[jira] Commented: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112331 ] Asgeir S. Nilsen commented on MNG-3259: --- I am unable to reproduce the error. Steps: - Used MNG-3259-2.zip - Installed parent pom - Installed multiproject Maven versions: 2.0.7 and 2.0.8-SNAPSHOT OS name: "sunos" version: "5.10" arch: "x86" Family: "unix" Java versions: Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode) Java HotSpot(TM) Server VM (build 1.5.0_13-b05, mixed mode) Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode) Expected result: - Multiproject build should fail Actual result: - Multiproject build passes. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ http://jira.codehaus.org/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112380 ] Asgeir S. Nilsen commented on MNG-3259: --- If it appears only on Windows -- could it be related to Windows' weird case-insensitive, but case-preserving file naming? I would guess that the strings c:\Windows and C:\WINDOWS have different hashcodes (and thus ordering could change), but are considered equal by the file system. Furthermore, the backslash \ vs forward slash / in file system paths could also cause equivalent paths to be treated different in a HashMap. > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: http://jira.codehaus.org/browse/MNG-3259 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8 >Reporter: Joerg Schaible >Assignee: Brian Fox >Priority: Blocker > Fix For: 2.0.8 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5 hours > Remaining Estimate: 0 minutes > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2570) Maven needs to support multiple logging levels
[ http://jira.codehaus.org/browse/MNG-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92666 ] Asgeir S. Nilsen commented on MNG-2570: --- What would it take to change the LoggerManager from ConsoleLoggerManager to for instance Log4JLoggerManager, and enable log4j configuration of Maven's logging? This would enable different levels of logging for different components, and also different appenders. Would it suffice to drop one of the plexus-logging jars in M2_HOME/lib ? There is some information at http://plexus.codehaus.org/writing-components-trial/05_01_custom_logging_implementation.html, but I'm not sufficiently experienced with Maven's innards to determine what needs to be done.. > Maven needs to support multiple logging levels > -- > > Key: MNG-2570 > URL: http://jira.codehaus.org/browse/MNG-2570 > Project: Maven 2 > Issue Type: Improvement > Components: Logging >Affects Versions: 2.0.4 >Reporter: Brian Fox > > The current logging levels are essentially verbose (default) and debug (-X). > We need a slightly less verbose output so that things like compiler warnings > and other output is actually visable to the developer. Currently it gets > buried in all the noise. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-64) "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04
[ http://jira.codehaus.org/browse/MCOMPILER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134114#action_134114 ] Asgeir S. Nilsen commented on MCOMPILER-64: --- Same problem here. I'm running with -XX:MaxPermSize=128m. java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode) Maven version: 2.0.9 Java version: 1.6.0_06 OS name: "sunos" version: "5.10" arch: "x86" Family: "unix" build 09-May-2008 13:00:08The system is out of resources. build 09-May-2008 13:00:08Consult the following stack trace for details. build 09-May-2008 13:00:08java.lang.OutOfMemoryError: PermGen space build 09-May-2008 13:00:08at java.lang.ClassLoader.defineClass1(Native Method) build 09-May-2008 13:00:08at java.lang.ClassLoader.defineClass(ClassLoader.java:620) build 09-May-2008 13:00:08at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) build 09-May-2008 13:00:08at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) build 09-May-2008 13:00:08at java.net.URLClassLoader.access$000(URLClassLoader.java:56) build 09-May-2008 13:00:08at java.net.URLClassLoader$1.run(URLClassLoader.java:195) build 09-May-2008 13:00:08at java.security.AccessController.doPrivileged(Native Method) build 09-May-2008 13:00:08at java.net.URLClassLoader.findClass(URLClassLoader.java:188) build 09-May-2008 13:00:08at org.codehaus.plexus.compiler.javac.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:56) build 09-May-2008 13:00:08at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) build 09-May-2008 13:00:08at com.sun.tools.javac.main.JavaCompiler.(JavaCompiler.java:314) build 09-May-2008 13:00:08at com.sun.tools.javac.main.JavaCompiler.instance(JavaCompiler.java:72) build 09-May-2008 13:00:08at com.sun.tools.javac.main.Main.compile(Main.java:340) build 09-May-2008 13:00:08at com.sun.tools.javac.main.Main.compile(Main.java:279) build 09-May-2008 13:00:08at com.sun.tools.javac.main.Main.compile(Main.java:270) build 09-May-2008 13:00:08at com.sun.tools.javac.Main.compile(Main.java:87) build 09-May-2008 13:00:08at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) build 09-May-2008 13:00:08at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) build 09-May-2008 13:00:08at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) build 09-May-2008 13:00:08at java.lang.reflect.Method.invoke(Method.java:597) build 09-May-2008 13:00:08at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420) build 09-May-2008 13:00:08at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141) build 09-May-2008 13:00:08at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493) build 09-May-2008 13:00:08at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114) build 09-May-2008 13:00:08at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) build 09-May-2008 13:00:08at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) build 09-May-2008 13:00:08at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) build 09-May-2008 13:00:08at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) build 09-May-2008 13:00:08at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) build 09-May-2008 13:00:08at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) build 09-May-2008 13:00:08at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) build 09-May-2008 13:00:08at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space > after update to java 1.6.0_04 > > > Key: MCOMPILER-64 > URL: http://jira.codehaus.org/browse/MCOMPILER-64 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Maven version: 2.0.8 > Java version: 1.6.0_04 > OS name: "
[jira] Commented: (SUREFIRE-61) Incorrect classpath ordering
[ http://jira.codehaus.org/browse/SUREFIRE-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88259 ] Asgeir S. Nilsen commented on SUREFIRE-61: -- Any hope on getting this fixed and released on the maven-surefire-plugin 2.2 branch? > Incorrect classpath ordering > > > Key: SUREFIRE-61 > URL: http://jira.codehaus.org/browse/SUREFIRE-61 > Project: Maven Surefire > Issue Type: Bug > Components: JUnit 3.x support >Affects Versions: 2.0 (2.2 plugin) > Environment: maven2.0.4, sun-jdk-1.5.0.09, maven-surefire-plugin 2.2, > surefire 2.0, gentoo linux x86 >Reporter: Martin Vysny >Priority: Critical > Attachments: my-app.zip, > SUREFIRE61_barrettas_surefire_surefire-booter_for_rev_489098.patch > > > Surefire incorrectly interprets classpath ordering. > Steps to reproduce: > 1. unzip my-app.zip - it's a simple mvn project created with >mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app >and lightly patched > 2. mvn test >in my case, it prints out > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties > jar:file:/home/vyzivus/.m2/repository/jxta/jxta/2.0/jxta-2.0.jar!/log4j.properties >which is incorrect. log4j.properties is located both in jxta.jar and > src/test/resources, but I think that src/test/resources takes precedence over > jxta. This ordering is set correctly in surefire36745tmp file I think, but > surefire seems to ignore the ordering. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
