[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=145526#action_145526 ] Henrik Brautaset Aronsen commented on MNG-624: -- Harsha: There is a simple patch in MNG-3057 which solves this issue. automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Issue Type: Improvement Components: Inheritance and Interpolation Reporter: Brett Porter Assignee: Ralph Goers Priority: Blocker Fix For: 3.0 Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz Original Estimate: 4 hours Remaining Estimate: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-tabpanelfocusedCommentId=145527#action_145527
]
Henrik Brautaset Aronsen commented on MARTIFACT-32:
---
There is a simple patch in MNG-3057 which solves this issue.
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
project
parent
...
artifactIdgrizzly-module/artifactId
packagingjar/packaging
version${grizzly.version}/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] 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 build plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration useFilefalse/useFile /configuration /plugin ... 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-tabpanelfocusedCommentId=145552#action_145552 ] Andreas Höhmann commented on MPIR-135: -- licenses license nameSiemens/name distributionmanual/distribution commentsSiemens License/comments /license /licenses 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-tabpanelfocusedCommentId=145553#action_145553 ] Andreas Höhmann commented on MPIR-135: -- if i define a url/url 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-tabpanelfocusedCommentId=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 packagingpom/packaging and typepom/type 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 NOTICE - THE JAR IS NOT BEING ASKED FOR, BUT A CLASSES DIR 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 classpathContainer/ 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 {{localRepository}} 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 taskdef.
[ERROR] - You are attempting to use a task defined using
[ERROR]presetdef or macrodef 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-tabpanelfocusedCommentId=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
project
parent
...
artifactIdgrizzly-module/artifactId
packagingjar/packaging
version${grizzly.version}/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 taskdef.
[ERROR] - You are attempting to use a task defined using
[ERROR]presetdef or macrodef 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-tabpanelfocusedCommentId=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 parent 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 parent 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-tabpanelfocusedCommentId=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] 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-tabpanelfocusedCommentId=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.UNIXProcess.forkAndExec(Native Method) at
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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
