[jira] Commented: (MRELEASE-488) -Dgoals option no longer accepts a comma (in release:perform)
[ http://jira.codehaus.org/browse/MRELEASE-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203351#action_203351 ] Martin Jaeger commented on MRELEASE-488: I found the same issue and confirm the problem. > -Dgoals option no longer accepts a comma (in release:perform) > - > > Key: MRELEASE-488 > URL: http://jira.codehaus.org/browse/MRELEASE-488 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: perform >Affects Versions: 2.0-beta-9 >Reporter: Chris LeCompte > > The -Dgoals option no longer accepts a comma separated list of goals. This > appears to be related to the way that the InvokerMavenExecutor is parsing the > string: > String[] rawGoals = goals.split( " " ); > as opposed to the forked maven executor: > String[] tokens = StringUtils.split( goals, ", " ); > a workaround for this is either to revert back to the beta-7 version, add the > -DmavenExecutorId=forked-path or use spaces as a delimiter and quote the > goals string. To reproduce use a command like: > mvn release:perform -Dgoals=clean,install -DconnectionUrl=... > the command will fail with an error such as: > [INFO] [INFO] Invalid task 'clean,install': you must specify a valid > lifecycle phase, or a goal in the format plugin:goal or > pluginGroupId:pluginArtifactId:pluginVersion:goal -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching reopened MRELEASE-261: --- Re-opened issue due to last comment. > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0-beta-10 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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-2696) Please sync the org.gmetrics repository with the central repository.
Please sync the org.gmetrics repository with the central repository. Key: MAVENUPLOAD-2696 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2696 Project: Maven Upload Requests Issue Type: Wish Reporter: Chris Mair Please sync the org.gmetrics repository with the central repository. Comma-Delimited Form: "org.gmetrics","mavens...@shell.sourceforge.net:/home/groups/g/gm/gmetrics/htdocs/m2repo","rsync_ssh","Chris Mair","chrism...@users.sourceforge.net",, Proof of Ownership of the gmetrics.org domain (Note name=Chris Mair): http://reports.internic.net/cgi/whois?whois_nic=gmetrics.org&type=domain Thanks - Chris Mair -- 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: (MDEP-231) Create a single dependency resolution plugin
[ http://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203296#action_203296 ] luke w patterson commented on MDEP-231: --- There have been times when a goal like this would have been useful to me. To be able to resolve an individual artifact from the command line without first creating a dummy pom. > Create a single dependency resolution plugin > > > Key: MDEP-231 > URL: http://jira.codehaus.org/browse/MDEP-231 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: resolve >Affects Versions: 2.1, 2.2 >Reporter: Marvin Froeder >Assignee: John Casey > Fix For: 2.2 > > Attachments: maven-dependency-plugin.patch, > maven-dependency-plugin.patch, maven-dependency-plugin.patch > > > The attached patch has a new goal that allows a single dependency to be > resolved, like this: > mvn > org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single > -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- 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-505) Linux Synergy client fails to execute scm:update command
[ http://jira.codehaus.org/browse/SCM-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-505. Resolution: Fixed fix [rev 891919|http://svn.apache.org/viewvc?rev=891919&view=rev] Thanks ! > Linux Synergy client fails to execute scm:update command > > > Key: SCM-505 > URL: http://jira.codehaus.org/browse/SCM-505 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-synergy >Affects Versions: 1.2 > Environment: Redhat Linux 5 > CM/Synergy 7.0 > Apache Maven 2.1.0 (r755702; 2009-03-19 00:40:27+0530) > Java version: 1.6.0_13 >Reporter: Subir S >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.3 > > Attachments: SCM-505-maven-scm-formatted.patch, > SCM-505-maven-scm.patch > > > The linux synergy client using remote client option does not work when using > scm:update goal. > Error is "ccm start -nogui -m -q -n user -pw password" cannot find the > appropriate database '/cm/dbs/testdb/db' > On command line if '-rc' option is used along with ccm start then everything > works. > Is there something additional to be done to make scm:update goal understand > that remote client is in use? > If there are some pointers, then i would like to help and send a patch or > test it -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[
http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203270#action_203270
]
Eric Miles commented on MRELEASE-261:
-
I'm not 100% sure this is fixed. I setup a project to use the beta-10-SNAPSHOT
plugin and it is still not working, I'm getting the following error while
trying to prepare the release:
{code}
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/Users/emiles/Projects/release-workspace/release-parent && svn
--non-interactive commit --file
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
--targets
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
[INFO] Working directory:
/Users/emiles/Projects/release-workspace/release-parent
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{code}
I have confirmed that I am using the beta 10 release as well as I have
confirmed the beta 10 release in Apache snapshots contained the v3.patch
identified in one of the previous comments. I'm attaching my sample project,
maven-release-issue.tar.gz. I'm hoping this can be used as a test case and/or
someone can tell me if I've set the project up incorrectly.
This work is being performed in a Mac OS X environment with JDK 1.5 and SVN
1.6.6.
> release:prepare shouls support flat directory multimodule projects
> --
>
> Key: MRELEASE-261
> URL: http://jira.codehaus.org/browse/MRELEASE-261
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
> Environment: linux / maven2 / svn
>Reporter: paul.whe...@gmail.com
>Assignee: Maria Odea Ching
> Fix For: 2.0-beta-10
>
> Attachments: flatProject.main.patch, flatProject.test.patch,
> maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch,
> MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch
>
>
> What I mean by flat file structure firstly.
> parent/pom.xml
> module1/pom.xml
> module2/pom.xml
> .
> .
> .
> module15/pom.xml
> the parent references the modules like so
>
> ../module1
> ../module2
> .
> .
> .
> ../module15
>
> When i release:prepare only the parent project is tagged the modules
> projects versions are incremented etc but the modules are not tagged in svn.
> I use this structure as i use eclipse as my IDE.
> I would love to see a fix for the issue marked as closed here
> http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand
> each submodule of the projects but it would be so nice to have the release
> plugin do this for me.
> forgive my english.
--
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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Miles updated MRELEASE-261: Attachment: maven-release-issue.tar.gz Sample project that still has release issues in a flat structure > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare > Environment: linux / maven2 / svn >Reporter: paul.whe...@gmail.com >Assignee: Maria Odea Ching > Fix For: 2.0-beta-10 > > Attachments: flatProject.main.patch, flatProject.test.patch, > maven-release-issue.tar.gz, MRELEASE-261-with-its-v3.patch, > MRELEASE-261-with-its.patch, MRELEASE-261.patch, PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MPDF-34) plugin fails with AbstractMethodError
[ http://jira.codehaus.org/browse/MPDF-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-34. - Resolution: Not A Bug Assignee: Lukas Theussl Wendy: please check the reporting plugins you use in continuum against the list we have at http://maven.apache.org/plugins/maven-pdf-plugin/examples/configuring-reports.html#Maven_Reporting_Plugins_Issues. I didn't check in detail but I am sure that some of them are not compatible. The report generation works for the cases I checked, eg on the doxia site https://svn.apache.org/repos/asf/maven/doxia/site/. But I guess excluding the reports as above is what you want anyway. > plugin fails with AbstractMethodError > - > > Key: MPDF-34 > URL: http://jira.codehaus.org/browse/MPDF-34 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: Maven 2.2.1 > Mac OS X >Reporter: Wendy Smoak >Assignee: Lukas Theussl > > To reproduce, change the pdf plugin version from 1.0 to 1.1 in > https://svn.apache.org/repos/asf/continuum/trunk/continuum-docs > With 1.0 it works fine. With 1.1 it fails with: > $ mvn site -X > ... > [FATAL ERROR] org.apache.maven.plugins.pdf.PdfMojo#execute() caused a linkage > error (java.lang.AbstractMethodError) and may be out-of-date. Check the > realms: > [FATAL ERROR] Plugin realm = > app0.child-container[org.apache.maven.plugins:maven-pdf-plugin:1.1] > ... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [DEBUG] Trace > java.lang.AbstractMethodError > at > org.apache.maven.plugins.pdf.PdfMojo.generateMavenReport(PdfMojo.java:1211) > at > org.apache.maven.plugins.pdf.PdfMojo.generateMavenReports(PdfMojo.java:1072) > at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:545) > at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > 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:597) > 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) > [INFO] > > [INFO] Total time: 26 seconds > [INFO] Finished at: Wed Dec 16 14:25:53 MST 2009 > [INFO] Final Memory: 88M/204M > [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] Issue Comment Edited: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203235#action_203235
]
John Wu edited comment on MJAVADOC-276 at 12/17/09 11:26 AM:
-
I encountered the similar problems. After multi-scenario verifications, I'd say
that
This is a regression, compare to version 2.6.
In a multi-module project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
In my tests, maven 2.2.1 and maven-release-plugin 2.0-beta-9 were used.
was (Author: phantom_john):
I encountered the similar problems. After multi-scenario verifications, I'd
say that
This is a regression, compare to version 2.6.
In a multi-module project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this
[jira] Issue Comment Edited: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203235#action_203235
]
John Wu edited comment on MJAVADOC-276 at 12/17/09 11:18 AM:
-
I encountered the similar problems. After multi-scenario verifications, I'd say
that
This is a regression, compare to version 2.6.
In a multi-module project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
was (Author: phantom_john):
I encountered the similar problems. After verifications, I'd say that
This is a regression, compare to version 2.6.
In a multi-modules project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this is being built,
> the submodule does not exist (yet).
> I have replicated this problem
[jira] Commented: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203235#action_203235
]
John Wu commented on MJAVADOC-276:
--
I encountered the similar problems. After verifications, I'd say that
This is a regression, compare to version 2.6.
In a multi-modules project, and say moduleA depends on moduleB, while running
release:perform (of course, from the project top level), the javadoc of version
2.6.1, during building moduleB (be OK), will try to build moduleA (should
it???), which will in turn cause various issues. If you're lucky, you'll see
something like "Missing: moduleB.jar:THE_NEW_VERSION ..." (It's obvious:
moduleB is being built and not completed yet). If not lucky, like me, I saw
"System property 'env' is required to build this project." because the command
arguments were not pass thru to the down stream build command.
Version 2.6 does not has that issue.
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this is being built,
> the submodule does not exist (yet).
> I have replicated this problem on two different computing environments, so
> I'm convinced that the Maven version is not relevant.
> (It is unclear to me if this problem also existed with Javadoc 2.6, but I
> don't think so.)
--
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-4499) Security management: Ease interaction with SSL sites
Security management: Ease interaction with SSL sites - Key: MNG-4499 URL: http://jira.codehaus.org/browse/MNG-4499 Project: Maven 2 & 3 Issue Type: Improvement Components: Artifacts and Repositories, Command Line, Deployment Affects Versions: 3.x Reporter: Marc Schöchlin Priority: Critical Development environments often use ssl-certificates which are self-signed or signed by company-internal certification authorities. If the certificate is unknown maven outputs the following message: --- INFO] Scanning for projects... [INFO] snapshot de.foo.bar:bar-parent:0.0.1-SNAPSHOT: checking for updates from snapshots [WARNING] repository metadata for: 'snapshot de.foo.bar:bar-parent:0.0.1-SNAPSHOT' could not be retrieved from repository: snapshots due to an error: Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target [INFO] Repository 'snapshots' will be blacklisted --- This is disastrous form usability point of view :-) Procedures like this are very not very convenient for developers: --- $JAVA_HOME/bin/keytool -import -alias UserTrustExternalCARoot -file UserTrustExternalCARoot.crt -keystore $JAVA_HOME/jre/lib/security/jssecacerts export MAVEN_OPTS="-Djavax.net.ssl.keyStore=$HOME/.keystore \ -Djavax.net.ssl.keyStorePassword=changeit \ -Djavax.net.ssl.trustStore=$HOME/.keystore \ -Djavax.net.ssl.trustStorePassword=changeit" mvn -Dusername=foo deploy --- Maven should provide an convenient way to accept a unknown certificate. I my opinion this should implemented like this: - If the exceptions is raised maven should output a message that the certificate can by downloaded and integrated in the keystore in an automated way by invoking the new maven option "-dc ..|--download-certificate " - If this option is invoked, maven automatically downloads the certificate/ca for the specified domain and adds it to a keystore located in $HOME/.m2/keystores/ an executes the specified goal with this keystore - If maven is called without the new option, maven uses the keystores in $HOME/.m2/keystores/ before giving up on certificate problems -- 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: (MASSEMBLY-420) maven fails when packing parent pom
[
http://jira.codehaus.org/browse/MASSEMBLY-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203198#action_203198
]
Kek commented on MASSEMBLY-420:
---
We have a similar problem:
- multimodule project
- defined assembly on parent to zip src/main/config and src/test/config
folders and attach the zip to module
- but some child-modules could have empty config folder
than we obtain
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to create
assembly: Error creating assembly archive config: You must set at least one
file.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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:597)
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: Failed to create
assembly: Error creating assembly archive config: You must set at least one
file.
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:421)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException:
Error creating assembly archive config: You must set at least one file.
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:194)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:370)
... 19 more
Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at
least one file.
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:272)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:250)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:852)
at
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:496)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:190)
... 20 more
I found the similar issue on maven-source-plugin:
http://jira.codehaus.org/browse/MSOURCES-44
So I suppose, that the problem could be solved in the same way. There are some
patches available. Some new parameter to ignore this problem will be helpfull,
this is very critical/blocking issue for my build environment.
Thank you for any help.
> maven fails when packing parent pom
> ---
>
> Key: MASSEMBLY-420
> URL: http://jira.codehaus.org/browse/MASSEMBLY-420
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Windows Vista
>Reporter: Karsten Ohme
>Priority: Blocker
>
> I have a parent module and multiple sub modules. I must build all submodules
> manually, because the parent assembly cannot be created.
> I have defined the assembly plugin in the parent.
> [INFO] [assembly:single {execution: make-assembly}]
> [WARNING] Cannot include project artifact: org.foo.bar:j2se:pom:1
> .0.2-SNAPSHOT; it doesn't have an associated file or directory.
> [INFO]
> --
[jira] Commented: (MPDF-34) plugin fails with AbstractMethodError
[
http://jira.codehaus.org/browse/MPDF-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203188#action_203188
]
Lukas Theussl commented on MPDF-34:
---
Confirmed. MPDF-26 introduced report generation in the pdf, apparently there is
a problem. Unfortunately the default was set to always generate reports (it
should have been optional IMO). You can switch it off as a workaround:
{code:xml}
false
{code}
> plugin fails with AbstractMethodError
> -
>
> Key: MPDF-34
> URL: http://jira.codehaus.org/browse/MPDF-34
> Project: Maven 2.x PDF Plugin
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: Maven 2.2.1
> Mac OS X
>Reporter: Wendy Smoak
>
> To reproduce, change the pdf plugin version from 1.0 to 1.1 in
> https://svn.apache.org/repos/asf/continuum/trunk/continuum-docs
> With 1.0 it works fine. With 1.1 it fails with:
> $ mvn site -X
> ...
> [FATAL ERROR] org.apache.maven.plugins.pdf.PdfMojo#execute() caused a linkage
> error (java.lang.AbstractMethodError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[org.apache.maven.plugins:maven-pdf-plugin:1.1]
> ...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [DEBUG] Trace
> java.lang.AbstractMethodError
> at
> org.apache.maven.plugins.pdf.PdfMojo.generateMavenReport(PdfMojo.java:1211)
> at
> org.apache.maven.plugins.pdf.PdfMojo.generateMavenReports(PdfMojo.java:1072)
> at org.apache.maven.plugins.pdf.PdfMojo.generatedPdf(PdfMojo.java:545)
> at org.apache.maven.plugins.pdf.PdfMojo.execute(PdfMojo.java:391)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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:597)
> 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)
> [INFO]
>
> [INFO] Total time: 26 seconds
> [INFO] Finished at: Wed Dec 16 14:25:53 MST 2009
> [INFO] Final Memory: 88M/204M
> [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: (MPDF-35) NPE when document descriptor has no meta information
[ http://jira.codehaus.org/browse/MPDF-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDF-35. - Resolution: Fixed Fix Version/s: 1.2 Assignee: Lukas Theussl Fixed in [r891591|http://svn.apache.org/viewvc?view=revision&revision=891591] > NPE when document descriptor has no meta information > > > Key: MPDF-35 > URL: http://jira.codehaus.org/browse/MPDF-35 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.2 > > > When there is no in pdf.xml the build fails with a NPE. The meta tag > should be optional. -- 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: (MPDF-35) NPE when document descriptor has no meta information
NPE when document descriptor has no meta information Key: MPDF-35 URL: http://jira.codehaus.org/browse/MPDF-35 Project: Maven 2.x PDF Plugin Issue Type: Bug Affects Versions: 1.1 Reporter: Lukas Theussl When there is no in pdf.xml the build fails with a NPE. The meta tag should be optional. -- 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: (MPDF-32) PDF generation fails due to velocity template error
[ http://jira.codehaus.org/browse/MPDF-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203185#action_203185 ] Lukas Theussl commented on MPDF-32: --- 1.5.1 is too old? Guess what, I was using 1.3.6... :) Anyway, MPDF-33 was a false alarm, I can reproduce your error. > PDF generation fails due to velocity template error > --- > > Key: MPDF-32 > URL: http://jira.codehaus.org/browse/MPDF-32 > Project: Maven 2.x PDF Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: Maven 2.0.10 JDK6, XP SP3 >Reporter: Michael Osipov > Attachments: pdf.log > > > I was trying to run mvn pdf:pdf and it suddenly failed. See attached log. The > failing template works flawlessly with the site goal. -- 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: (MEJB-3) Add ejb bundle feature like in maven 1
[
http://jira.codehaus.org/browse/MEJB-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=203184#action_203184
]
Michal Galet commented on MEJB-3:
-
If you just want to include your dependencies into your EJB jar file a simple
workaround is:
{code:xml}
org.apache.maven.plugins
maven-dependency-plugin
process-resources
copy-dependencies
target/classes
runtime
. . .
{code}
> Add ejb bundle feature like in maven 1
> --
>
> Key: MEJB-3
> URL: http://jira.codehaus.org/browse/MEJB-3
> Project: Maven 2.x EJB Plugin
> Issue Type: New Feature
> Environment: windows
>Reporter: Alexandre Vivien
>
> It could be nice if we could include dependencies in the ejb jar produce by
> the ejb plugin. In fact, I think an ejb bundle feature like in Maven 1 will
> be useful. We could use the dependencies scope or whatever. (Perhaps it can
> be handy to add a new scope name "bundle" that could be use with ejb, war and
> ear plugin )
> Thanks.
> Alexandre Vivien
--
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
