[jira] (MNG-1378) Make dependencies of test-jars transitive
[ https://jira.codehaus.org/browse/MNG-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311884#comment-311884 ] Joshua Pollak commented on MNG-1378: I'm amazed this issue has been open 7 years, it seems so basic. > Make dependencies of test-jars transitive > - > > Key: MNG-1378 > URL: https://jira.codehaus.org/browse/MNG-1378 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0 >Reporter: Mark Hobson > Fix For: Issues to be reviewed for 3.x > > Attachments: mng1378.tar.gz > > > test-jar transitive dependencies are calculated as per compile scope rather > than test scope. > The situation is demonstrated nicely in it0077: > * module sub1 has a test-scoped dependency of commons-lang > * module sub2 has a test-scoped dependency of sub1 test-jar > sub2 tests should inherit the commons-lang transitive dependency. For > example: > Index: > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > === > --- > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (revision > 328307) > +++ > maven-core-it/it0077/sub2/src/test/java/org/apache/maven/it0077/PersonTwoTest.java > (working > copy) > @@ -1,6 +1,7 @@ > package org.apache.maven.it0077; > import junit.framework.TestCase; > +import org.apache.commons.lang.BooleanUtils; > public class PersonTwoTest > extends PersonTest > Results in: > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > c:\maven-components\maven-core-it\it0077\sub2\src\test\java\org\apache\maven\it0077\PersonTwoTest.java:[4,31] > package org.apache.commons.lang does not exist -- 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] Commented: (SCM-445) Extend command coverage of AccuRev provider for use with Continuum and Release Plugin
[ http://jira.codehaus.org/browse/SCM-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210367#action_210367 ] Joshua Pollak commented on SCM-445: --- I get a compiler error when trying to compile a clean checkout from the URL above, am I doing something wrong? I did: svn co https://svn.apache.org/repos/asf/maven/sandbox/trunk/scm/maven-scm-provider-accurevnew/ cd maven-scm-provider-accurevnew/ mvn compile (all of which worked correctly), and then: mvn test which resulted in this: /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevCommandLineTest.java:[52,7] cannot access org.codehaus.plexus.PlexusTestCase class file for org.codehaus.plexus.PlexusTestCase not found public class AccuRevCommandLineTest /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/command/AccuRevTckUtil.java:[35,26] cannot find symbol symbol : class PlexusContainer location: package org.codehaus.plexus /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/command/AccuRevTckUtil.java:[97,28] cannot find symbol symbol : class PlexusContainer location: class org.apache.maven.scm.provider.accurev.command.AccuRevTckUtil /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/command/AccuRevTckUtil.java:[103,26] cannot find symbol symbol : class PlexusContainer location: class org.apache.maven.scm.provider.accurev.command.AccuRevTckUtil /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[29,42] package org.apache.maven.scm.manager.plexus does not exist /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[30,26] cannot find symbol symbol : class PlexusContainer location: package org.codehaus.plexus /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[31,57] package org.codehaus.plexus.component.repository.exception does not exist /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[32,34] package org.codehaus.plexus.logging does not exist /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[33,34] package org.codehaus.plexus.logging does not exist /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[58,39] cannot find symbol symbol : class PlexusContainer location: class org.apache.maven.scm.provider.accurev.cli.AccuRevJUnitUtil /Users/jpollak/src/maven-scm-provider-accurevnew/src/test/java/org/apache/maven/scm/provider/accurev/cli/AccuRevJUnitUtil.java:[59,15] cannot find symbol symbol : class ComponentLookupException location: class org.apache.maven.scm.provider.accurev.cli.AccuRevJUnitUtil > Extend command coverage of AccuRev provider for use with Continuum and > Release Plugin > - > > Key: SCM-445 > URL: http://jira.codehaus.org/browse/SCM-445 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-accurev >Reporter: Grant Gardner > Fix For: 1.4 > > Attachments: maven-scm-provider-accurev.tar.gz, > maven-scm-provider-accurev.tar.gz, maven-scm-provider-accurev.tar.gz > > > Replacement accurev provider with additional commands - Login, Checkout, > Update, Add, Changelog, CheckIn, Status, Tag, Export. See site documentation > for full coverage > Note that the URL syntax is different from the original minimal AccuRev > plugin. -- 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-368) In a DependencySet I cannot get scope to be transitive
[
http://jira.codehaus.org/browse/MASSEMBLY-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156548#action_156548
]
Joshua Pollak commented on MASSEMBLY-368:
-
I have the same problem with the tar.gz format. This is the head of my assembly
xml file:
{{monospaced}}
plugin
tar.gz
${project.artifactId}-${project.version}
lib
true
false
org.mule.transports:mule-transport-sqs
...
{{monospaced}}
The mule-transport-sqs depends on a library called typica, which depends on a
few other libraries. The only jar to appear in the lib directory is the
mhs-transport-sqs itself.
I added false in an effort to
fix the problem (I know false is the default), but it didn't help.
> In a DependencySet I cannot get scope to be transitive
> --
>
> Key: MASSEMBLY-368
> URL: http://jira.codehaus.org/browse/MASSEMBLY-368
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: I define an assembly having the "dir" format.
>Reporter: Jean-Sébastien Scrève
>
> I have a project "A" who has a dependency to another project named "myDomain".
>
> myDomain
> myDomain
> 1.0.0
> provided
>
> myDomain also has others "provided" dependencies :
>
> asm
> asm
> 2.2.3
> provided
>
>
> asm
> asm-attrs
> 2.2.3
> provided
>
> In my assembly descriptor, I define the following dependency set :
>
> false
> true
>
> false
> provided
>
> None of the "provided" dependencies of myDomain project are included into my
> assembly.
> That is :asm:asm and asm:asm-attrs are not included but myDomain:myDomain is
> included.
--
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-3816) dependency resolution fails when modules have inter-dependencies
[ http://jira.codehaus.org/browse/MNG-3816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152955#action_152955 ] Joshua Pollak commented on MNG-3816: To clarify, I don't think it should be required to do an install before being able to run commands on a self contained project like demoPom above... > dependency resolution fails when modules have inter-dependencies > > > Key: MNG-3816 > URL: http://jira.codehaus.org/browse/MNG-3816 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.9 > Environment: Mac, Maven 2.0.9, Java 1.5 >Reporter: Joshua Pollak > Attachments: demoPom.tgz > > > There seems to be problems with dependency resolution at various phases in > the maven lifecycle. For example, if I run the following command on the > attached project, I get a failure instead of the expected dependency tree: > [EMAIL PROTECTED]:~/src/software/projects/demoPom/trunk$ mvn dependency:tree > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Demo Project > [INFO] moduleA - Framework Code > [INFO] moduleB - Generated Sources > [INFO] moduleC - Main Application > [INFO] Searching repository for plugin with prefix: 'dependency'. > [INFO] > > [INFO] Building Demo Project > [INFO]task-segment: [dependency:tree] > [INFO] > > [INFO] [dependency:tree] > [INFO] com.kiva.demoPom:demoPom:pom:0.0.2-SNAPSHOT > [INFO] \- junit:junit:jar:3.8.1:test > [INFO] > > [INFO] Building moduleA - Framework Code > [INFO]task-segment: [dependency:tree] > [INFO] > > [INFO] [dependency:tree] > [INFO] com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT > [INFO] \- junit:junit:jar:3.8.1:test > [INFO] > > [INFO] Building moduleB - Generated Sources > [INFO]task-segment: [dependency:tree] > [INFO] > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.2-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=com.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] > -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleB:jar:0.0.2-SNAPSHOT > 2) com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleB:jar:0.0.2-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 4 seconds > [INFO] Finished at: Mon Nov 03 17:00:13 EST 2008 > [INFO] Final Memory: 9M/18M > [INFO] > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3816) dependency resolution fails when modules have inter-dependencies
dependency resolution fails when modules have inter-dependencies Key: MNG-3816 URL: http://jira.codehaus.org/browse/MNG-3816 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.9 Environment: Mac, Maven 2.0.9, Java 1.5 Reporter: Joshua Pollak Attachments: demoPom.tgz There seems to be problems with dependency resolution at various phases in the maven lifecycle. For example, if I run the following command on the attached project, I get a failure instead of the expected dependency tree: [EMAIL PROTECTED]:~/src/software/projects/demoPom/trunk$ mvn dependency:tree [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Demo Project [INFO] moduleA - Framework Code [INFO] moduleB - Generated Sources [INFO] moduleC - Main Application [INFO] Searching repository for plugin with prefix: 'dependency'. [INFO] [INFO] Building Demo Project [INFO]task-segment: [dependency:tree] [INFO] [INFO] [dependency:tree] [INFO] com.kiva.demoPom:demoPom:pom:0.0.2-SNAPSHOT [INFO] \- junit:junit:jar:3.8.1:test [INFO] [INFO] Building moduleA - Framework Code [INFO]task-segment: [dependency:tree] [INFO] [INFO] [dependency:tree] [INFO] com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT [INFO] \- junit:junit:jar:3.8.1:test [INFO] [INFO] Building moduleB - Generated Sources [INFO]task-segment: [dependency:tree] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA -Dversion=0.0.2-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=com.kiva.demoPom -DartifactId=moduleA -Dversion=0.0.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.kiva.demoPom:moduleB:jar:0.0.2-SNAPSHOT 2) com.kiva.demoPom:moduleA:jar:0.0.2-SNAPSHOT -- 1 required artifact is missing. for artifact: com.kiva.demoPom:moduleB:jar:0.0.2-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 4 seconds [INFO] Finished at: Mon Nov 03 17:00:13 EST 2008 [INFO] Final Memory: 9M/18M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-274) autoVersionSubModules could be improved for release:branch
[ http://jira.codehaus.org/browse/MRELEASE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152199#action_152199 ] Joshua Pollak commented on MRELEASE-274: It seems to me that -DautoVersionSubmodules=true has no effect. I am still prompted for the version number for modules of my top level pom (with pom) > autoVersionSubModules could be improved for release:branch > -- > > Key: MRELEASE-274 > URL: http://jira.codehaus.org/browse/MRELEASE-274 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-7, 2.0 > Environment: All >Reporter: Wouter Hermeling >Priority: Minor > > When doing a release:branch and setting autoVersionSubModules to true, i > would like to have the versions of the submodules modified the same way as > the parent instead of asking for the new version to use. -- 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-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152192#action_152192 ] Joshua Pollak commented on MRELEASE-173: Does this feature apply to the branch goal as well? I'd like to be able to do: mvn release:branch -DbranchVersion=1.2-myFeature -DbranchName=myFeature Can 2.0-beta-8 be released so we can start testing this feature? > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-238) Assembly plugin removes file permissions
[
http://jira.codehaus.org/browse/MASSEMBLY-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133257#action_133257
]
Joshua Pollak commented on MASSEMBLY-238:
-
I can confirm this problem. It only seems to happen with zip files, permissions
are preserved with tar.gz and tar.bz2.
> Assembly plugin removes file permissions
>
>
> Key: MASSEMBLY-238
> URL: http://jira.codehaus.org/browse/MASSEMBLY-238
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Vincent Massol
>
> I have some files with the execute permission set. When they are copied into
> a zip file by the assembly plugin their permissions are removed.
> This forces me to do something ugly (and not efficient) like this:
> {code}
>
>
>
>
>
> com.xpn.xwiki.platform:xwiki-jetty-resources
>
> /
> true
>
>
> **/*.sh
>
>
> 755
>
>
>
>
>
>
> com.xpn.xwiki.platform:xwiki-jetty-resources
>
> /
> true
>
>
> **/*.sh
>
>
>
> {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] Updated: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Pollak updated MNG-3559: --- Attachment: demoPom-0.0.2-src.tgz This updated demo project demonstrates the problem the -r2 patch corrects, and replaces the previously uploaded demoPom project. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -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.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133174#action_133174 ] jpollak edited comment on MNG-3559 at 4/30/08 7:02 PM: - The previous patch prevented the moduleC's production code from depending on moduleA's production code. This patch corrects this problem and replaces (obsoletes) the previous patch. was (Author: jpollak): The previous patch prevented the moduleC's production code from depending on moduleA's production code. This patch corrects this problem. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -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.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- 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-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Pollak updated MNG-3559: --- Attachment: ActiveProjectTestJar-r2-2.0.9.patch The previous patch prevented the moduleC's production code from depending on moduleA's production code. This patch corrects this problem. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, > ActiveProjectTestJar-r2-2.0.9.patch, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -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.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- 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-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
[ http://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua Pollak updated MNG-3559: --- Attachment: ActiveProjectTestJar-2.0.9.patch Here is a patch I think fixes the problem. The patch is against 2.0.9. The problem turns out to be that MavenProject.replaceWithActiveArtifact() doesn't recognize the "test-jar" dependency as a active project artifact because moduleA's packaging is "jar", not "test-jar" (obviously). What I've done is added a specific case to check if the dependency is of type test-jar and the scope of the dependency is "test". If so, the patch creates and ActiveProjectArtifact() and replaces the File inside with: new File(ref.getModelBuild().getTestOutputDirectory()) This doesn't allow production code to depend on another modules test's, but it does allow sibling tests to depend on another modules tests. > Multi-Module Project: module that depends on sibling test jar cannot execute > test-compile without install of sibling first > -- > > Key: MNG-3559 > URL: http://jira.codehaus.org/browse/MNG-3559 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.8, 2.0.9 >Reporter: Joshua Pollak > Attachments: ActiveProjectTestJar-2.0.9.patch, demoPom.tgz > > > We have project with a few sibling modules: > * Project > moduleA > +-- /src/main/java (Common Code) > +-- /src/test/java(Common Test Framework) > moduleB > moduleC > +-- /src/main/java (Production Code, depends on moduleA Common code) > +-- /src/test/java(Production Test Framework, depends on > moduleA Common Test Framework) > I dont think there is anything wrong with this project in concept. moduleC's > "main" code depends son moduleA's "main" code, and moduleC's test code > depends on moduleA's test code. > This works if I run 'mvn install', but for rapid development, we often run > single unit tests and need to be able to run "mvn test" from the top level > project, which fails. > For an example, download the attached project and run "mvn test" from the > trunk directory. It will fail with the error pasted below. Then, run "mvn > install" and everything works ok. We should be able to run our unit tests > without having to install first. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=com.kiva.demoPom > -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -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.kiva.demoPom -DartifactId=moduleA > -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar > -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT > -- > 1 required artifact is missing. > for artifact: > com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) -- 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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133038#action_133038 ] Joshua Pollak commented on MNG-2045: I don't think this bug is fixed. If I download sample.zip and run 'mvn test-compile', I get the following: [EMAIL PROTECTED]:~/src$ cd sample/ [EMAIL PROTECTED]:~/src/sample$ ls pom.xml sample-jar sample-jar-user [EMAIL PROTECTED]:~/src/sample$ mvn test-compile [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Unnamed - sample-project:sample-parent:pom:SNAPSHOT [INFO] Maven Quick Start Archetype [INFO] Maven Quick Start Archetype [INFO] [INFO] Building Unnamed - sample-project:sample-parent:pom:SNAPSHOT [INFO]task-segment: [test-compile] [INFO] [INFO] No goals needed for project - skipping [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [test-compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] Building Maven Quick Start Archetype [INFO]task-segment: [test-compile] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) sample-project:sample-jar:test-jar:tests:SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=sample-project -DartifactId=sample-jar -Dversion=SNAPSHOT -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=sample-project -DartifactId=sample-jar -Dversion=SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) sample-project:sample-jar-user:jar:SNAPSHOT 2) sample-project:sample-jar:test-jar:tests:SNAPSHOT -- 1 required artifact is missing. for artifact: sample-project:sample-jar-user:jar:SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Apr 29 18:55:27 EDT 2008 [INFO] Final Memory: 3M/6M [INFO] > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.8 > > Attachments: it1021.tar.gz, mng-2045-ittest.zip, > MNG-2045-maven-project-r577340.patch1, MNG-2045-maven-project-r577340.patch2, > sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really on
[jira] Created: (MNG-3559) Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first
Multi-Module Project: module that depends on sibling test jar cannot execute test-compile without install of sibling first -- Key: MNG-3559 URL: http://jira.codehaus.org/browse/MNG-3559 Project: Maven 2 Issue Type: Bug Components: Bootstrap & Build Affects Versions: 2.0.9, 2.0.8 Reporter: Joshua Pollak Attachments: demoPom.tgz We have project with a few sibling modules: * Project moduleA +-- /src/main/java (Common Code) +-- /src/test/java(Common Test Framework) moduleB moduleC +-- /src/main/java (Production Code, depends on moduleA Common code) +-- /src/test/java(Production Test Framework, depends on moduleA Common Test Framework) I dont think there is anything wrong with this project in concept. moduleC's "main" code depends son moduleA's "main" code, and moduleC's test code depends on moduleA's test code. This works if I run 'mvn install', but for rapid development, we often run single unit tests and need to be able to run "mvn test" from the top level project, which fails. For an example, download the attached project and run "mvn test" from the trunk directory. It will fail with the error pasted below. Then, run "mvn install" and everything works ok. We should be able to run our unit tests without having to install first. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -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.kiva.demoPom -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT -- 1 required artifact is missing. for artifact: com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2) -- 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: (MCLEAN-33) Cannot Supress Default clean while still cleaning
Cannot Supress Default clean while still cleaning
-
Key: MCLEAN-33
URL: http://jira.codehaus.org/browse/MCLEAN-33
Project: Maven 2.x Clean Plugin
Issue Type: New Feature
Affects Versions: 2.1.1
Reporter: Joshua Pollak
Priority: Minor
We would like to configure clean in our parent pom to remove the log files in
logs in all our child modules. We've done that like this:
maven-clean-plugin
2.1.1
${basedir}/logs
false
**/.svn
The problem is that when we want to clean an extra directory out of a module,
say for example, generated-sources:
maven-clean-plugin
2.1.1
gensrc
clean
clean
generated-sources
false
We then see the following when we run "mvn clean":
FO] Building Generated Sources
[INFO]task-segment: [clean]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set:
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/logs (included: [],
excluded: [**/.svn])
[INFO] [clean:clean {execution: gensrc}]
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/test-classes
[INFO] Deleting directory
/Users/jpollak/src/software/projects/mhs/trunk/mhs-gensrc/target/site
[INFO] Deleting file-set: generated-sources (included: [], excluded: [**/.svn])
[INFO]
It would be nice to suppress cleaning target a second time.
--
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-3314) offline build not running, when having SNAPSHOT dependencies
[ http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121918 ] Joshua Pollak commented on MNG-3314: I can confirm this bug on maven versions 2.0.6, 2.0.7, and 2.0.8. This is also a critical issue for corporate software teams with an internal Maven repository which is not available to developers who are working offline or at home where the internal repository is not available. > offline build not running, when having SNAPSHOT dependencies > > > Key: MNG-3314 > URL: http://jira.codehaus.org/browse/MNG-3314 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.7 >Reporter: Matthias Weßendorf >Priority: Critical > > am having troubles with > mvn ... -o > (with maven 2.0.7) > says not able to download (but, really, the file is in my local repo) > The dependency is a -SNAPSHOT (for what's worth) > Luckily, when traveling by train, I had maven 2.0.4 on my box as well. > A change to use 2.0.4 works fine. > So, is this an already know bug in 2.0.7 ? > To my understanding it is a bug, since offline just shouldn't try to get a > newer > SNAPSHOT, perhaps I am wrong. > I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect > just not checking for new stuff. > and... for some reasons, sometimes, > it just downloads a new SNAPSHOT. > That is a pain, when you are "maintaining" the same snapshot on your > box, but the build just goes ahead and actually downloads a version. -- 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
