[jira] Created: (MNG-3722) Fail to run CXF code generation with 2.0.10 RC
Fail to run CXF code generation with 2.0.10 RC -- Key: MNG-3722 URL: http://jira.codehaus.org/browse/MNG-3722 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.10 Reporter: nicolas de loof Attachments: test.zip The attached project contains only a WSDL 2 Java code generation with a dependency to slf4j. Running "mvn install" fails in 2.0.10-RC9 with a NoSuchMethodError : trace on commons-logging SLF4J API. This MAY be a cxf plugin issue, as maybe it doesn't build the JAXB classpath correctly... Running with maven2 2.0.9 doesn't throw this error (the code generation fails as the sample WSDL is RPC/encoded, but this is not the issue to be demonstrated here) -- 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] Created: (MAVENUPLOAD-2183) re-upload ckjm please
re-upload ckjm please -- Key: MAVENUPLOAD-2183 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2183 Project: Maven Upload Requests Issue Type: Wish Reporter: Nicolas Dordet "gr.spinellis","[EMAIL PROTECTED]:/home/groups/c/ck/ckjm/htdocs/m2repo","rsync_ssh","Nicolas Dordet","[EMAIL PROTECTED]",, -- 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: (SUREFIRE-235) failure reason not displayed
[ http://jira.codehaus.org/browse/SUREFIRE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145541#action_145541 ] Jörg Hohwiller commented on SUREFIRE-235: - According to the following link, this is the tracker category also for maven-surefire-report-plugin and maven-surefire-plugin: http://maven.apache.org/plugins/maven-surefire-report-plugin/issue-tracking.html http://maven.apache.org/plugins/maven-surefire-plugin/issue-tracking.html Beside its an Issue about maven-surefire-plugin as far as I understand. Did I get something wrong? > failure reason not displayed > > > Key: SUREFIRE-235 > URL: http://jira.codehaus.org/browse/SUREFIRE-235 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.0 (2.2 plugin) >Reporter: Jörg Hohwiller >Assignee: Carlos Sanchez > > Neigther with "mvn test" nor with "mvn -X test" I get the reason why a unit > test fails. > Of course I can run the test within my IDE but in my case it worked within > the IDE and only did NOT work in maven2. > After times of digging I found that there is a bug in sufrefire > (MSUREFIRE-115) causing this problem. > It would have saved me a lot of time if surefire would log the reason if a > test fails. This should include stacktraces of Exceptions if started with -X. > Currently I only get: > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failure. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugn.java:403) > what is absolutely useless to track down the problem. -- 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: (SUREFIRE-235) failure reason not displayed
[ http://jira.codehaus.org/browse/SUREFIRE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145542#action_145542 ] Jörg Hohwiller commented on SUREFIRE-235: - Using a JVM option is unsuiteable in my situation because we need a solution for the entire team. Acording to the documentation: http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html I could do this in my pom.xml org.apache.maven.plugins maven-surefire-plugin false ... However it does NOT work (has no effect at all). > failure reason not displayed > > > Key: SUREFIRE-235 > URL: http://jira.codehaus.org/browse/SUREFIRE-235 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.0 (2.2 plugin) >Reporter: Jörg Hohwiller >Assignee: Carlos Sanchez > > Neigther with "mvn test" nor with "mvn -X test" I get the reason why a unit > test fails. > Of course I can run the test within my IDE but in my case it worked within > the IDE and only did NOT work in maven2. > After times of digging I found that there is a bug in sufrefire > (MSUREFIRE-115) causing this problem. > It would have saved me a lot of time if surefire would log the reason if a > test fails. This should include stacktraces of Exceptions if started with -X. > Currently I only get: > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failure. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugn.java:403) > what is absolutely useless to track down the problem. -- 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] Reopened: (SUREFIRE-235) failure reason not displayed
[ http://jira.codehaus.org/browse/SUREFIRE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Hohwiller reopened SUREFIRE-235: - Reopened, see comments above. > failure reason not displayed > > > Key: SUREFIRE-235 > URL: http://jira.codehaus.org/browse/SUREFIRE-235 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.0 (2.2 plugin) >Reporter: Jörg Hohwiller >Assignee: Carlos Sanchez > > Neigther with "mvn test" nor with "mvn -X test" I get the reason why a unit > test fails. > Of course I can run the test within my IDE but in my case it worked within > the IDE and only did NOT work in maven2. > After times of digging I found that there is a bug in sufrefire > (MSUREFIRE-115) causing this problem. > It would have saved me a lot of time if surefire would log the reason if a > test fails. This should include stacktraces of Exceptions if started with -X. > Currently I only get: > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failure. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugn.java:403) > what is absolutely useless to track down the problem. -- 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] Created: (MPIR-135) NPE if license is not defined
NPE if license is not defined - Key: MPIR-135 URL: http://jira.codehaus.org/browse/MPIR-135 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: license Affects Versions: 2.1 Environment: maven 2.0.9 java 1.5 Reporter: Andreas Höhmann [INFO] [site:site] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.report.projectinfo.LicenseReport.getLicenseURL(LicenseReport.java:156) at org.apache.maven.report.projectinfo.LicenseReport.canGenerateReport(LicenseReport.java:114) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.filterReports(AbstractSiteRenderingMojo.java:177) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:81) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:49 9) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) $ at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] -- 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: (MPIR-135) NPE if license is not defined
[ http://jira.codehaus.org/browse/MPIR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145552#action_145552 ] Andreas Höhmann commented on MPIR-135: -- Siemens manual Siemens License > NPE if license is not defined > - > > Key: MPIR-135 > URL: http://jira.codehaus.org/browse/MPIR-135 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: license >Affects Versions: 2.1 > Environment: maven 2.0.9 > java 1.5 >Reporter: Andreas Höhmann > > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.report.projectinfo.LicenseReport.getLicenseURL(LicenseReport.java:156) > at > org.apache.maven.report.projectinfo.LicenseReport.canGenerateReport(LicenseReport.java:114) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.filterReports(AbstractSiteRenderingMojo.java:177) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:81) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:49 > 9) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > $ > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- 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] Created: (SCM-403) git scm:update command currently only works on the branch 'master'
git scm:update command currently only works on the branch 'master' --- Key: SCM-403 URL: http://jira.codehaus.org/browse/SCM-403 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.1 Reporter: Mark Struberg The scm:update command of the maven-scm-provider-gitexe currently only works on the branch 'master' which is comparable to 'trunk' in SVN. So this will fail if we are working on a 'real' branch. -- 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: (MPIR-135) NPE if license is not defined
[ http://jira.codehaus.org/browse/MPIR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145553#action_145553 ] Andreas Höhmann commented on MPIR-135: -- if i define a the the file-listing of the base-dir of the artifact is displayed as license ... hmm ?! > NPE if license is not defined > - > > Key: MPIR-135 > URL: http://jira.codehaus.org/browse/MPIR-135 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: license >Affects Versions: 2.1 > Environment: maven 2.0.9 > java 1.5 >Reporter: Andreas Höhmann > > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.report.projectinfo.LicenseReport.getLicenseURL(LicenseReport.java:156) > at > org.apache.maven.report.projectinfo.LicenseReport.canGenerateReport(LicenseReport.java:114) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.filterReports(AbstractSiteRenderingMojo.java:177) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:81) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:49 > 9) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > $ > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- 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] Created: (SCM-404) tgit scm:update does not have TCK Test yet
tgit scm:update does not have TCK Test yet -- Key: SCM-404 URL: http://jira.codehaus.org/browse/SCM-404 Project: Maven SCM Issue Type: Test Components: maven-scm-provider-git Reporter: Mark Struberg Attachments: GitExeUpdateTck.patch The maven-scm-provider-gitexe currently does not have the TCK test for the update command. The attachment contains the necessary patch to enable the TCK. Please do not activate this TCK unless we improved the 'update' command to pass TCK! -- 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-2720) Multiproject dependencies not accurate for project.compileClasspathElements when run from root project
[ http://jira.codehaus.org/browse/MNG-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145554#action_145554 ] Kaizer Sogiawala commented on MNG-2720: --- I think I have a workaround for this one. I created a Grouping POM (BOM-POM) and listed all the dependencies that are getting fizzled out downsteam in the grouping POM. I then replaced the individual dependencies from the downstream projects with one dependency on the grouping POM. That seemed to marshal all the jars properly in the reactor build. So effectively aggregate all the dependencies in the grouping POM and consume that POM downstream. Remember to use the pom and pom for the grouper. > Multiproject dependencies not accurate for project.compileClasspathElements > when run from root project > -- > > Key: MNG-2720 > URL: http://jira.codehaus.org/browse/MNG-2720 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.4 >Reporter: Jeff Genender > Fix For: Reviewed Pending Version Assignment > > > In a plugin I wrote (jspc), needs the dependency jars. It asks for this with > the request for the project.compileClasspathElements. In a multiproject > environment, when each project is built individually, it seems correct. > Example (when run with -X ina subproject dir) showing classpath: > /Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar > /Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar > /Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar > /Users/mbp/.m2/repository/tldtestapp/testexttld/1/testexttld-1.jar > <-NOTICE HERE - THIS IS AN ARTIFACT FROM ANOTHER SUBPROJECT > /Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar] > When it is run from the Top level/Root project...here is the output: > Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar > /Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar > /Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar > /Users/mbp/Desktop/jsp-example/TestTldProject/target/classes >INSTEAD > /Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar] > The second project has a dependency on the testexttld-1.jar because it > contains tag libs which must be wrapped in a jar. When run from a top level, > it uses the other project's classes directory instead of the JAR artifact. > WIth JSPC and taglibs, this makes it so it cannot work. If I have a > dependency on a jar, that jar should be the dependency as expected and not a > classes directory. For full explanation and example see here: > http://jira.codehaus.org/browse/MJSPC-4 -- 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] Created: (MECLIPSE-481) Eclipse project generation doesn't respect the compiler version settings
Eclipse project generation doesn't respect the compiler version settings Key: MECLIPSE-481 URL: http://jira.codehaus.org/browse/MECLIPSE-481 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.5.1 Environment: FreeBSD 6.3-STABLE FreeBSD 6.3-STABLE Maven version: 2.0.9 Java version: 1.6.0_03-p4 OS name: "freebsd" version: "6.3-stable" arch: "i386" Family: "unix" Eclipse Ganymede 3.4.0 Reporter: Eugene Dzhurinsky Priority: Minor Attachments: maven-eclipse-plugin-jre-fails.zip As I found in the issue http://jira.codehaus.org/browse/MECLIPSE-172, the eclipse plugin should respect the compiler settings provided in the maven-compiler-plugin to include the correct JRE in a generated .classpath file. However for some reason this doesn't work, and the default JRE (in my case - 1.6.0) is being included as a container JRE rather than expected JRE 1.5.0 Am I understanding things correctly and this is a bug, or may be this is expected behavior? I had also attached the compressed simple project with pom.xml and generated .project and .classparth files to illustrate the problem. The proposed solution to include explicit definition of the does the trick. -- 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: (SCM-396) git provider implements scm update
[ http://jira.codehaus.org/browse/SCM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14#action_14 ] Mark Struberg commented on SCM-396: --- Olivier, this is ok, please close it. I've created SCM-403 and SCM-404 for the improvements. > git provider implements scm update > --- > > Key: SCM-396 > URL: http://jira.codehaus.org/browse/SCM-396 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > Attachments: GitExeUpdateTck.patch > > -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145559#action_145559 ] Steve Gilbert commented on MNG-1832: I agree with others who state that the other suggest solutions are adequate. They are not. The timestamp the buildnumber plugin provides is an "epoch" integer value. The resulting manifest then looks like this: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: gilberts2 Build-Jdk: 1.4.2_15 Implementation-Title: a-code-module Implementation-Version: 1.0-SNAPSHOT Implementation-Vendor-Id: srg Implementation-Build: 65 buildDate: 1219240079087 Note the "buildDate" value. There is no way to modify that format. The output of the timestamp property does not have the formatting capabilities of the buildNumber property. In fact, here is the code from the plugin that sets the value: String timestamp = String.valueOf( now.getTime() ); project.getProperties().put( timestampPropertyName, timestamp ); Exposing a date-time property within Maven itself that can be used within the jar plugin configuration section would be preferred and should be easy. > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145562#action_145562 ] Steve Gilbert commented on MNG-1832: MNG-2562 states this is fixed in 2.0.10 but there is no explanation how it was fixed. > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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-3472) configuration possibilities to limit size of local repository
[ http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145566#action_145566 ] David Greenberg commented on MNG-3472: -- Joerg, would you please expand upon what you mean by not keeping the local repo in the profile? While I'm sure the "documentation" has plenty of information, it is always helpful to summarize or at least link to the specific text that is relevant to the problem. I also would have voted for this, as 14GB mysteriously disappeared from my server over time until I thought to look at the local repo. An external tool would be fine; does one exist that fixes precisely this problem? > configuration possibilities to limit size of local repository > - > > Key: MNG-3472 > URL: http://jira.codehaus.org/browse/MNG-3472 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.8 >Reporter: manuel aldana > > it would be great to make repository-size configurable, for instance by > setting the maximum number of downloads of a snapshot-version to be kept. > thus the explosion of local repository size can be reduced. > especially when you are working with many in-house multi-module projects > which are marked as snapshots before released , can increase repository size > significantly. > see mailing-list discussion: > http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.html -- 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-3472) configuration possibilities to limit size of local repository
[
http://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145567#action_145567
]
Benjamin Bentmann commented on MNG-3472:
bq. it is always helpful to summarize or at least link to the specific text
that is relevant to the problem.
The [Settings Reference|http://maven.apache.org/settings.html#Simple_Values]
describes the {{}} element which can be used to specify a
custom path for the local repo.
> configuration possibilities to limit size of local repository
> -
>
> Key: MNG-3472
> URL: http://jira.codehaus.org/browse/MNG-3472
> Project: Maven 2
> Issue Type: Improvement
> Components: Settings
>Affects Versions: 2.0.8
>Reporter: manuel aldana
>
> it would be great to make repository-size configurable, for instance by
> setting the maximum number of downloads of a snapshot-version to be kept.
> thus the explosion of local repository size can be reduced.
> especially when you are working with many in-house multi-module projects
> which are marked as snapshots before released , can increase repository size
> significantly.
> see mailing-list discussion:
> http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.html
--
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] Created: (MANTRUN-97) can't execute optional ant tasks
can't execute optional ant tasks
Key: MANTRUN-97
URL: http://jira.codehaus.org/browse/MANTRUN-97
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.2
Reporter: Haiko Emmel
Attachments: pom.xml
try to run an optional ant task produce following error message:
Scanning for projects...
project-execute
[#generate-resources]
[antrun:run]
Executing tasks
[echo] Hello World
[ERROR]The following mojo encountered an error while executing:
[ERROR]Group-Id: org.apache.maven.plugins
[ERROR]Artifact-Id: maven-antrun-plugin
[ERROR]Version: 1.2
[ERROR]Mojo: run
[ERROR]brought in via: POM
[ERROR]While building project:
[ERROR]Group-Id: haiko
[ERROR]Artifact-Id: test
[ERROR]Version: 1.0-SNAPSHOT
[ERROR]From file: C:\Dokumente und Einstellungen\hemmel\Eigene
Dateien\Projects\test\pom.xml
[ERROR]Reason: An Ant BuildException has occured: Could not create task or type
of type: propertyfile.
[ERROR]Ant could not find the task or a class this task relies upon.
[ERROR]This is common and has a number of causes; the usual
[ERROR]solutions are to read the manual pages then download and
[ERROR]install needed JAR files, or fix the build file:
[ERROR] - You have misspelt 'propertyfile'.
[ERROR] Fix: check your spelling.
[ERROR] - The task needs an external JAR file to execute
[ERROR] and this is not found at the right place in the classpath.
[ERROR] Fix: check the documentation for dependencies.
[ERROR] Fix: declare the task.
[ERROR] - The task is an Ant optional task and the JAR file and/or libraries
[ERROR] implementing the functionality were not found at the time you
[ERROR] yourself built your installation of Ant from the Ant sources.
[ERROR] Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
[ERROR] task and make sure it contains more than merely a
META-INF/MANIFEST.MF.
[ERROR] If all it contains is the manifest, then rebuild Ant with the needed
[ERROR] libraries present in ${ant.home}/lib/optional/ , or alternatively,
[ERROR] download a pre-built release version from apache.org
[ERROR] - The build file was written for a later version of Ant
[ERROR] Fix: upgrade to at least the latest release version of Ant
[ERROR] - The task is not an Ant core or optional task
[ERROR] and needs to be declared using .
[ERROR] - You are attempting to use a task defined using
[ERROR] or but have spelt wrong or not
[ERROR] defined it at the point of use
[ERROR]Remember that for JAR files to be visible to Ant tasks implemented
[ERROR]in ANT_HOME/lib, the files must be in the same directory or on the
[ERROR]classpath
[ERROR]Please neither file bug reports on this problem, nor email the
[ERROR]Ant mailing lists, until all of these causes have been explored,
[ERROR]as this is not an Ant bug.
For more information, run with the -e flag
BUILD FAILED
Total time: 1 second
Finished at: Wed Aug 20 13:07:42 CEST 2008
Final Memory: 33M/78M
--
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: (MARTIFACT-32) Maven does not expand expressions while installing artifacts locally
[
http://jira.codehaus.org/browse/MARTIFACT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145570#action_145570
]
Harsha Rai commented on MARTIFACT-32:
-
Thanks Henrik! for the pointer. It helps. Much appreciated.
> Maven does not expand expressions while installing artifacts locally
> -
>
> Key: MARTIFACT-32
> URL: http://jira.codehaus.org/browse/MARTIFACT-32
> Project: Maven Artifact
> Issue Type: Bug
>Reporter: Harsha Rai
>
> When a pom uses expressions like: grizzly.version in the following pom.xml
> >
> >
>...
> > grizzly-module
> > jar
> > ${grizzly.version}
> Everything works well when the project.version above is defined as a
> property as 'grizzly.version'
> The local repository layout also seems to be correct, for a given property
> value for, grizzly.version.
> What's going wrong is, maven just copies the same pom.xml to the local repo
> directory and from there to the remote repo while deploying the
> artifacts of the same project, whose version is parameterized.
> In the strict sense, while parsing the pom and resolving the artifacts,
> maven got the right version for the project.version for the project; the
> same should have been used inside the pom file while installing locally. By
> doing this, the expanded pom files will have right artifact information.
> Users should be given a choice if they want maven to expand expressions in
> the pom.xml or leave them as it is.
> I don't know the right category of the project and component. Please reassign
> / redirect as appropriate.
> This belongs somewhere pom parsing, artifact resolver and mvn install.
> thanks..
--
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] Closed: (MANTRUN-97) can't execute optional ant tasks
[
http://jira.codehaus.org/browse/MANTRUN-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MANTRUN-97.
Assignee: Benjamin Bentmann
Resolution: Not A Bug
This looks like a simple misconfiguration. You will need to add {{ant-nodeps}}
as a dependency of the plugin (not the project!). Please have a look at [Using
tasks not included in Ant's default
jar|http://maven.apache.org/plugins/maven-antrun-plugin/examples/customTasks.html].
> can't execute optional ant tasks
>
>
> Key: MANTRUN-97
> URL: http://jira.codehaus.org/browse/MANTRUN-97
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.2
>Reporter: Haiko Emmel
>Assignee: Benjamin Bentmann
> Attachments: pom.xml
>
>
> try to run an optional ant task produce following error message:
> Scanning for projects...
> project-execute
> [#generate-resources]
> [antrun:run]
> Executing tasks
> [echo] Hello World
> [ERROR]The following mojo encountered an error while executing:
> [ERROR]Group-Id: org.apache.maven.plugins
> [ERROR]Artifact-Id: maven-antrun-plugin
> [ERROR]Version: 1.2
> [ERROR]Mojo: run
> [ERROR]brought in via: POM
> [ERROR]While building project:
> [ERROR]Group-Id: haiko
> [ERROR]Artifact-Id: test
> [ERROR]Version: 1.0-SNAPSHOT
> [ERROR]From file: C:\Dokumente und Einstellungen\hemmel\Eigene
> Dateien\Projects\test\pom.xml
> [ERROR]Reason: An Ant BuildException has occured: Could not create task or
> type of type: propertyfile.
> [ERROR]Ant could not find the task or a class this task relies upon.
> [ERROR]This is common and has a number of causes; the usual
> [ERROR]solutions are to read the manual pages then download and
> [ERROR]install needed JAR files, or fix the build file:
> [ERROR] - You have misspelt 'propertyfile'.
> [ERROR] Fix: check your spelling.
> [ERROR] - The task needs an external JAR file to execute
> [ERROR] and this is not found at the right place in the classpath.
> [ERROR] Fix: check the documentation for dependencies.
> [ERROR] Fix: declare the task.
> [ERROR] - The task is an Ant optional task and the JAR file and/or libraries
> [ERROR] implementing the functionality were not found at the time you
> [ERROR] yourself built your installation of Ant from the Ant sources.
> [ERROR] Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to
> the
> [ERROR] task and make sure it contains more than merely a
> META-INF/MANIFEST.MF.
> [ERROR] If all it contains is the manifest, then rebuild Ant with the
> needed
> [ERROR] libraries present in ${ant.home}/lib/optional/ , or alternatively,
> [ERROR] download a pre-built release version from apache.org
> [ERROR] - The build file was written for a later version of Ant
> [ERROR] Fix: upgrade to at least the latest release version of Ant
> [ERROR] - The task is not an Ant core or optional task
> [ERROR] and needs to be declared using .
> [ERROR] - You are attempting to use a task defined using
> [ERROR] or but have spelt wrong or not
> [ERROR] defined it at the point of use
> [ERROR]Remember that for JAR files to be visible to Ant tasks implemented
> [ERROR]in ANT_HOME/lib, the files must be in the same directory or on the
> [ERROR]classpath
> [ERROR]Please neither file bug reports on this problem, nor email the
> [ERROR]Ant mailing lists, until all of these causes have been explored,
> [ERROR]as this is not an Ant bug.
>
> For more information, run with the -e flag
>
> BUILD FAILED
>
> Total time: 1 second
> Finished at: Wed Aug 20 13:07:42 CEST 2008
> Final Memory: 33M/78M
>
--
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-3722) Fail to run CXF code generation with 2.0.10 RC
[ http://jira.codehaus.org/browse/MNG-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145588#action_145588 ] John Casey commented on MNG-3722: - This is a relatively simple issue of the jackrabbit webdav wagon bringing in a version of slf4j that doesn't get "hidden" by the shade plugin when maven is built. I've fixed it locally, but I'd like to put together an integration test to verify it before closing this issue. > Fail to run CXF code generation with 2.0.10 RC > -- > > Key: MNG-3722 > URL: http://jira.codehaus.org/browse/MNG-3722 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.10 >Reporter: nicolas de loof >Assignee: John Casey > Attachments: test.zip > > > The attached project contains only a WSDL 2 Java code generation with a > dependency to slf4j. > Running "mvn install" fails in 2.0.10-RC9 with a NoSuchMethodError : trace on > commons-logging SLF4J API. > This MAY be a cxf plugin issue, as maybe it doesn't build the JAXB classpath > correctly... > Running with maven2 2.0.9 doesn't throw this error (the code generation fails > as the sample WSDL is RPC/encoded, but this is not the issue to be > demonstrated here) -- 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] Updated: (MNG-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich updated MNG-2576: -- Priority: Major (was: Minor) Summary: Make Like Reactor Mode (was: Add option to find root of project tree from subproject and build required deps) > Make Like Reactor Mode > -- > > Key: MNG-2576 > URL: http://jira.codehaus.org/browse/MNG-2576 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Kenney Westerhof > Fix For: Reviewed Pending Version Assignment > > > Add a commandline option to enable maven to expand the reactor scope to find > projects that are dependencies > of the projects currently in the reactor, and add them. > Currently only the current project and child projects are included in the > reactor search. I'm proposing > to add a commandline switch that lets maven check parent directories to find > the root of the project tree, > and then do a normal reactor scan, only adding projects that would normally > not be added if they're needed > as dependencies of the projects that would normally be built. > Here's a sample project tree: > * root > ** p1 > *** c1 (depends on p2) > ** p2 (depends on c2) > ** p3 > *** c2 > And a sample algorithm: > - When building c1, the reactor would contain [c1]. > - Maven would check p1, then root, etc, using the tags (without the > versions!) > to see if the project is still in the current reactor. > - It would then create a second list of projects (reactor2) containing ALL > projects, using the newly discovered root: [root, p1, c2, p2]. > - remove all projects from reactor2 contained in reactor: reactor2 = [root, > p1, p2] > - resolve all direct dependencies for all projects in reactor in reactor2 and > add them to reactor, taking versions into account: reactor = [p2, c1] > - repeat previous step until all projects have their dependencies resolved > from reactor 2. first iteration would yield reactor = [c2, p2, c1], > next iteration would stop since c1 doesn't have any dependencies present in > reactor2. > This would ensure that when some local project's sources have changed, > they'll be incorporated > in the build, regardless of where you build. So you don't have to do a > reactor build each time you change more > than 1 project, and you don't have to remember which projects you changed and > build them in the correct order > yourself, manually. -- 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] Closed: (MNG-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Fabulich closed MNG-2576. - Resolution: Fixed Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.0 Checked in revision 687388. > Make Like Reactor Mode > -- > > Key: MNG-2576 > URL: http://jira.codehaus.org/browse/MNG-2576 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Kenney Westerhof > Fix For: 2.1.0 > > > Add a commandline option to enable maven to expand the reactor scope to find > projects that are dependencies > of the projects currently in the reactor, and add them. > Currently only the current project and child projects are included in the > reactor search. I'm proposing > to add a commandline switch that lets maven check parent directories to find > the root of the project tree, > and then do a normal reactor scan, only adding projects that would normally > not be added if they're needed > as dependencies of the projects that would normally be built. > Here's a sample project tree: > * root > ** p1 > *** c1 (depends on p2) > ** p2 (depends on c2) > ** p3 > *** c2 > And a sample algorithm: > - When building c1, the reactor would contain [c1]. > - Maven would check p1, then root, etc, using the tags (without the > versions!) > to see if the project is still in the current reactor. > - It would then create a second list of projects (reactor2) containing ALL > projects, using the newly discovered root: [root, p1, c2, p2]. > - remove all projects from reactor2 contained in reactor: reactor2 = [root, > p1, p2] > - resolve all direct dependencies for all projects in reactor in reactor2 and > add them to reactor, taking versions into account: reactor = [p2, c1] > - repeat previous step until all projects have their dependencies resolved > from reactor 2. first iteration would yield reactor = [c2, p2, c1], > next iteration would stop since c1 doesn't have any dependencies present in > reactor2. > This would ensure that when some local project's sources have changed, > they'll be incorporated > in the build, regardless of where you build. So you don't have to do a > reactor build each time you change more > than 1 project, and you don't have to remember which projects you changed and > build them in the correct order > yourself, manually. -- 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] Created: (MAVENUPLOAD-2184) upload new release 1.13 to org.mentaframework
upload new release 1.13 to org.mentaframework --- Key: MAVENUPLOAD-2184 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2184 Project: Maven Upload Requests Issue Type: Task Reporter: Fernando Boaglio The Mentawai goal is to be a simple, flexible, joyful and productive Java web framework. This is a new release with a lot of improvements . TIA -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145596#action_145596 ] Paul Benedict commented on MNG-1832: See MNG-3718 on how it was implemented. > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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] Updated: (MPIR-135) NPE if license URL is not defined
[ http://jira.codehaus.org/browse/MPIR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MPIR-135: - Summary: NPE if license URL is not defined (was: NPE if license is not defined) > NPE if license URL is not defined > - > > Key: MPIR-135 > URL: http://jira.codehaus.org/browse/MPIR-135 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: license >Affects Versions: 2.1 > Environment: maven 2.0.9 > java 1.5 >Reporter: Andreas Höhmann > > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.report.projectinfo.LicenseReport.getLicenseURL(LicenseReport.java:156) > at > org.apache.maven.report.projectinfo.LicenseReport.canGenerateReport(LicenseReport.java:114) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.filterReports(AbstractSiteRenderingMojo.java:177) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:81) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:49 > 9) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > $ > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > -- 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] Closed: (SCM-396) git provider implements scm update
[ http://jira.codehaus.org/browse/SCM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-396. Resolution: Fixed > git provider implements scm update > --- > > Key: SCM-396 > URL: http://jira.codehaus.org/browse/SCM-396 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > Attachments: GitExeUpdateTck.patch > > -- 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] Updated: (SCM-403) git scm:update command currently only works on the branch 'master'
[ http://jira.codehaus.org/browse/SCM-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-403: - Fix Version/s: 1.x > git scm:update command currently only works on the branch 'master' > --- > > Key: SCM-403 > URL: http://jira.codehaus.org/browse/SCM-403 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.1 >Reporter: Mark Struberg > Fix For: 1.x > > > The scm:update command of the maven-scm-provider-gitexe currently only works > on the branch 'master' which is comparable to 'trunk' in SVN. So this will > fail if we are working on a 'real' branch. -- 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] Updated: (SCM-404) tgit scm:update does not have TCK Test yet
[ http://jira.codehaus.org/browse/SCM-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-404: - Affects Version/s: 1.1 Fix Version/s: 1.x > tgit scm:update does not have TCK Test yet > -- > > Key: SCM-404 > URL: http://jira.codehaus.org/browse/SCM-404 > Project: Maven SCM > Issue Type: Test > Components: maven-scm-provider-git >Affects Versions: 1.1 >Reporter: Mark Struberg > Fix For: 1.x > > Attachments: GitExeUpdateTck.patch > > > The maven-scm-provider-gitexe currently does not have the TCK test for the > update command. > The attachment contains the necessary patch to enable the TCK. > Please do not activate this TCK unless we improved the 'update' command to > pass TCK! -- 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] Updated: (SCM-71) Implement accurev provider
[ http://jira.codehaus.org/browse/SCM-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-71: Fix Version/s: (was: future) 1.1 > Implement accurev provider > -- > > Key: SCM-71 > URL: http://jira.codehaus.org/browse/SCM-71 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-accurev >Reporter: Emmanuel Venisse > Fix For: 1.1 > > > I look at documentation, and it's very easy to do (works like cvs or svn) > http://www.accurev.com/download/docs/AccuRev_User_CLI.pdf -- 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] Created: (MJAVADOC-213) Unix Shell used is Configurable
Unix Shell used is Configurable --- Key: MJAVADOC-213 URL: http://jira.codehaus.org/browse/MJAVADOC-213 Project: Maven 2.x Javadoc Plugin Issue Type: Improvement Affects Versions: 2.4 Environment: unix/linux Reporter: John Patrick Not all linux enviroments have bash installed, configuration ability might be useful for the javadoc plugin. Embedded error: Error rendering Maven report: Unable to find javadoc version: Error while executing process. /bin/bash: not found [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during page generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:101) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error rendering Maven report: Unable to find javadoc version: Error while executing process. at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:149) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) ... 18 more Caused by: org.apache.maven.reporting.MavenReportException: Unable to find javadoc version: Error while executing process. at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1093) at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:131) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) ... 22 more Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:652) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocVersion(AbstractJavadocMojo.java:2941) at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1085) ... 24 more Caused by: java.io.IOException: /bin/bash: not found at java.lang.UNIXProcess.forkAndExec(Native Method) at java.lang.UNIXProcess.(UNIXProcess.java:52) at java.lang.Runtime.execInternal(Native Method) at java.lang.Runtime.exec(Runtime.java:566) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:647) ... 28 more [INFO] [INFO] Total time: 26 seconds [INFO] Finished at: Wed Aug 20 15:17:12 CEST 2008 [INFO] Final Memory: 44M/83M [INFO]
[jira] Updated: (MNG-1944) cyclic dependencies causes maven to not include all transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Williams updated MNG-1944: --- Attachment: MNG-1944.patch I've attached a patch that makes two changes to the way cycles in the dependency graph are handled: 1. A warning is logged when a cycle is detected. 2. When a dependency is discarded because it creates a cycle, the remaining non-problematic dependencies are still processed as usual. > cyclic dependencies causes maven to not include all transitive dependencies > --- > > Key: MNG-1944 > URL: http://jira.codehaus.org/browse/MNG-1944 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.1 >Reporter: Brian Fox >Priority: Critical > Fix For: 3.0 > > Attachments: MNG-1944.patch > > > Try including dom4j 1.5.2 and see what dependencies are resolved. dom4j > depends on jaxen, which depends on dom4j. When maven sees the cyclic > dependency, it stops processing the jaxen dependency. This leaves everything > else jaxen depends on not included in the final artifact list. This is mvn -x > output: > dom4j:dom4j:jar:1.5.2 (selected for compile) > [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile) > [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > [DEBUG] dom4j:dom4j:jar:1.5.2 (removed - causes a cycle in the > graph) > [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile) > [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile) > Notice that xerces and xom and everything else jaxen depends on isn't > included. > Taking dom4j out of the jaxen pom locally causes everything to be included: > [DEBUG] com.stchome.maven.mojo:helloUser:jar:1.0-SNAPSHOT (selected for null) > [DEBUG] dom4j:dom4j:jar:1.5.2 (selected for compile) > [DEBUG] stax:stax-api:jar:1.0 (selected for compile) > [DEBUG] pull-parser:pull-parser:jar:2 (selected for compile) > [DEBUG] jaxme:jaxme-api:jar:0.3 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [DEBUG] msv:xsdlib:jar:20030807 (selected for compile) > [DEBUG] xpp3:xpp3:jar:1.1.3.3 (selected for compile) > [DEBUG] jaxen:jaxen:jar:1.1-beta-4 (selected for compile) > [DEBUG] jdom:jdom:jar:b10 (selected for compile) > [DEBUG] xom:xom:jar:1.0b3 (selected for compile) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (selected for compile) > [DEBUG] xerces:xercesImpl:jar:2.2.1 (selected for compile) > [DEBUG] xalan:xalan:jar:2.6.0 (selected for compile) > [WARNING] > This artifact has been relocated to xml-apis:xml-apis:1.0.b2. > [DEBUG] xml-apis:xml-apis:jar:1.0.b2 (selected for compile) > [WARNING] > This artifact has been relocated to com.ibm.icu:icu4j:2.6.1. > [DEBUG] com.ibm.icu:icu4j:jar:2.6.1 (selected for compile) > [WARNING] > This artifact has been relocated to javax.servlet:servlet-api:2.4. > [DEBUG] javax.servlet:servlet-api:jar:2.4 (selected for compile) > [WARNING] > This artifact has been relocated to org.ccil.cowan.tagsoup:tagsoup:0.9.7. > [DEBUG] org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7 (selected for > compile) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.1 (removed - nearer found: 2.6.2) > [DEBUG] xerces:xmlParserAPIs:jar:2.6.2 (selected for compile) > [DEBUG] xerces:xercesImpl:jar:2.2.1 (removed - nearer found: 2.6.2) > [DEBUG] xerces:xercesImpl:jar:2.6.2 (selected for compile) > [DEBUG] msv:relaxngDatatype:jar:20030807 (selected for compile) -- 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: (MJAVADOC-213) Unix Shell used is Configurable
[ http://jira.codehaus.org/browse/MJAVADOC-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145606#action_145606 ] Olivier Lamy commented on MJAVADOC-213: --- This should be fixed : see MJAVADOC-154. Have you lock the javadoc plugin version in your pom ? > Unix Shell used is Configurable > --- > > Key: MJAVADOC-213 > URL: http://jira.codehaus.org/browse/MJAVADOC-213 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: unix/linux >Reporter: John Patrick > > Not all linux enviroments have bash installed, configuration ability might be > useful for the javadoc plugin. > Embedded error: Error rendering Maven report: Unable to find javadoc > version: Error while executing process. > /bin/bash: not found > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error during > page generation >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:324) >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during > page generation >at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:101) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) >... 16 more > Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error > rendering Maven report: Unable to find javadoc version: Error while > executing process. >at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:149) >at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) >at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) >at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) >at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) >... 18 more > Caused by: org.apache.maven.reporting.MavenReportException: Unable to > find javadoc version: Error while executing process. >at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1093) >at > org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:131) >at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) >... 22 more > Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error > while executing process. >at > org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:652) >at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) >at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) >at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocVersion(AbstractJavadocMojo.java:2941) >at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1085) >... 24 more > Caused by: java.io.IOException: /bin/bash: not found >at java.lang.UNIXP
[jira] Updated: (SCM-276) New SCM Provider: monotone
[ http://jira.codehaus.org/browse/SCM-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-276: - Fix Version/s: (was: future) 1.x > New SCM Provider: monotone > -- > > Key: SCM-276 > URL: http://jira.codehaus.org/browse/SCM-276 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-monotone > Environment: Unit tests succed on linux and windows. >Reporter: Tim Kettler > Fix For: 1.x > > Attachments: SCM-276-provider.patch, SCM-276-provider.patch, > SCM-276-site.patch > > > maven-scm provider implementation for monotone > (http://www.venge.net/monotone/) > The provider currently implements: add, checkin, checkout, status and tag > Unit tests run on linux and windows; tested with release plugin on linux. > One problem with the unit tests remains: > I needed to manually create the 'scm-test' directory for the unit tests. Is > this a bug in the test framework or should the provider create all missing > directores as needed? -- 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] Closed: (SCM-71) Implement accurev provider
[ http://jira.codehaus.org/browse/SCM-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-71. --- Resolution: Fixed fix in rev 653572 . > Implement accurev provider > -- > > Key: SCM-71 > URL: http://jira.codehaus.org/browse/SCM-71 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-accurev >Reporter: Emmanuel Venisse > Fix For: 1.1 > > > I look at documentation, and it's very easy to do (works like cvs or svn) > http://www.accurev.com/download/docs/AccuRev_User_CLI.pdf -- 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-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145614#action_145614
]
Harsha Rai commented on MNG-3057:
-
Hello:
The above patch does not work, if the global-version property is defined
outside pom.xml or outside settings.xml . In other words, if you define like :
$ mvn install -Dglobal-version=1.0.0
in maven 2.0.9 it does not reflect the property "global-version" into the
project properties (another existing bug against maven).
Hence, the generated pom still will have stale ${global-version} as value.
As you can guess obviously, one need to add a few lines of code to fix the
bug. Check property against System.getProperty(key) to see if there is a
global property defined from command line...
Here is a partial diff:
+while (m.find()) {
+String match = m.group();
+String key = match.substring(2, match.length()-1);
+String value = properties.getProperty(key);
+ if (value == null) {
+ System.out.println("Trying .. system wide
property..");
+ value = System.getProperty(key);
+ if (value !=null)
+ System.out.println("Found value from sys=" +
value);
+ }
+if (value != null) {
+s = s.replaceAll("\\$\\{" + key + "\\}", value);
+}
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
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] Issue Comment Edited: (MNG-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145614#action_145614
]
hg2008 edited comment on MNG-3057 at 8/20/08 6:33 PM:
--
Hello:
The above patch does not work, if the global-version property is defined
outside pom.xml or outside settings.xml . In other words, if you define like :
$ mvn install -Dglobal-version=1.0.0
in maven 2.0.9 it does not reflect the property "global-version" into the
project properties (another existing bug against maven).
Hence, the generated pom still will have stale ${global-version} as value.
As you can guess obviously, one need to add a few lines of code to fix the
bug. Check property against System.getProperty(key) to see if there is a
global property defined from command line...
Here is a partial diff:
+while (m.find()) {
+String match = m.group();
+String key = match.substring(2, match.length()-1);
+String value = properties.getProperty(key);
+ if (value == null) {
+ System.out.println("Trying .. system wide
property..");
+ value = System.getProperty(key);
+ if (value !=null)
+ System.out.println("Found value from sys=" +
value);
+ }
+if (value != null) {
+s = s.replaceAll("\\$\\{" + key + "\\}", value);
+}
was (Author: hg2008):
Hello:
The above patch does not work, if the global-version property is defined
outside pom.xml or outside settings.xml . In other words, if you define like :
$ mvn install -Dglobal-version=1.0.0
in maven 2.0.9 it does not reflect the property "global-version" into the
project properties (another existing bug against maven).
Hence, the generated pom still will have stale ${global-version} as value.
As you can guess obviously, one need to add a few lines of code to fix the
bug. Check property against System.getProperty(key) to see if there is a
global property defined from command line...
Here is a partial diff:
+while (m.find()) {
+String match = m.group();
+String key = match.substring(2, match.length()-1);
+String value = properties.getProperty(key);
+ if (value == null) {
+ System.out.println("Trying .. system wide
property..");
+ value = System.getProperty(key);
+ if (value !=null)
+ System.out.println("Found value from sys=" +
value);
+ }
+if (value != null) {
+s = s.replaceAll("\\$\\{" + key + "\\}", value);
+}
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
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] Work logged: (MENFORCER-27) Multi model project with enforcer plugin bug
[ http://jira.codehaus.org/browse/MENFORCER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#action_112505 ] Brian Fox logged work on MENFORCER-27: -- Author: Brian Fox Created on: 20/Aug/08 10:11 PM Start Date: 20/Aug/08 10:11 PM Worklog Time Spent: 1 minute Issue Time Tracking --- Time Spent: 1 minute Remaining Estimate: 0 minutes > Multi model project with enforcer plugin bug > > > Key: MENFORCER-27 > URL: http://jira.codehaus.org/browse/MENFORCER-27 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug >Reporter: Michal Capo >Assignee: Brian Fox > Fix For: 1.0 > > Attachments: test.zip > > Time Spent: 1 minute > Remaining Estimate: 0 minutes > > I'm using: java 1.6 and ubuntu 7.10. > 1. create multimodel project with following structure > 1a. > root > |- A > |- B > |- C > |-C1 > 1b. C1 has dependency on A > 2. run 'mvn eclipse:eclipse' in the root folder of project (everything work > perfect) > 3. add 'maven-enforcer-plugin' to root pom.xml with some configuration > 4. run 'mvn eclipse:eclipse' again (oops, creating of eclipse project fails) > 5. workaround before you run 'mvn eclipse:eclipse' you have to run 'mvn > install' in the root folder of this project > I added maven multi project. So you can try it out. -- 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] Created: (MNGSITE-62) Maven SCM plugin guide page 404s.
Maven SCM plugin guide page 404s. - Key: MNGSITE-62 URL: http://jira.codehaus.org/browse/MNGSITE-62 Project: Maven 2 Project Web Site Issue Type: Bug Reporter: Haikal Saadh Priority: Minor http://maven.apache.org/scm/plugins/guide/index.html, as linked from the left sidebar (from 'Guides'), 404s. -- 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: (MJAVADOC-213) Unix Shell used is Configurable
[ http://jira.codehaus.org/browse/MJAVADOC-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145635#action_145635 ] Ringo De Smet commented on MJAVADOC-213: Olivier, Yes, I had locked maven-javadoc-plugin to 2.3. Version 2.4 seems to resolve the issue. Sorry for the overhead. This issue may be closed. Ringo > Unix Shell used is Configurable > --- > > Key: MJAVADOC-213 > URL: http://jira.codehaus.org/browse/MJAVADOC-213 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: unix/linux >Reporter: John Patrick > > Not all linux enviroments have bash installed, configuration ability might be > useful for the javadoc plugin. > Embedded error: Error rendering Maven report: Unable to find javadoc > version: Error while executing process. > /bin/bash: not found > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error during > page generation >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) >at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) >at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) >at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:324) >at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during > page generation >at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:101) >at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) >at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) >... 16 more > Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error > rendering Maven report: Unable to find javadoc version: Error while > executing process. >at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:149) >at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) >at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) >at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) >at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) >... 18 more > Caused by: org.apache.maven.reporting.MavenReportException: Unable to > find javadoc version: Error while executing process. >at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1093) >at > org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:131) >at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) >... 22 more > Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error > while executing process. >at > org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:652) >at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) >at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) >at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.getJavadocVersion(AbstractJavadocMojo.java:2941) >at > org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1085) >... 24 more > Caused by: java.io.I
