[jira] Updated: (MNG-4904) Make MavenExecutionResult.getTopologicallySortedProjects() return empty list instead of null
[ http://jira.codehaus.org/browse/MNG-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Basil James Whitehouse III updated MNG-4904: Attachment: MNG-4904.patch Git patch based on git://github.com/apache/maven-3.git . Test and javadoc supplied. > Make MavenExecutionResult.getTopologicallySortedProjects() return empty list > instead of null > > > Key: MNG-4904 > URL: http://jira.codehaus.org/browse/MNG-4904 > Project: Maven 2 & 3 > Issue Type: Improvement >Reporter: Basil James Whitehouse III > Attachments: MNG-4904.patch > > > MavenExecutionResult.getTopologicallySortedProjects() returns null when there > are no projects forcing consumers to perform null checks. Consider returning > an empty collection instead. -- 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-4904) Make MavenExecutionResult.getTopologicallySortedProjects() return empty list instead of null
Make MavenExecutionResult.getTopologicallySortedProjects() return empty list instead of null Key: MNG-4904 URL: http://jira.codehaus.org/browse/MNG-4904 Project: Maven 2 & 3 Issue Type: Improvement Reporter: Basil James Whitehouse III MavenExecutionResult.getTopologicallySortedProjects() returns null when there are no projects forcing consumers to perform null checks. Consider returning an empty collection instead. -- 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-4643) [regression] Transitive dependency not available due to dependency POM erroneously rejected as invalid
[ http://jira.codehaus.org/browse/MNG-4643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231498#action_231498 ] Basil James Whitehouse III commented on MNG-4643: - FYI a fix to Apache FTP server has been filed (and resolved): https://issues.apache.org/jira/browse/FTPSERVER-382 And a request made to fix the poms in Central: http://jira.codehaus.org/browse/MEV-669 > [regression] Transitive dependency not available due to dependency POM > erroneously rejected as invalid > -- > > Key: MNG-4643 > URL: http://jira.codehaus.org/browse/MNG-4643 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0-alpha-7, 3.0-beta-1 > Environment: linux >Reporter: Francis De Brabandere >Assignee: Benjamin Bentmann > Fix For: 3.0-beta-2 > > Attachments: testbrokendep.tar.gz, testbrokendep.zip > > > I depend on apache ftpserver for my tests. But somehow since 3.0-beta-1 the > transitive apache mina dependency is not available in the test classpath any > more > See the provided project. This code works on maven 2.x and also worked with > 3.x versions until 3.0-alpha-7. But with beta 1 this build fails with class > not found. > Apache Maven 3.0-beta-1 (r935667; 2010-04-19 19:00:39+0200) > Java version: 1.6.0_16 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.16/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.31-20-generic" arch: "i386" Family: "unix" -- 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: (MEV-669) ftpserver-parent pom contains invalid character preventing parsing with Maven 3
ftpserver-parent pom contains invalid character preventing parsing with Maven 3 --- Key: MEV-669 URL: http://jira.codehaus.org/browse/MEV-669 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Basil James Whitehouse III This affects all current 1.0.x versions. I've filed https://issues.apache.org/jira/browse/FTPSERVER-382 for an upstream fix and there is a workaround but fixing the data in central would be nice for new downloads (or those that want to refresh their internal repos). -- 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-464) assembly descriptor id should be mandatory
[
http://jira.codehaus.org/browse/MASSEMBLY-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208494#action_208494
]
Basil James Whitehouse III commented on MASSEMBLY-464:
--
Impossible is an exgaration. Not expected, yes; and difficult for Nexus and
other repo managers to index, yes
([NEXUS-3158|https://issues.sonatype.org/browse/NEXUS-3158]). A project can
still depend on one of these assemblies and it will download the zip from the
repo (even a Nexus repo) provided the type is defined.
I
[posted|http://old.nabble.com/Missing-search-results-with-assembly-attached-artifacts-td26581535ef34835.html#a26581535]
about this on the Nexus mailing list too.
Based on the examples from the above thread if you add this dependency:
{code:xml}
com.example.maven
zip-distribution-packaging-pom
1.0.0-SNAPSHOT
zip
{code}
The zip will be downloaded.
Also note that there's currently an option to [exclude the assemblyId from the
final
name|http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#appendAssemblyId]
which conflict with this issue.
The use case I have is to create a distribution bundle in a multi-module build.
There is a separate module to create this assembly and from an esthetic's
perspective it's redundant to add a classifier to the filename. If there were
a packaging type of 'zip' I'd use that instead and AFAIK that would be more
correct from a maven coordinates perspective and probably indexed correctly by
Nexus.
> assembly descriptor id should be mandatory
> --
>
> Key: MASSEMBLY-464
> URL: http://jira.codehaus.org/browse/MASSEMBLY-464
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
>Reporter: Juven Xu
>
> I can create assembly using descriptor like this:
> {code:xml}
>
>
>
> zip
>
>
>
> src/main/java
>
>
>
> {code}
> the file created does not have a classifier, and it's not the main artifact
> either, so it's impossible to locate it using maven coordinates.
> the id should be mandatory so there will always a classifier.
--
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-4520) TOTSP GWT plugin fails to build GWT apps with Maven 3
[ http://jira.codehaus.org/browse/MNG-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Basil James Whitehouse III updated MNG-4520: Attachment: pom-for-codehaus-gwt.xml > TOTSP GWT plugin fails to build GWT apps with Maven 3 > - > > Key: MNG-4520 > URL: http://jira.codehaus.org/browse/MNG-4520 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-alpha-5 > Environment: $ mvn3 --version > Apache Maven 3.0-alpha-6 (r896384; 2010-01-06 06:00:46-0500) > Java version: 1.6.0_14 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.14/jre > Default locale: en_CA, platform encoding: UTF-8 > OS name: "linux" version: "2.6.27-16-generic" arch: "i386" Family: "unix" > AND > $ mvn --version > Maven version: 2.0.9 > Java version: 1.6.0_14 > OS name: "linux" version: "2.6.27-16-generic" arch: "i386" Family: "unix" >Reporter: Basil James Whitehouse III > Attachments: m3-gwt-example.zip, pom-for-codehaus-gwt.xml > > > The attached sample project builds successfully with Maven 2.0.9 but fails > with Maven 3.0-alpha-5. Note I got the same results with the [staged > 3.0-alpha-6|https://repository.apache.org/content/repositories/maven-014/org/apache/maven/apache-maven/3.0-alpha-6/] > which is used to produce the log in the sample. I've attached logs for > running with Maven 2.0.9 and Maven 3 alpha. > I used separate local repos for building with Maven 2 & 3 to isolate > artifacts. > I'm using a feature of the gwt plugin to automatically setup the GWT tools to > compile the source. This downloads the platform specific archive, extracts > it to the target directory, and then invokes GWTs platform specific complier. > Under Maven 2 the gwt plugin goal of setup adds the platform specific gwt > archive to the dependencies for the next extractGwt goal to locate and > extract the gwt build tools. Under Maven 3 I don't see this same dependency > being added. > I know there are newer versions of this plugin and the Codehaus one > supersedes it, but I can't change the project at this point. > To run you'll need to add the repo and plugin repo to the pom or settings.xml > (or repo manager): > http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/ > *Maven 2* > $ mvn -X --batch-mode -Dmaven.repo.local=$(pwd)/repos/m2-gwt-plugin clean > install | tee mvn2-build.output > > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 28 seconds > [INFO] Finished at: Wed Jan 06 11:57:44 EST 2010 > [INFO] Final Memory: 18M/128M > [INFO] > > *Maven 3* > $ mvn3 -X --batch-mode -Dmaven.repo.local=$(pwd)/repos/m3-gwt-plugin clean > install | tee mvn3-build.output > > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.924s > [INFO] Finished at: Wed Jan 06 11:58:59 EST 2010 > [INFO] Final Memory: 4M/81M > [INFO] > > [ERROR] Failed to execute goal > com.totsp.gwt:maven-googlewebtoolkit2-plugin:2.0-beta15:extractGwt > (compile-gwt) on project maven3-gwt-example: Error: Could not load GWT > artifact. Make sure you have the setup goal enabled for this plugin or that > you have setup a dependency on com.google.gwt:gwt-linux -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal com.totsp.gwt:maven-googlewebtoolkit2-plugin:2.0-beta15:extractGwt > (compile-gwt) on project maven3-gwt-example: Error: Could not load GWT > artifact. Make sure you have the setup goal enabled for this plugin or that > you have setup a dependency on com.google.gwt:gwt-linux > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:422) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:122) > 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
[jira] Commented: (MNG-4520) TOTSP GWT plugin fails to build GWT apps with Maven 3
[ http://jira.codehaus.org/browse/MNG-4520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205618#action_205618 ] Basil James Whitehouse III commented on MNG-4520: - Olivier, the totsp plugin has been merged into the codehaus one and you are correct in that the version that I cited is no longer supported. Unfortunately there are several large GWT projects that don't have the bandwidth to change and verify the switch at the moment (some being in maintenance only mode). I filed this to highlight an incompatible change between Maven 2 and Maven 3 but I understand if it won't be fixed if the codehaus plugin works correctly. FWIW I tested the same project with Maven 3-alpha5 and the Codehaus GWT plugin version 1.1 and it build successfully with minor pom modifications required. This project is only the sample one that comes with GWT so I don't expect it to be exhaustive but a good sign none-the-less. I've attached the pom for this for future reference. > TOTSP GWT plugin fails to build GWT apps with Maven 3 > - > > Key: MNG-4520 > URL: http://jira.codehaus.org/browse/MNG-4520 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-alpha-5 > Environment: $ mvn3 --version > Apache Maven 3.0-alpha-6 (r896384; 2010-01-06 06:00:46-0500) > Java version: 1.6.0_14 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.14/jre > Default locale: en_CA, platform encoding: UTF-8 > OS name: "linux" version: "2.6.27-16-generic" arch: "i386" Family: "unix" > AND > $ mvn --version > Maven version: 2.0.9 > Java version: 1.6.0_14 > OS name: "linux" version: "2.6.27-16-generic" arch: "i386" Family: "unix" >Reporter: Basil James Whitehouse III > Attachments: m3-gwt-example.zip > > > The attached sample project builds successfully with Maven 2.0.9 but fails > with Maven 3.0-alpha-5. Note I got the same results with the [staged > 3.0-alpha-6|https://repository.apache.org/content/repositories/maven-014/org/apache/maven/apache-maven/3.0-alpha-6/] > which is used to produce the log in the sample. I've attached logs for > running with Maven 2.0.9 and Maven 3 alpha. > I used separate local repos for building with Maven 2 & 3 to isolate > artifacts. > I'm using a feature of the gwt plugin to automatically setup the GWT tools to > compile the source. This downloads the platform specific archive, extracts > it to the target directory, and then invokes GWTs platform specific complier. > Under Maven 2 the gwt plugin goal of setup adds the platform specific gwt > archive to the dependencies for the next extractGwt goal to locate and > extract the gwt build tools. Under Maven 3 I don't see this same dependency > being added. > I know there are newer versions of this plugin and the Codehaus one > supersedes it, but I can't change the project at this point. > To run you'll need to add the repo and plugin repo to the pom or settings.xml > (or repo manager): > http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/ > *Maven 2* > $ mvn -X --batch-mode -Dmaven.repo.local=$(pwd)/repos/m2-gwt-plugin clean > install | tee mvn2-build.output > > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 28 seconds > [INFO] Finished at: Wed Jan 06 11:57:44 EST 2010 > [INFO] Final Memory: 18M/128M > [INFO] > > *Maven 3* > $ mvn3 -X --batch-mode -Dmaven.repo.local=$(pwd)/repos/m3-gwt-plugin clean > install | tee mvn3-build.output > > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.924s > [INFO] Finished at: Wed Jan 06 11:58:59 EST 2010 > [INFO] Final Memory: 4M/81M > [INFO] > > [ERROR] Failed to execute goal > com.totsp.gwt:maven-googlewebtoolkit2-plugin:2.0-beta15:extractGwt > (compile-gwt) on project maven3-gwt-example: Error: Could not load GWT > artifact. Make sure you have the setup goal enabled for this plugin or that > you have setup a dependency on com.google.gwt:gwt-linux -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal com.totsp.gwt:maven-googlewebtoolkit2-plugin:2.0-beta15:extractGwt > (compile-gwt) on project maven3-gwt-example: Error: Could not load GWT > artifact. Make sure you have the setup goal enabled for this plugin or that > you have setup a dependency on com.google.gwt:gwt-linux > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec
[jira] Created: (MNG-4520) TOTSP GWT plugin fails to build GWT apps with Maven 3
TOTSP GWT plugin fails to build GWT apps with Maven 3 - Key: MNG-4520 URL: http://jira.codehaus.org/browse/MNG-4520 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0-alpha-5 Environment: $ mvn3 --version Apache Maven 3.0-alpha-6 (r896384; 2010-01-06 06:00:46-0500) Java version: 1.6.0_14 Java home: /usr/lib/jvm/java-6-sun-1.6.0.14/jre Default locale: en_CA, platform encoding: UTF-8 OS name: "linux" version: "2.6.27-16-generic" arch: "i386" Family: "unix" AND $ mvn --version Maven version: 2.0.9 Java version: 1.6.0_14 OS name: "linux" version: "2.6.27-16-generic" arch: "i386" Family: "unix" Reporter: Basil James Whitehouse III Attachments: m3-gwt-example.zip The attached sample project builds successfully with Maven 2.0.9 but fails with Maven 3.0-alpha-5. Note I got the same results with the [staged 3.0-alpha-6|https://repository.apache.org/content/repositories/maven-014/org/apache/maven/apache-maven/3.0-alpha-6/] which is used to produce the log in the sample. I've attached logs for running with Maven 2.0.9 and Maven 3 alpha. I used separate local repos for building with Maven 2 & 3 to isolate artifacts. I'm using a feature of the gwt plugin to automatically setup the GWT tools to compile the source. This downloads the platform specific archive, extracts it to the target directory, and then invokes GWTs platform specific complier. Under Maven 2 the gwt plugin goal of setup adds the platform specific gwt archive to the dependencies for the next extractGwt goal to locate and extract the gwt build tools. Under Maven 3 I don't see this same dependency being added. I know there are newer versions of this plugin and the Codehaus one supersedes it, but I can't change the project at this point. To run you'll need to add the repo and plugin repo to the pom or settings.xml (or repo manager): http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/ *Maven 2* $ mvn -X --batch-mode -Dmaven.repo.local=$(pwd)/repos/m2-gwt-plugin clean install | tee mvn2-build.output [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Wed Jan 06 11:57:44 EST 2010 [INFO] Final Memory: 18M/128M [INFO] *Maven 3* $ mvn3 -X --batch-mode -Dmaven.repo.local=$(pwd)/repos/m3-gwt-plugin clean install | tee mvn3-build.output [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.924s [INFO] Finished at: Wed Jan 06 11:58:59 EST 2010 [INFO] Final Memory: 4M/81M [INFO] [ERROR] Failed to execute goal com.totsp.gwt:maven-googlewebtoolkit2-plugin:2.0-beta15:extractGwt (compile-gwt) on project maven3-gwt-example: Error: Could not load GWT artifact. Make sure you have the setup goal enabled for this plugin or that you have setup a dependency on com.google.gwt:gwt-linux -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.totsp.gwt:maven-googlewebtoolkit2-plugin:2.0-beta15:extractGwt (compile-gwt) on project maven3-gwt-example: Error: Could not load GWT artifact. Make sure you have the setup goal enabled for this plugin or that you have setup a dependency on com.google.gwt:gwt-linux at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:247) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:104) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:422) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:157) at org.apache.maven.cli.MavenCli.main(MavenCli.java:122) 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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException:
[jira] Commented: (MNG-4368) DefaultArtifactInstaller should only overwrite files if timestamp has changed
[ http://jira.codehaus.org/browse/MNG-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201823#action_201823 ] Basil James Whitehouse III commented on MNG-4368: - I frequently have a similar workflow as Tamás, in my case with short lived bug branches (less than a week) that get incorporated back into the trunk/mainline. I feel the proposed flow to change the version number would expand the workflow unnecessarily. Note that these branches aren't used by other developers, merely as a location for me to commit, test, refactor, and reintegrate with the mainline when ready. I run clean install before integrating to ensure the branch and trunk is buildable. I have used the versions plugin and it's very useful, but in this case the flow works well (in Maven 2.2.1) without requiring me to switch the version when I create the branch, and switch it back when I merge into the mainline. > DefaultArtifactInstaller should only overwrite files if timestamp has changed > - > > Key: MNG-4368 > URL: http://jira.codehaus.org/browse/MNG-4368 > Project: Maven 2 > Issue Type: Improvement > Environment: Linux, JDK 1.5 >Reporter: Johannes Martin > Fix For: 2.2.2, 3.0-alpha-3 > > > install:install (from maven-install-plugin) by default uses > DefaultArtifactInstaller to install artifacts. DefaultArtifactInstaller in > turn uses FileUtils.copyFile(), thereby overwriting destination files even if > they are unchanged. It would be helpful if DefaultArtifactInstaller used > FileUtils.copyFileIfModified() instead, at least as an option, to speed up > the build process. -- 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-4233) Artifact does not get resolved from the reactor
[
http://jira.codehaus.org/browse/MNG-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187794#action_187794
]
Basil James Whitehouse III commented on MNG-4233:
-
This is with:
$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_14
OS name: "linux" version: "2.6.28-15-generic" arch: "i386" Family: "unix"
> Artifact does not get resolved from the reactor
> ---
>
> Key: MNG-4233
> URL: http://jira.codehaus.org/browse/MNG-4233
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 2.0.6, 2.0.9, 2.0.10, 2.1.0, 2.2.0
>Reporter: Oran Kelly
> Attachments: test-case.tar.gz
>
>
> This issue is directly related to MNG-2877. That issue is marked as fixed in
> 2.0.6. However, I have a project which does pretty much what MNG-2877
> describes (a sub-project using maven-dependency-plugin to unpack a jar
> created at an earlier stage in the reactor) and it is not working.
> I have attached a simple project structure which displays the issue. I have
> tested this with Maven 2.0.6, 2.0.9, 2.0.10, 2.1.0 and 2.2.0 and it fails in
> them all.
> I build this test project structure using:
> rm -fr $HOME/.m2/repository/maven/test
> mvn clean verify
> (Using "clean verify" as this is what release:prepare does and is how I ran
> in to the problem).
> The output from this run is
> {noformat}
> [INFO] Scanning for projects...
> [WARNING]
> Profile with id: 'dev' has not been activated.
> [INFO] Reactor build order:
> [INFO] Test Module
> [INFO] Test Module Core
> [INFO] Test Module Dep
> [INFO]
>
> [INFO] Building Test Module
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO]
>
> [INFO] Building Test Module Core
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /home/user/tmp/test-case/core/src/main/resources
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 1 source file to /home/user/tmp/test-case/core/target/classes
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /home/user/tmp/test-case/core/src/test/resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] No sources to compile
> [INFO] [surefire:test {execution: default-test}]
> [INFO] No tests to run.
> [INFO] [jar:jar {execution: default-jar}]
> [INFO] Building jar:
> /home/user/tmp/test-case/core/target/core-1.0.0-SNAPSHOT.jar
> [INFO]
>
> [INFO] Building Test Module Dep
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /home/user/tmp/test-case/dep/src/main/resources
> [INFO] [dependency:unpack {execution: unpack}]
> [INFO] Configured Artifact: maven.test:core:1.0.0-SNAPSHOT:jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: maven.test
> ArtifactId: core
> Version: 1.0.0-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=maven.test -DartifactId=core
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=maven.test -DartifactId=core
> -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url]
> -DrepositoryId=[id]
> mav
[jira] Commented: (MNG-4233) Artifact does not get resolved from the reactor
[
http://jira.codehaus.org/browse/MNG-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187793#action_187793
]
Basil James Whitehouse III commented on MNG-4233:
-
I just verified that that this worked by:
* downloading the attached test case
* running as described
* getting the same error
* change the dep/pom.xml to use {{unpack-dependencies}} instead of {{unpack}}
* run again as described (including the rm of the local repo)
* no error, see log below
{code}
$ rm -fr $HOME/.m2/repository/maven/test
$ mvn clean verify
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Test Module
[INFO] Test Module Core
[INFO] Test Module Dep
[INFO]
[INFO] Building Test Module
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO]
[INFO] Building Test Module Core
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/basil/downloads/test-case/core/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to
/home/basil/downloads/test-case/core/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[INFO] Building jar:
/home/basil/downloads/test-case/core/target/core-1.0.0-SNAPSHOT.jar
[INFO]
[INFO] Building Test Module Dep
[INFO]task-segment: [clean, verify]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory /home/basil/downloads/test-case/dep/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [dependency:unpack-dependencies {execution: unpack}]
[INFO] Unpacking
/home/basil/downloads/test-case/core/target/core-1.0.0-SNAPSHOT.jarto
/home/basil/downloads/test-case/dep/target/dependency
with Includes null and excludes:null
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/home/basil/downloads/test-case/dep/target/dep-1.0.0-SNAPSHOT.jar
[INFO]
[INFO]
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Test Module ... SUCCESS [2.871s]
[INFO] Test Module Core .. SUCCESS [2.184s]
[INFO] Test Module Dep ... SUCCESS [3.673s]
[INFO]
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 9 seconds
[INFO] Finished at: Thu Aug 20 15:06:58 GMT 2009
[INFO] Final Memory: 18M/36M
[INFO]
{code}
> Artifact does not get resolved from the reactor
> ---
>
> Key: MNG-4233
> URL: http://jira.codehaus.org/browse/MNG-4233
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 2.0.6, 2.0.9, 2.0.10, 2.1.0, 2.2.0
>Reporter: Oran Kelly
> Attachments: test-case.tar.gz
>
>
> This issue is directly related to MNG-2877. That issue is marked as fixed in
> 2.0.6. However, I have a project which does pretty much what MNG-2877
> describes (a sub-project using maven-dependency-plugin to unpack a jar
> created at an earlier stage in the reactor) and it is not working.
> I have attached a simple project structure which displays the issue. I have
> tested this with Maven 2.0.6, 2.0.9, 2.0.10, 2.1.0 and 2.2.0 and it fails in
> them all.
> I build this test project structure using:
> rm -fr $HOME/.m2/repository/maven/test
> mvn clean verify
> (Using "clean verify" as this is what release:prepare does and is how I ran
> in to the problem).
> The output from this run is
>
[jira] Commented: (MNG-4233) Artifact does not get resolved from the reactor
[
http://jira.codehaus.org/browse/MNG-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=187790#action_187790
]
Basil James Whitehouse III commented on MNG-4233:
-
I think the problem is in the using dependency:unpack. I had this problem
before and it took some close reading to figure it out. From the unpack goals
documentation: "Goal that retrieves a list of artifacts from the repository and
unpacks them in a defined location." This goal needs to have the artifact in
the local repo. I switched to using dependency:unpack-dependencies since it
works within the reactor/multimodule build.
> Artifact does not get resolved from the reactor
> ---
>
> Key: MNG-4233
> URL: http://jira.codehaus.org/browse/MNG-4233
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 2.0.6, 2.0.9, 2.0.10, 2.1.0, 2.2.0
>Reporter: Oran Kelly
> Attachments: test-case.tar.gz
>
>
> This issue is directly related to MNG-2877. That issue is marked as fixed in
> 2.0.6. However, I have a project which does pretty much what MNG-2877
> describes (a sub-project using maven-dependency-plugin to unpack a jar
> created at an earlier stage in the reactor) and it is not working.
> I have attached a simple project structure which displays the issue. I have
> tested this with Maven 2.0.6, 2.0.9, 2.0.10, 2.1.0 and 2.2.0 and it fails in
> them all.
> I build this test project structure using:
> rm -fr $HOME/.m2/repository/maven/test
> mvn clean verify
> (Using "clean verify" as this is what release:prepare does and is how I ran
> in to the problem).
> The output from this run is
> {noformat}
> [INFO] Scanning for projects...
> [WARNING]
> Profile with id: 'dev' has not been activated.
> [INFO] Reactor build order:
> [INFO] Test Module
> [INFO] Test Module Core
> [INFO] Test Module Dep
> [INFO]
>
> [INFO] Building Test Module
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO]
>
> [INFO] Building Test Module Core
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /home/user/tmp/test-case/core/src/main/resources
> [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 1 source file to /home/user/tmp/test-case/core/target/classes
> [INFO] [resources:testResources {execution: default-testResources}]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /home/user/tmp/test-case/core/src/test/resources
> [INFO] [compiler:testCompile {execution: default-testCompile}]
> [INFO] No sources to compile
> [INFO] [surefire:test {execution: default-test}]
> [INFO] No tests to run.
> [INFO] [jar:jar {execution: default-jar}]
> [INFO] Building jar:
> /home/user/tmp/test-case/core/target/core-1.0.0-SNAPSHOT.jar
> [INFO]
>
> [INFO] Building Test Module Dep
> [INFO]task-segment: [clean, verify]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] [resources:resources {execution: default-resources}]
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> /home/user/tmp/test-case/dep/src/main/resources
> [INFO] [dependency:unpack {execution: unpack}]
> [INFO] Configured Artifact: maven.test:core:1.0.0-SNAPSHOT:jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: maven.test
> ArtifactId: core
> Version: 1.0.0-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=maven.test -DartifactId=core
> -Dversion=1.0.0-SNAPSHOT -Dpac
[jira] Commented: (MRELEASE-313) add an option to set the profile(s) used to perform the release
[ http://jira.codehaus.org/browse/MRELEASE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150511#action_150511 ] Basil James Whitehouse III commented on MRELEASE-313: - Can this profile also be activated when running release:prepare? I have a multi-module project that builds a distribution archive that is only activated by a profile since developers don't normally need it and it's quite large (80 MB) and don't want to occupy space in the local Maven repo. In order for this distribute module to have it's version number changed by the release plugin it needs to be part of the release:prepare . For now I use the performRelease property to activate it, but I'd rather not use that since it could also activate other things I don't normally need. E.g. mvn --batch-mode release:prepare release:perform -DperformRelease > add an option to set the profile(s) used to perform the release > --- > > Key: MRELEASE-313 > URL: http://jira.codehaus.org/browse/MRELEASE-313 > Project: Maven 2.x Release Plugin > Issue Type: Wish >Affects Versions: 2.0-beta-7 >Reporter: nicolas de loof >Assignee: nicolas de loof >Priority: Minor > Fix For: 2.0-beta-8 > > > release:perform runs maven to build the released artifact with the current > active profiles (AFAIK) > It would be nice to have a configuration parameter to set release profiles, > so that it does not depend on user environment. -- 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-285) Unresolved test-jar dependency during release
[
http://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149293#action_149293
]
Basil James Whitehouse III commented on MRELEASE-285:
-
Actually I think this problem runs deeper than just test-jar classifiers.
Other classifiers are broken as well. I've tried this with a project where
there's an EJB client jar (with a classifier of 'client') and that doesn't
work. Using a type of {{ejb-client}} fixed this as well. I'm guessing that
any dependency with a classifier is probably broken.
FYI: the ejb-client issue seems to be different from MRELEASE-129.
> Unresolved test-jar dependency during release
> -
>
> Key: MRELEASE-285
> URL: http://jira.codehaus.org/browse/MRELEASE-285
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: Maven version: 2.0.7
> Java version: 1.5.0_07
> OS name: "mac os x" version: "10.4.10" arch: "i386"
>Reporter: Rod Coffin
> Fix For: 2.0
>
> Attachments: example.jar
>
>
> I have a multi-module project where one project produces a normal jar and a
> test-jar
> (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html).
> Another submodule has a test scoped dependency on the test-jar from the first
> submodule. For example, this is the structure and produced artifacts for a
> small sample (attached) I built to reproduce this behavior:
> release-test-jar (parent project)
> project-with-test-jar (submodule)
> => project-with-test-jar-1.0.jar
> => project-with-test-jar-1.0-tests.jar
> project-using-test-jar (submodule)
> => project-user-test-jar-1.0.jar
> When I run a 'clean install' the build succeeds. However, when I run a
> 'release:prepare' the build fails with the following error:
> 1 required artifact is missing.
> for artifact:
> com.rfc:project-using-test-jar:jar:1.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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.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.artifact.resolver.MultipleArtifactsNotFoundException:
> Missing:
> --
> 1) com.rfc:project-with-test-jar:test-jar:tests:1.1
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.rfc
> -DartifactId=project-with-test-jar \
> -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar
> -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=com.rfc
> -DartifactId=project-with-test-jar \
> -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar
> -Dfile=/path/to/file \
>-Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1) com.rfc:project-using-test-jar:jar:1.1
> 2) com.rfc:project-with-test-jar:test-jar:tests:1.1
> --
> 1 required artifact is missing.
> for artifact:
> com.rfc:project-using-test-jar:jar:1.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
> at
> o
[jira] Commented: (MRELEASE-285) Unresolved test-jar dependency during release
[ http://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149287#action_149287 ] Basil James Whitehouse III commented on MRELEASE-285: - Oddly this issue doesn't happen when running a dry run of release:perform (e.g. mvn release:perform -DdryRun=true). This makes it awkward to verify fixes since a real release:prepare has to be performed and that will modify your poms which have to be reverted if there was a failure. > Unresolved test-jar dependency during release > - > > Key: MRELEASE-285 > URL: http://jira.codehaus.org/browse/MRELEASE-285 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Maven version: 2.0.7 > Java version: 1.5.0_07 > OS name: "mac os x" version: "10.4.10" arch: "i386" >Reporter: Rod Coffin > Fix For: 2.0 > > Attachments: example.jar > > > I have a multi-module project where one project produces a normal jar and a > test-jar > (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html). > Another submodule has a test scoped dependency on the test-jar from the first > submodule. For example, this is the structure and produced artifacts for a > small sample (attached) I built to reproduce this behavior: > release-test-jar (parent project) > project-with-test-jar (submodule) > => project-with-test-jar-1.0.jar > => project-with-test-jar-1.0-tests.jar > project-using-test-jar (submodule) > => project-user-test-jar-1.0.jar > When I run a 'clean install' the build succeeds. However, when I run a > 'release:prepare' the build fails with the following error: > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > 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.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.artifact.resolver.MultipleArtifactsNotFoundException: > Missing: > -- > 1) com.rfc:project-with-test-jar:test-jar:tests:1.1 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=com.rfc > -DartifactId=project-with-test-jar \ > -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.rfc:project-using-test-jar:jar:1.1 > 2) com.rfc:project-with-test-jar:test-jar:tests:1.1 > -- > 1 required artifact is missing. > for artifact: > com.rfc:project-using-test-jar:jar:1.1 > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.m
[jira] Commented: (MRELEASE-285) Unresolved test-jar dependency during release
[
http://jira.codehaus.org/browse/MRELEASE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149283#action_149283
]
Basil James Whitehouse III commented on MRELEASE-285:
-
I found a workaround to this based on an unrelated [hint in this
thread|http://www.mail-archive.com/[EMAIL PROTECTED]/msg79498.html]: instead of
using a classifier use a type of {{test-jar}} in the dependency declaration.
E.g:
{noformat}
com.company.project
core
test-jar
test
{noformat}
> Unresolved test-jar dependency during release
> -
>
> Key: MRELEASE-285
> URL: http://jira.codehaus.org/browse/MRELEASE-285
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
> Environment: Maven version: 2.0.7
> Java version: 1.5.0_07
> OS name: "mac os x" version: "10.4.10" arch: "i386"
>Reporter: Rod Coffin
> Fix For: 2.0
>
> Attachments: example.jar
>
>
> I have a multi-module project where one project produces a normal jar and a
> test-jar
> (http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html).
> Another submodule has a test scoped dependency on the test-jar from the first
> submodule. For example, this is the structure and produced artifacts for a
> small sample (attached) I built to reproduce this behavior:
> release-test-jar (parent project)
> project-with-test-jar (submodule)
> => project-with-test-jar-1.0.jar
> => project-with-test-jar-1.0-tests.jar
> project-using-test-jar (submodule)
> => project-user-test-jar-1.0.jar
> When I run a 'clean install' the build succeeds. However, when I run a
> 'release:prepare' the build fails with the following error:
> 1 required artifact is missing.
> for artifact:
> com.rfc:project-using-test-jar:jar:1.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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.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.artifact.resolver.MultipleArtifactsNotFoundException:
> Missing:
> --
> 1) com.rfc:project-with-test-jar:test-jar:tests:1.1
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.rfc
> -DartifactId=project-with-test-jar \
> -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar
> -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file there:
> mvn deploy:deploy-file -DgroupId=com.rfc
> -DartifactId=project-with-test-jar \
> -Dversion=1.1 -Dclassifier=tests -Dpackaging=test-jar
> -Dfile=/path/to/file \
>-Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1) com.rfc:project-using-test-jar:jar:1.1
> 2) com.rfc:project-with-test-jar:test-jar:tests:1.1
> --
> 1 required artifact is missing.
> for artifact:
> com.rfc:project-using-test-jar:jar:1.1
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:305)
> at
> org.apache.maven.artifact.resolver.DefaultArtifactResolver
[jira] Commented: (MASSEMBLY-144) wont put files in top level directory
[
http://jira.codehaus.org/browse/MASSEMBLY-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=141116#action_141116
]
Basil James Whitehouse III commented on MASSEMBLY-144:
--
I think this has to do with includeBaseDirectory being false and the output
directory being / .
A workaround that I discovered is to set the output directory to . (dot):
{code:xml}
bug-example
zip
false
TODO.txt
.
{code}
> wont put files in top level directory
> -
>
> Key: MASSEMBLY-144
> URL: http://jira.codehaus.org/browse/MASSEMBLY-144
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP using maven 2.0.4. I think I am using
> assembly 2.1 as that is the only version I could find in my ~/.m2 directory.
>Reporter: Alan Kent
>Assignee: John Casey
>Priority: Minor
> Fix For: 2.2-beta-1
>
>
> I am relatively new to Maven so hopefully this is not a silly mistake, but
> the following assembly XML file will NOT include the TODO.txt file. If you
> put the file into a subdirectory (using
> a/b/c or by setting
> true) then the file will appear
> in the ZIP file. This is at least non-intuitive, but feels like a bug to me.
>
> bug-example
>
> zip
>
> false
>
>
> TODO.txt
> /
>
>
>
--
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-2276) profile activation by property doesn't work with properties defined in settings.
[ http://jira.codehaus.org/browse/MNG-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139833#action_139833 ] Basil James Whitehouse III commented on MNG-2276: - Can someone with privileges please add 'Profiles' to the affected components to make it easier for others to find this issue. > profile activation by property doesn't work with properties defined in > settings. > > > Key: MNG-2276 > URL: http://jira.codehaus.org/browse/MNG-2276 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.4 >Reporter: Brian Fox > Fix For: 2.1 > > > Activating a profile like below doesn't get activated unless the property is > set on the CLI. I need to have the property defined in the settings.xml so > it's always set. > > > prod > > > deploy-ct > > > Further, I noticed that if I set it so that the activation is like: > > > deploy-cttrue > > > The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It > is not active if I use "-Ddeploy-ct=false" but the settings descriptor says > that the existence of the property is only used if value is not set. -- 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-3633) Dependency Management Wildcards
[
http://jira.codehaus.org/browse/MNG-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=139812#action_139812
]
Basil James Whitehouse III commented on MNG-3633:
-
Or even to be able to wildcard on the groupid:
org.springframework
*
2.4.5
> Dependency Management Wildcards
> ---
>
> Key: MNG-3633
> URL: http://jira.codehaus.org/browse/MNG-3633
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Reporter: Geoffrey Wiseman
>
> I'd love to have the option of wildcards in dependency management. When
> you're working with a lot of dependencies that share a common version, it's
> really irritating to have to add each one to the dependency management.
> For instance:
> {code:xml}
>
>
>
> org.springframework
> spring-*
> 2.5.4
>
>
>
> {code}
> Instead of:
> {code:xml}
>
> 2.5.4
>
>
>
>
> com.feedroom.feedroom-commons
> common
> 1.2-SNAPSHOT
>
>
> org.springframework
> spring-orm
> ${springVersion}
>
>
> org.springframework
> spring-test
> ${springVersion}
>
>
> org.springframework
> spring-beans
> ${springVersion}
>
>
> org.springframework
> spring-aop
> ${springVersion}
>
>
> org.springframework
> spring-jdbc
> ${springVersion}
>
>
>
> {code}
--
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: (MRESOURCES-39) Filtering fails for command line properties
[ http://jira.codehaus.org/browse/MRESOURCES-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138752#action_138752 ] Basil James Whitehouse III commented on MRESOURCES-39: -- Could someone with privileges mark this as affecting version 2.2 of the resources plugin to make it a bit easier for others to find. > Filtering fails for command line properties > --- > > Key: MRESOURCES-39 > URL: http://jira.codehaus.org/browse/MRESOURCES-39 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Environment: maven-2.0.4 and maven-2.0.5 > Mac OS X >Reporter: Matt Brozowski >Priority: Critical > Fix For: 2.3 > > Attachments: filtering-bug.tar, > maven-resources-plugin-prop-filtering-r630241.patch > > > When passing a property on the command line to maven using -D it does not > properly override values passed to filters. > I have attached a sample project that defines a property in the pom.xml > called 'filtered' This property is used as a filter in the > filtered.properties file in src/main/filtered/filtered.properties. I have > also included a test that gets passed the filtered property as a System > property via the surefire plugin. It then loaded the filtered.properties > file and tests to ensure the filters match. > The tests pass when run as > mvn test > BUT if I run as > mvn -Dfiltered=from-cmd-line teset > They fail. > I have also included the antrun plugin print its perspective on the value of > the property. -- 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: (MCHANGES-111) Announcement Mojo doesn't respect Jira authentication settings
[ http://jira.codehaus.org/browse/MCHANGES-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Basil James Whitehouse III updated MCHANGES-111: Attachment: MCHANGES-111.patch Patch for accessing a JIRA instance that requires authentication, mostly following what was done in the JiraMojo. > Announcement Mojo doesn't respect Jira authentication settings > -- > > Key: MCHANGES-111 > URL: http://jira.codehaus.org/browse/MCHANGES-111 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement >Affects Versions: 2.0 >Reporter: Michael Johns > Attachments: MCHANGES-111.patch > > > The announcement mojo doesn't respect the Jira authentication settings > (jiraUser and jiraPassword). It instantiates a JiraDownloader but never > applies these settings. It should do something like JiraMojo, which calls > setJiraDownloaderParameters() to make sure all values are set. -- 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: (MDEP-161) dependy:resolve-plugins doesn't output to file when using outputFile parameter
dependy:resolve-plugins doesn't output to file when using outputFile parameter
--
Key: MDEP-161
URL: http://jira.codehaus.org/browse/MDEP-161
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: resolve-plugins
Affects Versions: 2.0
Environment: $ mvn --version
Maven version: 2.0.8
Java version: 1.6.0_03
OS name: "linux" version: "2.6.22-14-generic" arch: "i386" Family: "unix"
Reporter: Basil James Whitehouse III
Assignee: Brian Fox
The dependency:tree and dependency:resolve goals output to file when there's an
outputFile parameter. The
[documentation|http://maven.apache.org/plugins/maven-dependency-plugin/resolve-plugins-mojo.html#outputFile|documented]
for resolve-plugins indicates it's possible, but running {{mvn
dependency:resolve-plugins -DoutputFile=plugin-dep.txt}} only outputs to the
console.
--
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: (MRAR-22) Allow filtering of source resources
Allow filtering of source resources Key: MRAR-22 URL: http://jira.codehaus.org/browse/MRAR-22 Project: Maven 2.x Rar Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Basil James Whitehouse III There doesn't appear to be a way to filter the contents of /src/main/rar . This would be very useful to filter the project version into Geronimo specific descriptors (as well as other custom settings). -- 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: (MANTRUN-62) line.separator property not passed properly to ant
[
http://jira.codehaus.org/browse/MANTRUN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106664
]
Basil James Whitehouse III commented on MANTRUN-62:
---
Pardon my ignorance, I missed MANTRUN-40 and MANTRUN-64 which seem to describe
my issue. (Learn to search JIRA istead of using google =)
> line.separator property not passed properly to ant
> --
>
> Key: MANTRUN-62
> URL: http://jira.codehaus.org/browse/MANTRUN-62
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
> Environment: maven 2.0.4
>Reporter: Corporate Gadfly
> Attachments: build.xml, pom.xml
>
>
> line.separator does not resolve properly inside an ant task (using
> maven-antrun-plugin).
> E.g., using the 2 attached files, running
> {code}ant{code} produces the following output {code}Buildfile: build.xml
> echo:
> [echo]
> [echo] line.separator: --
> [echo] --
> [echo] os.name: --Linux--
> [echo]
> BUILD SUCCESSFUL
> Total time: 0 seconds{code}
> which is all okay, so far (new line is being shown on the echo line).
> However, when using {code}mvn initialize{code}, we get the following output
> {code}[INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Maven Echo
> [INFO]task-segment: [initialize]
> [INFO]
>
> [INFO] [antrun:run {execution: echo-no-properties}]
> [INFO] Executing tasks
> echo:
> [echo]
> [echo] line.separator: --${line.separator}--
> [echo] os.name: --${os.name}--
> [echo]
> [INFO] Executed tasks
> [INFO] [antrun:run {execution: echo-with-properties}]
> [INFO] Executing tasks
> echo:
> [echo]
> [echo] line.separator: -- --
> [echo] os.name: --Linux--
> [echo]
> [INFO] Executed tasks
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Tue Nov 21 15:26:55 EST 2006
> [INFO] Final Memory: 3M/508M
> [INFO]
>
> {code}
> I have two questions:
> # Why do I have to specify all the properties one-by-one while calling the
> target?
> # Why is the output for line.separator not what is expected?
--
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: (MANTRUN-62) line.separator property not passed properly to ant
[
http://jira.codehaus.org/browse/MANTRUN-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106663
]
Basil James Whitehouse III commented on MANTRUN-62:
---
This seems similar to my experience. I can't find any documentation or an
issue that precisely captures my issue, but this entry is the closest. Adding
my comment here rather than creating another issue.
I started prototyping delegation to an ant script by writing the ant tasks
inline with the plugins configuration. Once that worked I extracted the ant
code to a separate build.xml and delegated to it using the ant task as
suggested in the plugin documentation: "...it's encouraged to move all your Ant
tasks to a build.xml file and just call it from the POM using Ant's
task.".
Wanting to use Maven as the source of configuration I made heavy use of the
Maven properties (project.build.sourceDirectory, project.build.outputDirectory,
etc). The Maven property reference worked fine when I was using the inlined
task but failed once it was extracted to a build.xml file. I was hoping that
the Maven properties would be passed to the ant build transparently, or as long
as the inhertiAll attribute was true. It surprised me that they weren't and
that I'd have to essentially alias each value I needed, causing a lot of extra
work.
Is it possible to correct this behavior? Am I just missing something?
> line.separator property not passed properly to ant
> --
>
> Key: MANTRUN-62
> URL: http://jira.codehaus.org/browse/MANTRUN-62
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
> Environment: maven 2.0.4
>Reporter: Corporate Gadfly
> Attachments: build.xml, pom.xml
>
>
> line.separator does not resolve properly inside an ant task (using
> maven-antrun-plugin).
> E.g., using the 2 attached files, running
> {code}ant{code} produces the following output {code}Buildfile: build.xml
> echo:
> [echo]
> [echo] line.separator: --
> [echo] --
> [echo] os.name: --Linux--
> [echo]
> BUILD SUCCESSFUL
> Total time: 0 seconds{code}
> which is all okay, so far (new line is being shown on the echo line).
> However, when using {code}mvn initialize{code}, we get the following output
> {code}[INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Maven Echo
> [INFO]task-segment: [initialize]
> [INFO]
>
> [INFO] [antrun:run {execution: echo-no-properties}]
> [INFO] Executing tasks
> echo:
> [echo]
> [echo] line.separator: --${line.separator}--
> [echo] os.name: --${os.name}--
> [echo]
> [INFO] Executed tasks
> [INFO] [antrun:run {execution: echo-with-properties}]
> [INFO] Executing tasks
> echo:
> [echo]
> [echo] line.separator: -- --
> [echo] os.name: --Linux--
> [echo]
> [INFO] Executed tasks
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Tue Nov 21 15:26:55 EST 2006
> [INFO] Final Memory: 3M/508M
> [INFO]
>
> {code}
> I have two questions:
> # Why do I have to specify all the properties one-by-one while calling the
> target?
> # Why is the output for line.separator not what is expected?
--
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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103791 ] Basil James Whitehouse III commented on MNG-3043: - This also seems to affect the Release plugin when performing a release:prepare. > Allow 'mvn test' to work with test-jar dependencies in a reactor > > > Key: MNG-3043 > URL: http://jira.codehaus.org/browse/MNG-3043 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, Reactor and workspace >Affects Versions: 2.0.6, 2.0.7, 2.1 >Reporter: Kenney Westerhof > Fix For: Reviewed Pending Version Assignment > > > Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn > install', you run 'mvn test'. > Test classes of dependencies should be resolved from the reactor, just as > main classes, if there's no archive available. > I'm not sure how to go about this. Specifying a dependency on something with > test-jar, > and having that dependency declare the maven-jar-plugin with the 'test-jar' > goal is insufficient. > Perhaps we can just add a standard classifier that maven is aware of, in this > case 'tests'. The jar packaging > would export this as a known classifier, and tells maven how it contributes > to what classpath. > Since test sources are a first class citizen, just as main sources are (they > have the same phases, same > elements in the pom (but differently named)). > It seems logical to me that somehow the test classes should be made available > to dependencies, > if they declare a dependency with classifier 'tests'. -- 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
