[jira] Commented: (MCOMPILER-59) Compilation fails on warning messages from javac (Java 6)
[ http://jira.codehaus.org/browse/MCOMPILER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120941 ] Ben Tatham commented on MCOMPILER-59: - I have the same problem on this warning: C:\work\.java:176: warning: sun.misc.Cleaner is Sun proprietary API and may be removed in a future release sun.misc.Cleaner cleaner = (sun.misc.Cleaner) getCleanerMethod ^ If I turn off verbose on the compiler-plugin, it passes the build. With verbose=true, the build gets a Compilation Failure. > Compilation fails on warning messages from javac (Java 6) > - > > Key: MCOMPILER-59 > URL: http://jira.codehaus.org/browse/MCOMPILER-59 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Mac OSX 10.4.10 > Maven version: 2.0.7 > Java version: 1.6.0-dp > OS name: "mac os x" version: "10.4.10" arch: "i386" > java version "1.6.0-dp" > Java(TM) SE Runtime Environment (build 1.6.0-dp-b88-34) > Java HotSpot(TM) Client VM (build 1.6.0-b88-17-release, mixed mode, sharing) >Reporter: Tim Meighen > Attachments: compiler-warning.tar.gz, warning.tar.gz > > > The attached project fails due to an inability to parse the following warning > messages from the Java compiler (Java 6) > [INFO] Compilation failure > could not parse error message: > /Users/tmeighen/compiler-warning/entity/target/classes/test/MyEntity.class: > warning: Cannot find annotation method 'name()' in type > 'javax.persistence.Table': class file for javax.persistence.Table not found > /Users/tmeighen/compiler-warning/logic/src/main/java/test/Logic.java:7: > warning: [deprecation] deprecateMe() in test.MyEntity has been deprecated > entity.deprecateMe(); > ^ > could not parse error message: > /Users/tmeighen/compiler-warning/entity/target/classes/test/MyEntity.class: > warning: Cannot find annotation method 'name()' in type > 'javax.persistence.Table': class file for javax.persistence.Table not found > /Users/tmeighen/compiler-warning/logic/src/main/java/test/Logic.java:7: > warning: [deprecation] deprecateMe() in test.MyEntity has been deprecated > entity.deprecateMe(); > ^ -- 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: (MASSEMBLY-281) Assembly Descriptor from external or parent source
Assembly Descriptor from external or parent source -- Key: MASSEMBLY-281 URL: http://jira.codehaus.org/browse/MASSEMBLY-281 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Ben Tatham It would be really convenient if you could easily share assembly descriptors from the parent pom. If the parent pom defines an assembly (likely in pluginManagement), and the descriptor lives in that parent project, then the child should be able to run the same assembly, without having to explicitly download and unpack the parent project dependency. The same fix/feature could be used for other config-file based plugins, like maven-verifier-plugin, as well. -- 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-3398) Multiple Plugin Declarations Ignored with no warning
Multiple Plugin Declarations Ignored with no warning Key: MNG-3398 URL: http://jira.codehaus.org/browse/MNG-3398 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.8, 2.0.7 Reporter: Ben Tatham If I (accidentally) declare the same plugin in the pom twice, with different executions,only the executions from the first declaration are run. And no warning is given saying that it is ignoring the others. I figure there are two options to solve this: either use both declarations, or fail the build (fail -- not warning) to tell the user to fix their pom. -- 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: (MREPOSITORY-11) Javadoc not included in the bundle
[ http://jira.codehaus.org/browse/MREPOSITORY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155038#action_155038 ] Ben Tatham commented on MREPOSITORY-11: --- Please update this page: http://maven.apache.org/guides/mini/guide-central-repository-upload.html to remove the bit about this bug. > Javadoc not included in the bundle > -- > > Key: MREPOSITORY-11 > URL: http://jira.codehaus.org/browse/MREPOSITORY-11 > Project: Maven 2.x Repository Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Maven version: 2.0.7 > Java version: 1.4.2_13 > OS name: "windows xp" version: "5.1" arch: "x86" >Reporter: Julien HENRY >Assignee: Carlos Sanchez > Fix For: 2.1 > > > On a simple project, I run: > mvn clean source:jar javadoc:jar repository:bundle-create > As a result in target I get: > artifact-version.jar > artifact-version-bundle.jar > artifact-version-javadoc.jar > artifact-version-sources.jar > But in artifact-version-bundle.jar there are only: > META-INF > pom.xml > LICENSE.txt > artifact-version.jar > artifact-version-sources.jar -- 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-2363) does not work in a multi-project build
[ http://jira.codehaus.org/browse/MNG-2363?page=comments#action_83175 ]
Ben Tatham commented on MNG-2363:
-
I have the same issue, but not using modules.
This is the critical point:
"Instead, during a multi-project build the profile is either on or off
depending on whether the file exists relative to the aggregator pom. The
decision is made once."
I want a parent pom to define some plugin executions (like xdoclet, jspc, etc),
so I can reuse those plugin configurations in all my other projects that need
these tools. Of course, that parent project doesn't have servlets/tags/jsps to
compile, so I have to use a profile to define them so that I can actually
install the pom project itself. But I don't want to have to use a command line
property to turn it on...my tests rely on those plugins running.
> does not work in a multi-project build
> ---
>
> Key: MNG-2363
> URL: http://jira.codehaus.org/browse/MNG-2363
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Reporter: David Boden
>Priority: Critical
> Fix For: 2.1
>
> Attachments: problemactivation.zip, screenshot-1.jpg
>
>
> I would expect each subproject to have the profile turned on or off depending
> on whether ${basedir}/file-to-check-for exists.
> Instead, during a multi-project build the profile is either on or off
> depending on whether the file exists relative to the *aggregator pom*. The
> decision is made once.
> Variable substitution doesn't work, so I can't explicitly use
> ${basedir}/file-to-check-for or any variation on this theme
> to workaround the bug.
> Some background to my particular problem. I have 10 modules to build. Some of
> them are GUI modules and contain a file called plugin.xml in the subproject
> directory. I want to package these up specially and sign them, ready for
> deployment to webstart. The other modules are shared and server code and I
> don't want these packaged in the same way. So, I've got a dependency in my
> *parent* pom file which activates a profile called "guibundle" if a
> plugin.xml file exists in the subproject directory.
--
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-212) Add POM Schema to pom.xml
Add POM Schema to pom.xml - Key: MECLIPSE-212 URL: http://jira.codehaus.org/browse/MECLIPSE-212 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Reporter: Ben Tatham Priority: Minor The POM Editor does not include the XML Schema for POMs in the pom.xml. In fact, if I add it manually, and then use the "Add Dependency" feature, it takes it away. Having the Schema available make it really nice to use the build in XML Editor features of Eclipse when manually modifying the POM. This should be an extremely trivial thing to... http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> instead of just -- 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: (MECLIPSE-212) Add POM Schema to pom.xml
[ http://jira.codehaus.org/browse/MECLIPSE-212?page=all ] Ben Tatham closed MECLIPSE-212. --- Resolution: Fixed I put this in the wrong place. Moved to MNGECLIPSE (Maven 2.x Eclipse Extension) > Add POM Schema to pom.xml > - > > Key: MECLIPSE-212 > URL: http://jira.codehaus.org/browse/MECLIPSE-212 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Reporter: Ben Tatham >Priority: Minor > > The POM Editor does not include the XML Schema for POMs in the pom.xml. In > fact, if I add it manually, and then use the "Add Dependency" feature, it > takes it away. > Having the Schema available make it really nice to use the build in XML > Editor features of Eclipse when manually modifying the POM. > This should be an extremely trivial thing to... > http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> instead of just -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_111754 ] Ben Tatham commented on MSOURCES-13: Yes, exactly. When run from an in a pom, instead of from the cmd line, the generate-sources phase gets run twice. In my case, it causes xdoclet to run twice, which causes other problems. > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Source Plugin > Issue Type: Improvement > Environment: ALL >Reporter: Ben Tatham > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
No-Forking mojos for use within a POM instead of CLI Key: MSOURCES-13 URL: http://jira.codehaus.org/browse/MSOURCES-13 Project: Maven 2.x Sources Plugin Issue Type: Improvement Environment: ALL Reporter: Ben Tatham Attachments: nofork.patch The exiting jar at test-jar mojos will always cause a lifecycle fork and generate-sources. This can cause all kinds of undesired side effects when using the source plugin with a pom, instead of CLI. I propose a simple fix (patch attached) to extend these two mojos in no-forking mode. I can't think of a better name for them. This behaviour is similar to the difference between assembly:assembly and assembly:attached. -- 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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MSOURCES-13: --- Attachment: nofork.patch My previous patch was a bit premature. This one actually does what it says. I didn't realize that maven plugin javadoc annotations were inherited! > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Sources Plugin > Issue Type: Improvement > Environment: ALL >Reporter: Ben Tatham > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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: (MASSEMBLY-452) Shared Assembly Descriptor does not work in Maven3-alpha4
Shared Assembly Descriptor does not work in Maven3-alpha4 - Key: MASSEMBLY-452 URL: http://jira.codehaus.org/browse/MASSEMBLY-452 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-4 Environment: Apache Maven 3.0-alpha-4 (r835944; 2009-11-13 13:06:31-0500) Java version: 1.6.0_16 Java home: C:\java\jdk1.6.0_16\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.2" arch: "amd64" Family: "windows" Reporter: Ben Tatham Attachments: assemblybug.txt Following these instructions: http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html it used to work fine in Maven 2.2.1 and earlier. With Maven 3.0-alpha-4, see the attached output. -- 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-452) Shared Assembly Descriptor does not work in Maven3-alpha4
[ http://jira.codehaus.org/browse/MASSEMBLY-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200335#action_200335 ] Ben Tatham commented on MASSEMBLY-452: -- Perhaps this issue should be added to: http://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-PluginsMaintainedbytheApacheMavenCommunity > Shared Assembly Descriptor does not work in Maven3-alpha4 > - > > Key: MASSEMBLY-452 > URL: http://jira.codehaus.org/browse/MASSEMBLY-452 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 > Environment: Apache Maven 3.0-alpha-4 (r835944; 2009-11-13 > 13:06:31-0500) > Java version: 1.6.0_16 > Java home: C:\java\jdk1.6.0_16\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.2" arch: "amd64" Family: "windows" >Reporter: Ben Tatham > Attachments: assemblybug.txt > > > Following these instructions: > http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html > it used to work fine in Maven 2.2.1 and earlier. > With Maven 3.0-alpha-4, see the attached output. -- 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: (MCOMPILER-113) Depenent classes end up in target/classes
Depenent classes end up in target/classes - Key: MCOMPILER-113 URL: http://jira.codehaus.org/browse/MCOMPILER-113 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) Java version: 1.6.0_17 Java home: C:\java\jdk1.6.0_17\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.2" arch: "amd64" Family: "windows" Reporter: Ben Tatham Some extra classes from dependent jars end up in target/classes, and consequently the project artifact jar. Specifically, javax.servlet, from servlet-api:2.4 gets added. This is specified as a provided scope, but even if provided is removed, it still happens. Also reported by others on maven-users list: http://www.mail-archive.com/us...@maven.apache.org/msg101503.html I also tried maven-compiler-plugin:2.1, and with maven 2.2.1. Same results. Adding excludes to maven-compiler-plugin does not stop it from happening (I assume because the classes are not being built by the compiler (b/c not in src/main/java), and so excludes does not apply to them. For now, I've excluded them from the artifact in the maven-jar-plugin: javax\** -- 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-4677) Plugin configuration incorrectly inherited from parent pom
Plugin configuration incorrectly inherited from parent pom
--
Key: MNG-4677
URL: http://jira.codehaus.org/browse/MNG-4677
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0-beta-1
Reporter: Ben Tatham
Until 3.0-beta-1 this was working correctly, but now when I run
release:perform, it runs the goals from the un-inherited plugin configuration
instead of the one in pluginManagement that should be inherited.
In this example, the release plugin on the project should run goals: "deploy
nmx-pom:dependency", but instead it is running "deploy nmx-pom:parent". The
latter is what the parent pom project itself runs on release.
It seems that maven is now ignoring the false flag, at
least in some cases.
This is confirmed by the effective pom as well (see below). Note that the
effective pom in m2eclipse (that must still use the embedded maven instead of
the external one I setup in Eclipse Preferences) has it correct.
The release goals are all setup by the parent pom, which contains this:
...
org.apache.maven.plugins
maven-release-plugin
2.0-beta-9
true
http://svn/repos/libraries/java/${project.artifactId}/tags
false
deploy ca.nanometrics.maven:nmx-pom-plugin:dependency
-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}
org.apache.maven.plugins
maven-release-plugin
2.0-beta-9
false
http://svn/repos/tools/maven/common-pom/tags
false
deploy
ca.nanometrics.maven:nmx-pom-plugin:${nmx-pom-plugin.version}:parent
-Dpom.update.skip=${pom.update.skip}
-Dhudson.url=${hudson.url}
-Dhudson.jobName=${hudson.jobName}
-Dhudson.buildNumber=${hudson.buildNumber}
The effective pom of the project itself, using 3.0-beta-1 has:
...
maven-release-plugin
2.0-beta-9
true
http://svn/repos/libraries/java/apollo-workstation/tags
false
deploy ca.nanometrics.maven:nmx-pom-plugin:dependency
-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName= -Dhudson.buildNumber=
maven-release-plugin
2.0-beta-9
false
http://svn/repos/libraries/java/apollo/workstation/tags
false
deploy ca.nanometrics.maven:nmx-pom-plugin:1.3.3:parent
-Dpom.update.skip=false -Dhudson.url=
-Dhudson.jobName=
-Dhudson.buildNumber=
...
--
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: (MSOURCES-13) No-Forking mojos for use within a POM instead of CLI
[ http://jira.codehaus.org/browse/MSOURCES-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166423#action_166423 ] Ben Tatham commented on MSOURCES-13: I agree -- add it already. But perhaps I'm biased. :) > No-Forking mojos for use within a POM instead of CLI > > > Key: MSOURCES-13 > URL: http://jira.codehaus.org/browse/MSOURCES-13 > Project: Maven 2.x Source Plugin > Issue Type: Improvement >Affects Versions: 2.0.3 > Environment: ALL >Reporter: Ben Tatham > Fix For: 2.1 > > Attachments: nofork.patch, nofork.patch > > > The exiting jar at test-jar mojos will always cause a lifecycle fork and > generate-sources. This can cause all kinds of undesired side effects when > using the source plugin with a pom, instead of CLI. I propose a simple fix > (patch attached) to extend these two mojos in no-forking mode. I can't think > of a better name for them. > This behaviour is similar to the difference between assembly:assembly and > assembly:attached. -- 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: (MRELEASE-434) Assumes scm.url is Current Directory for Remote Tagging
Assumes scm.url is Current Directory for Remote Tagging --- Key: MRELEASE-434 URL: http://jira.codehaus.org/browse/MRELEASE-434 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-9 Reporter: Ben Tatham With the addition of remoteTagging=true, based on the testing I have done, the release plugin is doing a remote tag of the url defined in the scm.url property, which I think comes from developerConnection. If this is incorrect, and that url doesn't exist, than it fails. If this is incorrect, and the url does exist, then the user will get unexpected results, not to mention that you just ran the tests against something different than what will be released (although they will be run again at release:perform) Is this the intended behaviour? Or is my testing taking me to the wrong conclusions? -- 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: (MSOURCES-44) If project doesn't contain sources (contains only test sources) source:jar will fail
[ http://jira.codehaus.org/browse/MSOURCES-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MSOURCES-44: --- Attachment: failOnEmpty.patch Here is a simple patch to provide a "failOnEmpty" parameter that can be set to false to skip ArchiverException. I could not see a simple way to check if no files are specified before calling the archiver, or to check that this is the reason for the ArchiverException. But it works for me. Note: Must set attach=false to avoid trying to install/deploy a file that does not exist. > If project doesn't contain sources (contains only test sources) source:jar > will fail > > > Key: MSOURCES-44 > URL: http://jira.codehaus.org/browse/MSOURCES-44 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: WinXp SP3, Cygwin >Reporter: Bugittaa Pahasti > Attachments: failOnEmpty.patch > > > We are running all of our CI builds with the release profile so that javadocs > and sources are generated. However, one module in a multi-module build > contains only test sources. After updating from 2.0.4 to 2.1 the build will > fail. The same error occurs when source:jar is run manually. Below is the > stack trace from jar:source. It might be intentional that the build will fail > in case source:jar is run from command line, but when using release profile > the failure is quite problematic. > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error creating source archive: You must set at least one file. > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error creating source > archive: You must set at least one file. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > 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: Error creating > source archive: You must set at least one file. > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:285) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:232) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:201) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 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:260) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) > at > org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673) > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:543) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:277) > ... 20 more -- This message is a
[jira] Commented: (MSOURCES-44) If project doesn't contain sources (contains only test sources) source:jar will fail
[ http://jira.codehaus.org/browse/MSOURCES-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174132#action_174132 ] Ben Tatham commented on MSOURCES-44: We have the same issue, with some test-less projects (like parent pom projects, that are themselves a child pom of our overall company pom that says to create source and test-source jars for all projects, using no-fork goals). > If project doesn't contain sources (contains only test sources) source:jar > will fail > > > Key: MSOURCES-44 > URL: http://jira.codehaus.org/browse/MSOURCES-44 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: WinXp SP3, Cygwin >Reporter: Bugittaa Pahasti > > We are running all of our CI builds with the release profile so that javadocs > and sources are generated. However, one module in a multi-module build > contains only test sources. After updating from 2.0.4 to 2.1 the build will > fail. The same error occurs when source:jar is run manually. Below is the > stack trace from jar:source. It might be intentional that the build will fail > in case source:jar is run from command line, but when using release profile > the failure is quite problematic. > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error creating source archive: You must set at least one file. > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error creating source > archive: You must set at least one file. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > 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: Error creating > source archive: You must set at least one file. > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:285) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:232) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:201) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > ... 16 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:260) > at > org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) > at > org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673) > at > org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:543) > at > org.apache.maven.plugin.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:277) > ... 20 more -- 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] [Created] (MSHARED-664) Add ico files to default non-filtered extentions
Ben Tatham created MSHARED-664: -- Summary: Add ico files to default non-filtered extentions Key: MSHARED-664 URL: https://issues.apache.org/jira/browse/MSHARED-664 Project: Maven Shared Components Issue Type: Improvement Reporter: Ben Tatham Currently, by default, the following common image/binary file types are non-filtered by default. * jpg,jpeg,gif,bmp,png We should add ico files to this list as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MPH-124) Show parameter aliases in Describe.
Ben Tatham created MPH-124:
--
Summary: Show parameter aliases in Describe.
Key: MPH-124
URL: https://issues.apache.org/jira/browse/MPH-124
Project: Maven Help Plugin
Issue Type: Improvement
Reporter: Ben Tatham
{{mvn help:describe -Ddetail}} should show the alias as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] (MDEPLOY-144) retry failed deploy does not work on wagon authentication errors
Ben Tatham created MDEPLOY-144:
--
Summary: retry failed deploy does not work on wagon authentication
errors
Key: MDEPLOY-144
URL: https://jira.codehaus.org/browse/MDEPLOY-144
Project: Maven 2.x and 3.x Deploy Plugin
Issue Type: Improvement
Components: deploy:deploy
Affects Versions: 2.7
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\tools\maven\apache-maven-3.0.4
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\tools\Java\jdk1.6.0_29\jre
Default locale: en_CA, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Ben Tatham
Priority: Minor
I have increased the retryFailedDeploymentCount to 10, which does work when I
have seen the upload timeout.
But when webdav wagon returns 401, it does not retry. I can understand why it
wouldn't do that (in most cases, it would just fail again, like if you get a
400 due to the artifact already existing in Nexus, and even most authentication
failures), but allow me to explain the scenario.
Why I want it to retry:
Oddly, our Nexus installation occasionally fails to properly authenticate (our
IT people say its due to some difference in ActiveDirectory on WindowsServer
2008 from 2000, and Nexus LDAP does it the 2000 way).
This is very annoying, because it will fail almost always on the 2nd or 3rd
artifact to upload during deployment, which means to properly deploy the
release, we have to either delete the already uploaded artifacts for that
release from Nexus, or do manual deploy-file/via nexus ui of the remaining
artifacts.
I have looked at the code to try and create a patch, but its been hard to piece
together the code paths, as it looks like it depends on the maven installation,
not the dependency hierarchy of maven-deploy-plugin. Specifically, my guess it
is handled inside artifact-manager.
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put
[INFO] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project events: Failed to deploy artifacts: Could not transfer artifact
ca.nanometrics:events:jar:1.1.7 from/to releases
(http://{removed}/nexus/content/repositories/releases): Failed to transfer
file:
http://{removed}/nexus/content/repositories/releases/ca/nanometrics/events/1.1.7/events-1.1.7.jar.
Return code is: 401, ReasonPhrase:Unauthorized. -> [Help 1]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-144) retry failed deploy does not work on wagon authentication errors
[
https://jira.codehaus.org/browse/MDEPLOY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=290712#comment-290712
]
Ben Tatham commented on MDEPLOY-144:
Note that one solution to this issue at a higher level would be to do a single
authentication with Nexus for all the artifacts to be deployed (all-or-nothing
upload of that version). I'm not sure if that's even possible though, without
changes to Nexus itself.
> retry failed deploy does not work on wagon authentication errors
>
>
> Key: MDEPLOY-144
> URL: https://jira.codehaus.org/browse/MDEPLOY-144
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 2.7
> Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: C:\tools\maven\apache-maven-3.0.4
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\tools\Java\jdk1.6.0_29\jre
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Ben Tatham
>Priority: Minor
>
> I have increased the retryFailedDeploymentCount to 10, which does work when I
> have seen the upload timeout.
> But when webdav wagon returns 401, it does not retry. I can understand why
> it wouldn't do that (in most cases, it would just fail again, like if you get
> a 400 due to the artifact already existing in Nexus, and even most
> authentication failures), but allow me to explain the scenario.
> Why I want it to retry:
> Oddly, our Nexus installation occasionally fails to properly authenticate
> (our IT people say its due to some difference in ActiveDirectory on
> WindowsServer 2008 from 2000, and Nexus LDAP does it the 2000 way).
> This is very annoying, because it will fail almost always on the 2nd or 3rd
> artifact to upload during deployment, which means to properly deploy the
> release, we have to either delete the already uploaded artifacts for that
> release from Nexus, or do manual deploy-file/via nexus ui of the remaining
> artifacts.
> I have looked at the code to try and create a patch, but its been hard to
> piece together the code paths, as it looks like it depends on the maven
> installation, not the dependency hierarchy of maven-deploy-plugin.
> Specifically, my guess it is handled inside artifact-manager.
> org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.put
> [INFO] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project events: Failed to deploy artifacts: Could not transfer artifact
> ca.nanometrics:events:jar:1.1.7 from/to releases
> (http://{removed}/nexus/content/repositories/releases): Failed to transfer
> file:
> http://{removed}/nexus/content/repositories/releases/ca/nanometrics/events/1.1.7/events-1.1.7.jar.
> Return code is: 401, ReasonPhrase:Unauthorized. -> [Help 1]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5405) Execute goal does not passes from mojos.xml pluginMetadata
Ben Tatham created MNG-5405: --- Summary: Execute goal does not passes from mojos.xml pluginMetadata Key: MNG-5405 URL: https://jira.codehaus.org/browse/MNG-5405 Project: Maven 2 & 3 Issue Type: Bug Components: Plugin API Affects Versions: 3.0.4 Reporter: Ben Tatham In pluginMetadata (.mojos.xml) that describes an ant-based plugin, adding foo:bar Doesn't make its way in to the plugin.xml. I tracked down the bug to a missing setter in: maven-plugin-tools-model-3.2 org.apache.maven.plugin.tools.model.PluginMetadataParser line 131 When copying the LifecycleExecution out of the Mojo into the MojoDescriptor, it sets the execution lifecycle and phase, but skips the goal. Trivial fix, not even worth a path, imho. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5405) Execute goal does not passes from mojos.xml pluginMetadata
[ https://jira.codehaus.org/browse/MNG-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Tatham updated MNG-5405: Attachment: MNG-5405.patch Here is the simple patch for this bug. Hopefully, we can get it released soon... > Execute goal does not passes from mojos.xml pluginMetadata > -- > > Key: MNG-5405 > URL: https://jira.codehaus.org/browse/MNG-5405 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugin API >Affects Versions: 3.0.4 >Reporter: Ben Tatham > Attachments: MNG-5405.patch > > > In pluginMetadata (.mojos.xml) that describes an ant-based plugin, > adding > > foo:bar > > Doesn't make its way in to the plugin.xml. > I tracked down the bug to a missing setter in: > maven-plugin-tools-model-3.2 > org.apache.maven.plugin.tools.model.PluginMetadataParser > line 131 > When copying the LifecycleExecution out of the Mojo into the MojoDescriptor, > it sets the execution lifecycle and phase, but skips the goal. > Trivial fix, not even worth a path, imho. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
