Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
It's really sad that SUN hasn't fixed this yet;-( I wonder that there are not more people are affected by this issue. Actually everybody who uses build tools like Maven should have slower compile times. Our workaround is, that our build isn't generating the class-path entry in the manifest any more. But this workaround only works for jars that get deployed to our application server within a EAR file. Arnaud HERITIER wrote: We are facing the same issue actually ( https://jira.jboss.org/jira/browse/GTNPORTAL-27) and several months after the issues was reported to SUN it is not yet fixed in JDK :-( Please vote for it : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 Nobody found a workaround ? Arnaud On Mon, May 25, 2009 at 11:38 AM, j_ri jochen.riedlin...@l-bank.de wrote: Hi, meanwhile I posted in the Sun Developer Network, since my tests lead to the conclusion that the problem occures because of a bug in the javac compiler of Java 6. see http://forums.sun.com/thread.jspa?threadID=5386732tstart=0 http://forums.sun.com/thread.jspa?threadID=5386732tstart=0 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 but what I wonder about is that nobody else who compiles quite large prohjects using maven has the same problems as we do. another question I have is the follwing: why does maven put all transitive dependencies in the compile classpath? it is best practise to have all jars I really depend on for my compilation as direct dependency in my pom. why don't force this and just put the direct dependencies in the compile classpath and pass the transitive ones only to the other tasks (packaging, etc.)? -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp2868702p2968777.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1-5-to-1-6-tp2868702p3807303.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
Yes I don't understand how we can find such a problem which isn't yet fix by SUN :-( Cheers, Arnaud # Arnaud Héritier # Software Factory Manager # eXo Platform # http://www.exoplatform.com # http://blog.aheritier.net On Mon, Oct 12, 2009 at 1:02 PM, j_ri jochen.riedlin...@l-bank.de wrote: It's really sad that SUN hasn't fixed this yet;-( I wonder that there are not more people are affected by this issue. Actually everybody who uses build tools like Maven should have slower compile times. Our workaround is, that our build isn't generating the class-path entry in the manifest any more. But this workaround only works for jars that get deployed to our application server within a EAR file. Arnaud HERITIER wrote: We are facing the same issue actually ( https://jira.jboss.org/jira/browse/GTNPORTAL-27) and several months after the issues was reported to SUN it is not yet fixed in JDK :-( Please vote for it : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 Nobody found a workaround ? Arnaud On Mon, May 25, 2009 at 11:38 AM, j_ri jochen.riedlin...@l-bank.de wrote: Hi, meanwhile I posted in the Sun Developer Network, since my tests lead to the conclusion that the problem occures because of a bug in the javac compiler of Java 6. see http://forums.sun.com/thread.jspa?threadID=5386732tstart=0 http://forums.sun.com/thread.jspa?threadID=5386732tstart=0 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 but what I wonder about is that nobody else who compiles quite large prohjects using maven has the same problems as we do. another question I have is the follwing: why does maven put all transitive dependencies in the compile classpath? it is best practise to have all jars I really depend on for my compilation as direct dependency in my pom. why don't force this and just put the direct dependencies in the compile classpath and pass the transitive ones only to the other tasks (packaging, etc.)? -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp2868702p2968777.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1-5-to-1-6-tp2868702p3807303.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
finally we found the cause of the issue. javac of 1.6 doesn't ignore the class-path entries in the manifest file of the JARs in the classpath as 1.5 did. As all of our jars have configured . manifest addClasspathfalse/addClasspath /manifest .. There are a lot of dependencies in the search path for class files of the compiler which are nor really there. If maven passes c:\Daten\repository\commons-lang\commons-lang\2.3\commons-lang-2.3.jar as command line option to the compiler and the manifest Class-Path of another JAr in my classpath contains the relative path lib/commons-lang-2.3.jar then the compiler resolves this to project directory/lib/commons-lang-2.3.jar and additionally adds that to the search path for class files of javac. So this search path suddenly contained 500 paths to jar files, instead of the 56 passed by maven -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp2868702p2980816.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
B can use types form A in its public interface. Do we really want to force all C's to know which of B's dependencies appear in its public interface? Or do all B's document which dependencies they re-export, i.e. which should be considered transitive, and which not? Actually, that last idea, might not be so bad... o.k., you are right. I also don't want to know all tha dependencies and I really like your last idea! Actually the guys at Sun should just fix JDK 1.6 to be able to handle long classpaths again;-) -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp2868702p2973143.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
Hi, meanwhile I posted in the Sun Developer Network, since my tests lead to the conclusion that the problem occures because of a bug in the javac compiler of Java 6. see http://forums.sun.com/thread.jspa?threadID=5386732tstart=0 http://forums.sun.com/thread.jspa?threadID=5386732tstart=0 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6843751 but what I wonder about is that nobody else who compiles quite large prohjects using maven has the same problems as we do. another question I have is the follwing: why does maven put all transitive dependencies in the compile classpath? it is best practise to have all jars I really depend on for my compilation as direct dependency in my pom. why don't force this and just put the direct dependencies in the compile classpath and pass the transitive ones only to the other tasks (packaging, etc.)? -- View this message in context: http://n2.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp2868702p2968777.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
On Mon, May 25, 2009 at 11:38, j_ri jochen.riedlin...@l-bank.de wrote:
another question I have is the follwing:
why does maven put all transitive dependencies in the compile classpath? it
is best practise to have all jars I really depend on for my compilation as
direct dependency in my pom. why don't force this and just put the direct
dependencies in the compile classpath and pass the transitive ones only to
the other tasks (packaging, etc.)?
A: provides class Foo {}
B: provides function getTheFoo() - Foo
B: has a compile time dependency on A
C: has a compile-time dependency on B
C: calls getTheFoo(), which returns a... oops.
B can use types form A in its public interface. Do we really want to
force all C's to know which of B's dependencies appear in its public
interface? Or do all B's document which dependencies they re-export,
i.e. which should be considered transitive, and which not?
Actually, that last idea, might not be so bad...
// ben
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
I did some mor tests. First of all I tried with deactivated antivirus software. As expected this didn't solve the problem What I wrote last time. That Maven builds a different classpath for JDK 1.5 and 1.6 is only true for Maven 2.07. Maven 2.1.0 built the same classpath with both versions of the JDK. Today I tried something different. I set JAVA_HOME to JDK 1.6, but configured the maven-compiler-plugin to use the javac.exe of JDK 1.5: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration executableC:\Programme\java\jdk1.5.0_11\bin\javac.exe/executable forktrue/fork verbosetrue/verbose source1.5/source target1.5/target encodingutf-8/encoding /configuration /plugin The result was: the codes was compiled fast! For me it seems that there is a problem if Maven passes a very long classpath to the java-compiler of JDK 1.6. When I did my test with ant I just included a fileset with *.jar and not every single item of the classpath with full path. Does somebody have experience with quite big sourcetrees with a lot of dependencies in the classpath?? -- View this message in context: http://www.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp23501164p23559061.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
I finally found the source of the problem. I extracted the classpath from the maven-compiler-plugin by writing the output (-X Otion) to a log-file and generated argument files for calling javac from the commandline: javac @options.txt @classes.txt And the times are equal to maven: Very slow with JDK 1.6 and fast compilation time with JDK 1.5. The compile of Java 1.6 seems to have a problem when passing a very long classpath or too many source-files (all with a full path). What is the maven-compiler-plugin doing? Just calling javac on the commandline? Ant seems to be able to handle this better. j_ri wrote: I did some mor tests. First of all I tried with deactivated antivirus software. As expected this didn't solve the problem What I wrote last time. That Maven builds a different classpath for JDK 1.5 and 1.6 is only true for Maven 2.07. Maven 2.1.0 built the same classpath with both versions of the JDK. Today I tried something different. I set JAVA_HOME to JDK 1.6, but configured the maven-compiler-plugin to use the javac.exe of JDK 1.5: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration executableC:\Programme\java\jdk1.5.0_11\bin\javac.exe/executable forktrue/fork verbosetrue/verbose source1.5/source target1.5/target encodingutf-8/encoding /configuration /plugin The result was: the codes was compiled fast! For me it seems that there is a problem if Maven passes a very long classpath to the java-compiler of JDK 1.6. When I did my test with ant I just included a fileset with *.jar and not every single item of the classpath with full path. Does somebody have experience with quite big sourcetrees with a lot of dependencies in the classpath?? -- View this message in context: http://www.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp23501164p23560941.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
On Fri, May 15, 2009 at 8:41 AM, j_ri jochen.riedlin...@l-bank.de wrote: I did some mor tests. First of all I tried with deactivated antivirus software. As expected this didn't solve the problem What I wrote last time. That Maven builds a different classpath for JDK 1.5 and 1.6 is only true for Maven 2.07. Maven 2.1.0 built the same classpath with both versions of the JDK. Yes, that was fixed in 2.0.9 because we moved the dependencies to linkedhashsets...the changes between jdks is exactly why we made that change. You can now influence the order by rearranging the order of the dependencies in your pom. Today I tried something different. I set JAVA_HOME to JDK 1.6, but configured the maven-compiler-plugin to use the javac.exe of JDK 1.5: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.0.2/version configuration executableC:\Programme\java\jdk1.5.0_11\bin\javac.exe/executable forktrue/fork verbosetrue/verbose source1.5/source target1.5/target encodingutf-8/encoding /configuration /plugin The result was: the codes was compiled fast! For me it seems that there is a problem if Maven passes a very long classpath to the java-compiler of JDK 1.6. When I did my test with ant I just included a fileset with *.jar and not every single item of the classpath with full path. Does somebody have experience with quite big sourcetrees with a lot of dependencies in the classpath?? -- View this message in context: http://www.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp23501164p23559061.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
Which JDK under what OS ? 2009/5/12 j_ri jochen.riedlin...@l-bank.de: Hi, I have problems with the compilation-time of some of our projects using java 6 (update 10 and 13) and maven (I tried with 2.0.7 and 2.1.0). Compiling 806 source-files takes about 7 seconds using jdk 1.5. When switching to jdk 1.6 ist takes 59 seconds. To compare the results I copied the jar-files of all dependencies and transitive dependencies to a lib folder and created a ant script for compiling the 806 source-files using jdk 1.6..and it compiled fast.7 seconds. maven alone can't be the problem, since it builds fast with jdk 1.5 . jdk alone can't be the problem, since it builds fast without maven . We don't have the problem with all of our projects, some of them build within the same timespan as before. I think the problem is with projects haveing a lot of transitive dependencies. I would appreciate if someone can give me a hint how to solve this. Searching the www I didn't find that there is a genaral issue with maven and jdk 6, isn't it? Thanks, Jochen -- View this message in context: http://www.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp23501164p23501164.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
I tried with JDK 6 Update 10 and JDK 6 Update 13(with JDK 5 Update 11 everything was fine) OS is Windows XP Pro SP2 I tried with Maven 2.0.7 and 2.1.0 -- View this message in context: http://www.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp23501164p23520344.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
Have you told your antivirus to trust the new install of java? 2009/5/13 j_ri jochen.riedlin...@l-bank.de I tried with JDK 6 Update 10 and JDK 6 Update 13(with JDK 5 Update 11 everything was fine) OS is Windows XP Pro SP2 I tried with Maven 2.0.7 and 2.1.0 -- View this message in context: http://www.nabble.com/Slow-maven-compile-after-upgrading-JDK-from-1.5-to-1.6-tp23501164p23520344.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Slow maven compile after upgrading JDK from 1.5 to 1.6
No, our antivirus is configured to trust nothing;-) we didn't configure it to trust the old java and so the new java isn't configured as trustet either. But I'll try after I found an admin who does ist for me (I'm working in a bank.) Today we noticed while checking the log output of running mvn with -X option that compiler:compile used a different classpath with JDK 1.5 and 1.6 The dependencies are not only loaded in different order, but some of the transitive dependencies are missing. So there must be a classloading or dependency resolution difference between the different versions of the JDK. Here is the example of the classpath of one of the smaller submodules (as you can see oro-2.0.7.jar is not listet when using JDK 6): Maven 2.0.7, JDK 6 Update 13: [DEBUG] Classpath: [D:\daten\clearcase\snap\LEgO_DevMerge\LPROFI_APP01\lego\LegoCore\modell\target\classes c:\Daten\repository\lbank\lidos\lidos-utils\1.16.2\lidos-utils-1.16.2.jar c:\Daten\repository\lbank\externPruefziffer\iban\1.1.0\iban-1.1.0.jar c:\Daten\repository\commons-math\commons-math\1.2\commons-math-1.2.jar c:\Daten\repository\lbank\lidos\ejb\lidos-ejb\1.16.2\lidos-ejb-1.16.2-client.jar c:\Daten\repository\antlr\antlr\2.7.6\antlr-2.7.6.jar D:\daten\clearcase\snap\LEgO_DevMerge\LPROFI_APP01\lego\LegoCore\common\target\classes c:\Daten\repository\org\hibernate\hibernate\3.2.4.sp1\hibernate-3.2.4.sp1.jar c:\Daten\repository\commons-validator\commons-validator\1.1.4\commons-validator-1.1.4.jar c:\Daten\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar c:\Daten\repository\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar c:\Daten\repository\logkit\logkit\1.0.1\logkit-1.0.1.jar c:\Daten\repository\asm\asm\1.5.3\asm-1.5.3.jar c:\Daten\repository\commons-beanutils\commons-beanutils\1.7.0\commons-beanutils-1.7.0.jar c:\Daten\repository\lbank\interchange\interchange\1.2.7\interchange-1.2.7.jar c:\Daten\repository\avalon-framework\avalon-framework\4.1.3\avalon-framework-4.1.3.jar c:\Daten\repository\lbank\functions\functions\1.3.0\functions-1.3.0.jar c:\Daten\repository\commons-logging\commons-logging\1.1\commons-logging-1.1.jar c:\Daten\repository\net\sf\ehcache\ehcache\1.2.3\ehcache-1.2.3.jar c:\Daten\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar c:\Daten\repository\lbank\lidos\ejb\lidos-ejb-client-remote\1.16.2\lidos-ejb-client-remote-1.16.2.jar c:\Daten\repository\lbank\mbf\mbf-common\1.6.3\mbf-common-1.6.3.jar c:\Daten\repository\asm\asm-attrs\1.5.3\asm-attrs-1.5.3.jar c:\Daten\repository\cglib\cglib\2.1_3\cglib-2.1_3.jar c:\Daten\repository\jdom\jdom\1.0\jdom-1.0.jar c:\Daten\repository\lbank\framework\framework\1.3.6\framework-1.3.6.jar c:\Daten\repository\commons-lang\commons-lang\2.3\commons-lang-2.3.jar c:\Daten\repository\javax\transaction\jta\1.0.1B\jta-1.0.1B.jar] [DEBUG] Output directory: D:\daten\clearcase\snap\LEgO_DevMerge\LPROFI_APP01\lego\LegoCore\modell\target\classes Maven 2.0.7, JDK 5 Update 11: [DEBUG] Classpath: [D:\daten\clearcase\snap\LEgO_DevMerge\LPROFI_APP01\lego\LegoCore\modell\target\classes c:\Daten\repository\javax\transaction\jta\1.0.1B\jta-1.0.1B.jar c:\Daten\repository\lbank\framework\framework\1.3.6\framework-1.3.6.jar c:\Daten\repository\lbank\interchange\interchange\1.2.7\interchange-1.2.7.jar c:\Daten\repository\antlr\antlr\2.7.6\antlr-2.7.6.jar c:\Daten\repository\logkit\logkit\1.0.1\logkit-1.0.1.jar c:\Daten\repository\commons-beanutils\commons-beanutils\1.7.0\commons-beanutils-1.7.0.jar c:\Daten\repository\asm\asm\1.5.3\asm-1.5.3.jar c:\Daten\repository\javax\servlet\servlet-api\2.5\servlet-api-2.5.jar c:\Daten\repository\commons-collections\commons-collections\3.1\commons-collections-3.1.jar c:\Daten\repository\avalon-framework\avalon-framework\4.1.3\avalon-framework-4.1.3.jar c:\Daten\repository\jdom\jdom\1.0\jdom-1.0.jar c:\Daten\repository\lbank\externPruefziffer\iban\1.1.0\iban-1.1.0.jar c:\Daten\repository\net\sf\ehcache\ehcache\1.2.3\ehcache-1.2.3.jar c:\Daten\repository\commons-lang\commons-lang\2.3\commons-lang-2.3.jar c:\Daten\repository\commons-logging\commons-logging\1.1\commons-logging-1.1.jar c:\Daten\repository\oro\oro\2.0.7\oro-2.0.7.jar c:\Daten\repository\lbank\lidos\lidos-utils\1.16.2\lidos-utils-1.16.2.jar c:\Daten\repository\dom4j\dom4j\1.6.1\dom4j-1.6.1.jar c:\Daten\repository\cglib\cglib\2.1_3\cglib-2.1_3.jar c:\Daten\repository\asm\asm-attrs\1.5.3\asm-attrs-1.5.3.jar c:\Daten\repository\lbank\lidos\ejb\lidos-ejb\1.16.2\lidos-ejb-1.16.2-client.jar c:\Daten\repository\commons-validator\commons-validator\1.1.4\commons-validator-1.1.4.jar c:\Daten\repository\lbank\mbf\mbf-common\1.6.3\mbf-common-1.6.3.jar c:\Daten\repository\org\hibernate\hibernate\3.2.4.sp1\hibernate-3.2.4.sp1.jar c:\Daten\repository\lbank\functions\functions\1.3.0\functions-1.3.0.jar c:\Daten\repository\commons-math\commons-math\1.2\commons-math-1.2.jar
