Agree that we should make sure nothing on jdbc side breaks in case we get take off jdbc-all from default build. Do we have a JIRA for this btw?
-Hanifi On Tue, Oct 14, 2014 at 4:13 PM, Aditya <[email protected]> wrote: > I too, am inclined towards retaining the warning and removing "jdbc-all" > module from a non release build. > > However, a pre-commit test must activate this profile before checking in a > patch. > > On Tue, Oct 14, 2014 at 4:10 PM, Hanifi Gunes <[email protected]> wrote: > >> I am inclined not using -dontwarn as it may mask possible issues that >> occur while proguarding. +1 for moving this from default build though. >> >> On Tue, Oct 14, 2014 at 4:05 PM, Aman Sinha <[email protected]> wrote: >> >>> Aditya, thanks for those flags. Do you want to create the JIRA for >>> removing it from the default build and perhaps assign it to yourself :) >>> >>> On Tue, Oct 14, 2014 at 3:34 PM, Aditya <[email protected]> wrote: >>> >>> > I agree. This could be made a part of "apache-release" profile. >>> > >>> > On Tue, Oct 14, 2014 at 3:32 PM, Jason Altekruse < >>> [email protected] >>> > > >>> > wrote: >>> > >>> > > I think the better option is to remove the proguard goal from the >>> default >>> > > build. It isn't testing anything or accomplishing a useful for the >>> dev >>> > team >>> > > to run it for every build, with or without the crazy logging. In the >>> > > meantime this would be useful for making the build a little faster. >>> > > >>> > > -Jason >>> > > >>> > > On Tue, Oct 14, 2014 at 3:16 PM, Aditya <[email protected]> >>> wrote: >>> > > >>> > >> This commit [1] turned off the verbose output from ProGuard >>> > >> >>> > >> However, the bulk of messages are info and warning, which requires >>> > >> additional flags to turn off. The following patch can turn off both >>> of >>> > >> these >>> > >> >>> > >> exec/jdbc-all/pom.xml | 2 ++ >>> > >> 1 file changed, 2 insertions(+) >>> > >> >>> > >> diff --git a/exec/jdbc-all/pom.xml b/exec/jdbc-all/pom.xml >>> > >> index 349366b..783fa6f 100644 >>> > >> --- a/exec/jdbc-all/pom.xml >>> > >> +++ b/exec/jdbc-all/pom.xml >>> > >> @@ -215,6 +215,8 @@ >>> > >> >>> <outputDirectory>${project.build.directory}</outputDirectory> >>> > >> <maxMemory>6g</maxMemory> >>> > >> <options> >>> > >> + <option>-dontnote</option> >>> > >> + <option>-dontwarn</option> >>> > >> <option>-dontobfuscate</option> >>> > >> <option>-dontoptimize</option> >>> > >> <option>-ignorewarnings</option> >>> > >> >>> > >> Do we want do do this? >>> > >> >>> > >> [1] >>> > >> >>> > >> >>> > >>> https://git-wip-us.apache.org/repos/asf?p=incubator-drill.git;a=commitdiff;h=35296501 >>> > >> >>> > >> On Tue, Oct 14, 2014 at 2:32 PM, Hanifi Gunes <[email protected]> >>> > >> wrote: >>> > >> >>> > >> > Afaik proguard plugin outputs verbose messages if it is a debug >>> build >>> > or >>> > >> > verbose switch is explicitly passed. Not sure about the recent >>> changes >>> > >> > though. >>> > >> > >>> > >> > >>> > >> > On Tue, Oct 14, 2014 at 2:11 PM, Jason Altekruse < >>> > >> [email protected] >>> > >> > > >>> > >> > wrote: >>> > >> > >>> > >> > > Not sure about the impact of the proguard upgrade, but I almost >>> > always >>> > >> > > cancel the build if I happen to see that output. I know if it >>> gets >>> > to >>> > >> > that >>> > >> > > point that I haven't failed any tests. The only reason we have >>> that >>> > in >>> > >> > the >>> > >> > > build is to make the thin jdbc jar, which most devs on the team >>> > aren't >>> > >> > > making use of right now. The longer term solution has been >>> > discussed, >>> > >> > which >>> > >> > > is pulling out the proguard step into a release only version of >>> the >>> > >> build >>> > >> > > that will be run less frequently. >>> > >> > > >>> > >> > > -Jason >>> > >> > > >>> > >> > > On Tue, Oct 14, 2014 at 1:58 PM, Aman Sinha < >>> [email protected]> >>> > >> wrote: >>> > >> > > >>> > >> > > > I am seeing a whole bunch of Proguard verbose output when >>> doing a >>> > >> build >>> > >> > > of >>> > >> > > > latest 0.7 master branch. Anyone else seeing this ? I >>> thought a >>> > >> > prior >>> > >> > > > commit had fixed this but maybe the upgrade of Proguard to 5.0 >>> > >> changed >>> > >> > > this >>> > >> > > > behavior. >>> > >> > > > >>> > >> > > >>> > >> > >>> > >> >>> > > >>> > > >>> > >>> >> >> >
