[jira] Commented: (MSITE-548) site:deploy -> folder structure is different when artifactId=module's directory
[ http://jira.codehaus.org/browse/MSITE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253677#action_253677 ] Lukas Theussl commented on MSITE-548: - There are several issues here. First I cannot quite reproduce your problem (running maven 2.2.1, site-plugin-2.3-SNAPSHOT): the deployed directory structure is root module1 module-2 (ie modules get deployed to the same level) while it should actually be root root/module1 root/module-2 However, this is apparently not a site-plugin issue, running help:effective-pom in one of the modules shows that the effective distributionManagement.site.url of the module is actually /tmp/module1, this is what the site plugin uses. Anyway, for such non-standard project layouts I would recommend to specify the distMngmnt sections for each module explicitly, doing so the deployed site is ok AFAICS. > site:deploy -> folder structure is different when artifactId=module's > directory > --- > > Key: MSITE-548 > URL: http://jira.codehaus.org/browse/MSITE-548 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0-beta-3 > Environment: windows >Reporter: Stefan Hansel > Attachments: artifact-id-testcase.zip > > > There is a multimodule flat project structure: > root > module1 > module2 > module1 has an artifactID of 'module1' (same as directory name) > modulu2 has an artifactID of 'module-2' (different to directory name) > After a 'mvn site-deploy' the generated report has the folder structure: > /root > /root/module-2 > /module1 > So based on the artifactID the submodules are created as a child of the root > - or not. > This is at least inconsistent and should be changed to be handled always the > same - independent of the artifactID. > This is also important for other plugins (i.e. the dashboard plugin). > They seem to have some hardcoded directory structure (preferring submodules > as childs of the root report). > Due to this bug (see http://jira.codehaus.org/browse/MOJO-1630) the links > between reports there still don't work as long as artifactID=module's > directory. > Attached you will find a testcase (based on maven3, but can also be used with > maven2 when the version of the site-plugin is changed). -- 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-637) hg not under root
[ http://jira.codehaus.org/browse/MRELEASE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253678#action_253678 ] Reimo Daum commented on MRELEASE-637: - Hello, just a suggestion - as Hg is casesensitive it might just a problem with that. As i can see from your log there are some files starting with capiltal letter and some not: c:\dev\projects\test2\pom.xml C:\dev\projects\test2\generated\pom.xml It depends on how you describe your Hg repository and from where are you executing your hg commands. For instance your command line console might be using different case (probably due to executing 'cd c:\dev\projects' instead of 'cd C:\dev\projects') > hg not under root > - > > Key: MRELEASE-637 > URL: http://jira.codehaus.org/browse/MRELEASE-637 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 > Environment: Maven 3.0 > Windows 7 > Mercurial 1.5.2 >Reporter: Alexander Maksimenko > > When I call mvn release:prepare for project with sub-projects I got > [INFO] EXECUTING: cmd.exe /X /C "hg commit --message "[maven-release-plugin] > prepare release > 1.0.8.3" c:\dev\projects\test2\pom.xml > C:\dev\projects\test2\generated\pom.xml" > [ERROR] > EXECUTION FAILED > Execution of cmd : commit failed with exit code: -1. > Working directory was: > c:\dev\projects\test2 > Your Hg installation seems to be valid and complete. > Hg version: 1.5.2 (OK) > When I call this command directly I've got > hg commit --message "[maven-release-plugin] prepare release" > c:\dev\projects\test2\pom.xml C:\dev\projects\test2\generated\pom.xml > abort: C:\dev\projects\test2\generated\pom.xml not under root > So seems hg requires relative path to commited files > When I call > hg commit --message "[maven-release-plugin] prepare release" pom.xml > generated\pom.xml > everything is OK -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-602) upgrade to scm 1.5 (hg plugin insists on 'pushing')
upgrade to scm 1.5 (hg plugin insists on 'pushing') --- Key: SCM-602 URL: http://jira.codehaus.org/browse/SCM-602 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-mercurial (hg) Affects Versions: 1.2, 1.3, 1.4 Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 1.5 When I combine the mercurial scm with the release plugin, I'm unhappy to discover that the scm insists on doing a push. The whole point of a hg or git-based systems is to work in the local clone and push up to the repo at a later time. I submit that the plugin should leave the pushing to me, simply performing the hg manipulations in the local clone. -- 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] Moved: (MRELEASE-641) upgrade to scm 1.5 (hg plugin insists on 'pushing')
[ http://jira.codehaus.org/browse/MRELEASE-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved SCM-602 to MRELEASE-641: --- Complexity: (was: Intermediate) Component/s: (was: maven-scm-provider-mercurial (hg)) scm Fix Version/s: (was: 1.5) 2.2 Affects Version/s: (was: 1.4) (was: 1.3) (was: 1.2) 2.1 Issue Type: Improvement (was: Bug) Key: MRELEASE-641 (was: SCM-602) Project: Maven 2.x Release Plugin (was: Maven SCM) > upgrade to scm 1.5 (hg plugin insists on 'pushing') > --- > > Key: MRELEASE-641 > URL: http://jira.codehaus.org/browse/MRELEASE-641 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > > When I combine the mercurial scm with the release plugin, I'm unhappy to > discover that the scm insists on doing a push. The whole point of a hg or > git-based systems is to work in the local clone and push up to the repo at a > later time. I submit that the plugin should leave the pushing to me, simply > performing the hg manipulations in the local clone. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-161) If there is more than one artifact with the same artifactId in dependencyManagement only the first one is updated
[
http://jira.codehaus.org/browse/MRELEASE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reimo Daum updated MRELEASE-161:
Attachment: MRELEASE-161.patch
I attached possible solution for this bug - it does not break tests but i'm not
sure if it's a correct way to solve this issue as this loop break has been
there for ages.
My solutions is not to break the loop as there are also other dependendcies
with same "groupId + artifactId" but different type.
> If there is more than one artifact with the same artifactId in
> dependencyManagement only the first one is updated
> -
>
> Key: MRELEASE-161
> URL: http://jira.codehaus.org/browse/MRELEASE-161
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-4
> Environment: Maven 2.0.4 under windows
>Reporter: Sébastien Cesbron
> Attachments: MRELEASE-161.patch, multipleArtifacts.patch,
> release-test.zip
>
>
> I have a multi module project. When I do release:prepare, the release plugin
> update the version tag of all my submodules in the dependencyManagement
> section.
> For the same module I have declared two artifacts like this :
> {code:xml}
>
> com.bla
> blabla
> 1.0-SNAPSHOT
> test-jar
> test
>
>
> com.bla
> blabla
> 1.0-SNAPSHOT
>
> {code}
> In this case, the release plugin only update the first dependency.
> This is due to element search in the "updateDomVersion" method of the
> AbstractRewritePomsPhase class. I've attached a patch to solve the problem. I
> don't know if this is the right way to do. I change all the artifacts in the
> same pass. I don't take car of different type/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] Closed: (MRELEASE-641) upgrade to scm 1.5 (hg plugin insists on 'pushing')
[ http://jira.codehaus.org/browse/MRELEASE-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-641. - Resolution: Fixed fix [rev 1065954|http://svn.apache.org/viewvc?rev=1065954&view=rev] > upgrade to scm 1.5 (hg plugin insists on 'pushing') > --- > > Key: MRELEASE-641 > URL: http://jira.codehaus.org/browse/MRELEASE-641 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: scm >Affects Versions: 2.1 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.2 > > > When I combine the mercurial scm with the release plugin, I'm unhappy to > discover that the scm insists on doing a push. The whole point of a hg or > git-based systems is to work in the local clone and push up to the repo at a > later time. I submit that the plugin should leave the pushing to me, simply > performing the hg manipulations in the local clone. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-475) hg plugin insists on 'pushing'
[ http://jira.codehaus.org/browse/SCM-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253688#action_253688 ] Olivier Lamy commented on SCM-475: -- see MRELEASE-641 > hg plugin insists on 'pushing' > -- > > Key: SCM-475 > URL: http://jira.codehaus.org/browse/SCM-475 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.2, 1.3, 1.4 >Reporter: Benson Margulies >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: SCM-475-maven-scm-provider-hg.patch > > > When I combine the mercurial scm with the release plugin, I'm unhappy to > discover that the scm insists on doing a push. The whole point of a hg or > git-based systems is to work in the local clone and push up to the repo at a > later time. I submit that the plugin should leave the pushing to me, simply > performing the hg manipulations in the local clone. -- 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: (MSITE-548) site:deploy -> folder structure is different when artifactId=module's directory
[
http://jira.codehaus.org/browse/MSITE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253693#action_253693
]
Stefan Hansel commented on MSITE-548:
-
Ok, checked again - it indeed only happens with maven3.0.1 + 3.0.2 .
Who whould be responsible for such a bug-report? Is this the core of Maven
http://jira.codehaus.org/browse/MNG ?
As you say 'non-standard project layout' - I thought that a flat multimodule
project is completely valid (at least officially documented in the sonartype
docs) and the best way to cope with eclipse, as it only knows a flat project
structure anyway?
One other question: I already tried to manipulate/tweak the
distributionManagement.site.url (but of course don't want to use absolute paths
there).
I hoped that
{code}
${project.parent.distributionManagement.site.url}/subdir
{code}
would help in the submodule, but I only get errors and it looks like the
variable is not resolved.
Any suggestions?
> site:deploy -> folder structure is different when artifactId=module's
> directory
> ---
>
> Key: MSITE-548
> URL: http://jira.codehaus.org/browse/MSITE-548
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.0-beta-3
> Environment: windows
>Reporter: Stefan Hansel
> Attachments: artifact-id-testcase.zip
>
>
> There is a multimodule flat project structure:
> root
> module1
> module2
> module1 has an artifactID of 'module1' (same as directory name)
> modulu2 has an artifactID of 'module-2' (different to directory name)
> After a 'mvn site-deploy' the generated report has the folder structure:
> /root
> /root/module-2
> /module1
> So based on the artifactID the submodules are created as a child of the root
> - or not.
> This is at least inconsistent and should be changed to be handled always the
> same - independent of the artifactID.
> This is also important for other plugins (i.e. the dashboard plugin).
> They seem to have some hardcoded directory structure (preferring submodules
> as childs of the root report).
> Due to this bug (see http://jira.codehaus.org/browse/MOJO-1630) the links
> between reports there still don't work as long as artifactID=module's
> directory.
> Attached you will find a testcase (based on maven3, but can also be used with
> maven2 when the version of the site-plugin is changed).
--
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] Moved: (MNG-5000) child distributionManagment.site.url not correct in a flat directory layout
[ http://jira.codehaus.org/browse/MNG-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved MSITE-548 to MNG-5000: -- Complexity: Intermediate Affects Version/s: (was: 3.0-beta-3) 3.0.2 Key: MNG-5000 (was: MSITE-548) Project: Maven 2 & 3 (was: Maven 2.x and 3.x Site Plugin) > child distributionManagment.site.url not correct in a flat directory layout > --- > > Key: MNG-5000 > URL: http://jira.codehaus.org/browse/MNG-5000 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: windows >Reporter: Stefan Hansel > Attachments: artifact-id-testcase.zip > > > There is a multimodule flat project structure: > root > module1 > module2 > module1 has an artifactID of 'module1' (same as directory name) > modulu2 has an artifactID of 'module-2' (different to directory name) > After a 'mvn site-deploy' the generated report has the folder structure: > /root > /root/module-2 > /module1 > So based on the artifactID the submodules are created as a child of the root > - or not. > This is at least inconsistent and should be changed to be handled always the > same - independent of the artifactID. > This is also important for other plugins (i.e. the dashboard plugin). > They seem to have some hardcoded directory structure (preferring submodules > as childs of the root report). > Due to this bug (see http://jira.codehaus.org/browse/MOJO-1630) the links > between reports there still don't work as long as artifactID=module's > directory. > Attached you will find a testcase (based on maven3, but can also be used with > maven2 when the version of the site-plugin is changed). -- 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: (MSITE-548) child distributionManagment.site.url not correct in a flat directory layout
[ http://jira.codehaus.org/browse/MSITE-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-548: Summary: child distributionManagment.site.url not correct in a flat directory layout (was: site:deploy -> folder structure is different when artifactId=module's directory) > child distributionManagment.site.url not correct in a flat directory layout > --- > > Key: MSITE-548 > URL: http://jira.codehaus.org/browse/MSITE-548 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: windows >Reporter: Stefan Hansel > Attachments: artifact-id-testcase.zip > > > There is a multimodule flat project structure: > root > module1 > module2 > module1 has an artifactID of 'module1' (same as directory name) > modulu2 has an artifactID of 'module-2' (different to directory name) > After a 'mvn site-deploy' the generated report has the folder structure: > /root > /root/module-2 > /module1 > So based on the artifactID the submodules are created as a child of the root > - or not. > This is at least inconsistent and should be changed to be handled always the > same - independent of the artifactID. > This is also important for other plugins (i.e. the dashboard plugin). > They seem to have some hardcoded directory structure (preferring submodules > as childs of the root report). > Due to this bug (see http://jira.codehaus.org/browse/MOJO-1630) the links > between reports there still don't work as long as artifactID=module's > directory. > Attached you will find a testcase (based on maven3, but can also be used with > maven2 when the version of the site-plugin is changed). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-302) mvn install site-deploy does not follow the reactor build sequence
[ http://jira.codehaus.org/browse/MSITE-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-302. --- Resolution: Duplicate Assignee: Lukas Theussl > mvn install site-deploy does not follow the reactor build sequence > -- > > Key: MSITE-302 > URL: http://jira.codehaus.org/browse/MSITE-302 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-6 >Reporter: Ramon Havermans >Assignee: Lukas Theussl > Attachments: msite302-maven-logs.zip, msite302.zip, > OvereenkomstService_site-OvereenkomstService_site.1006-build.log > > > We have a multi pom project. We have one parent, one EJB and one Impl > project. The EJB project uses the Impl. The reactor sequence is Parent, EJB, > Impl. When first doing "mvn install" and then "mvn site-deploy" the build is > succesful. When doing "mvn install site-deploy" (on clean repository) the > build fails because it first builds the Ejb instead of the Impl. It won't > build because it is missing the installed Impl jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-693) The @factory annotation is ignored
The @factory annotation is ignored -- Key: SUREFIRE-693 URL: http://jira.codehaus.org/browse/SUREFIRE-693 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.7.2 Environment: ubuntu 10.10, jdk 1.6, testng 5.14.6, maven 3.0.2 Reporter: Yoryos Valotasios The plugin ignores methods annotated with @org.testng.annotations.Factory and tries to instantiate the test class (that should get instantiated by the factory method) alone. When I provide a suiteXmlFile everything seems to be ok except that I have to maintain a different suite file for each scenario as the excludedGroups configuration is ignored and the excludegroups property is also ignored. -- 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: (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ http://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253712#action_253712 ] Lukas Theussl commented on MSITE-171: - MSITE-302 has a test project. > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: http://jira.codehaus.org/browse/MSITE-171 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > Attachments: install_site_runs.log, site_fails.log, > subsequent_site_runs.log > > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site 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] Closed: (MSITE-475) Unwanted lifecycle phases triggered by mvn site:site
[
http://jira.codehaus.org/browse/MSITE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-475.
---
Resolution: Not A Bug
Assignee: Lukas Theussl
> Unwanted lifecycle phases triggered by mvn site:site
>
>
> Key: MSITE-475
> URL: http://jira.codehaus.org/browse/MSITE-475
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Lukas Theussl
> Attachments: huh.tar.gz
>
>
> The attached test cases consists of a detached parent, an aggregating parent,
> and a child.
> Instructions:
> {noformat}
> 1. cd 'parent'; mvn
> 2. mvn site:site
> {noformat}
> observe that the antrun execution from the compile phase is executed.
> Then, if you like, edit the toplevel pom.xml to remove the element
> that points to the parent in the parent directory, and observe that site:site
> stops running the compile phase.
> I can't see anything about that parent that has any reason to make the site
> plugin turn around and launch the standard (non-site) lifecycle, but
> obviously there's something I don't know.
--
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: (MSITE-475) Unwanted lifecycle phases triggered by mvn site:site
[
http://jira.codehaus.org/browse/MSITE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253716#action_253716
]
Benson Margulies commented on MSITE-475:
Could I beg you for an explanation?
> Unwanted lifecycle phases triggered by mvn site:site
>
>
> Key: MSITE-475
> URL: http://jira.codehaus.org/browse/MSITE-475
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Lukas Theussl
> Attachments: huh.tar.gz
>
>
> The attached test cases consists of a detached parent, an aggregating parent,
> and a child.
> Instructions:
> {noformat}
> 1. cd 'parent'; mvn
> 2. mvn site:site
> {noformat}
> observe that the antrun execution from the compile phase is executed.
> Then, if you like, edit the toplevel pom.xml to remove the element
> that points to the parent in the parent directory, and observe that site:site
> stops running the compile phase.
> I can't see anything about that parent that has any reason to make the site
> plugin turn around and launch the standard (non-site) lifecycle, but
> obviously there's something I don't know.
--
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-5001) @readonly Mojo parameter annotation doesn't work
@readonly Mojo parameter annotation doesn't work Key: MNG-5001 URL: http://jira.codehaus.org/browse/MNG-5001 Project: Maven 2 & 3 Issue Type: Bug Components: Plugin API Affects Versions: 3.0.2 Reporter: Jochen Ehret Attachments: log-maven-2.2.1.txt, log-maven-3.0.2.txt, readonlytest.zip In Maven 2.2.1, the @readonly annotation works as described: You can't configure a Mojo parameter in the pom section. If you do, the build will fail: [INFO] Error configuring: test:test-plugin. Reason: ERROR: Cannot override read-only parameter: testParameter in goal: test:dumpParameter In Maven 3.0.2, the @readonly seems to have no effect: [INFO] --- test-plugin:0.0.1-SNAPSHOT:dumpParameter (test-exec) @ test-project --- testParameter: readonly parameter configured in pom You can reproduce the behaviour with the attached example project. Log outputs for Maven 2.2.1 and 3.0.2 are also attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MRRESOURCES-53) use of remote resources plugin breaks ability to use test-jar artifacts
[
http://jira.codehaus.org/browse/MRRESOURCES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253719#action_253719
]
Steven Bethard edited comment on MRRESOURCES-53 at 2/1/11 8:49 AM:
---
I'm pretty confident it's in the {{maven-jar-plugin}} because I can provoke
this issue without the remote resources plugin using the {{maven-exec-plugin}}
or even just the {{maven-surefire-plugin}}:
http://jira.codehaus.org/browse/MEXEC-91.
Both of these issues should probably be merged and assigned to the
{{maven-jar-plugin}} but I don't know how to do that. Hopefully a real maven
committer will come by some time soon and do that.
was (Author: steven.bethard):
I'm not pretty confident it's in the {{maven-jar-plugin}} because I can
provoke this issue without the remote resources plugin using the
{{maven-exec-plugin}} or even just the {{maven-surefire-plugin}}:
http://jira.codehaus.org/browse/MEXEC-91.
Both of these issues should probably be merged and assigned to the
{{maven-jar-plugin}} but I don't know how to do that. Hopefully a real maven
committer will come by some time soon and do that.
> use of remote resources plugin breaks ability to use test-jar artifacts
> ---
>
> Key: MRRESOURCES-53
> URL: http://jira.codehaus.org/browse/MRRESOURCES-53
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Scott Carey
>Priority: Critical
> Attachments: project.zip
>
>
> I have a dead simple project configuration that breaks if I inherit from
> org.apache:apache . If I disable the remote resources plugin portion, it
> works.
> The plugin is trying to resolve a test-jar artifact during the compile phase,
> but such an artifact does not exist until the test-compile phase.
> To reproduce: unpack the project provided. run 'mvn clean compile'. that
> will fail. test-compile will work. If you install, then compile will work
> because it will find the test-jar in the local repo. You must not have any
> related snapshot artifacts in the local repo related to this project to
> reproduce.
> If you break the inheritance to the apache parent, it will work. Or, you can
> override the usage of the remote resources plugin and disable it to get the
> project to function.
> It seems to work if I assign the plugin to operate in a late phase -- such as
> prepare-package. Perhaps all that is required is that the plugin operate in
> as late a phase as it can by default?
> If it must operate in compile however, it cannot look for dependencies that
> are not generated until test-compile such as test-jar types.
--
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: (MRRESOURCES-53) use of remote resources plugin breaks ability to use test-jar artifacts
[
http://jira.codehaus.org/browse/MRRESOURCES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253719#action_253719
]
Steven Bethard commented on MRRESOURCES-53:
---
I'm not pretty confident it's in the {{maven-jar-plugin}} because I can provoke
this issue without the remote resources plugin using the {{maven-exec-plugin}}
or even just the {{maven-surefire-plugin}}:
http://jira.codehaus.org/browse/MEXEC-91.
Both of these issues should probably be merged and assigned to the
{{maven-jar-plugin}} but I don't know how to do that. Hopefully a real maven
committer will come by some time soon and do that.
> use of remote resources plugin breaks ability to use test-jar artifacts
> ---
>
> Key: MRRESOURCES-53
> URL: http://jira.codehaus.org/browse/MRRESOURCES-53
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Scott Carey
>Priority: Critical
> Attachments: project.zip
>
>
> I have a dead simple project configuration that breaks if I inherit from
> org.apache:apache . If I disable the remote resources plugin portion, it
> works.
> The plugin is trying to resolve a test-jar artifact during the compile phase,
> but such an artifact does not exist until the test-compile phase.
> To reproduce: unpack the project provided. run 'mvn clean compile'. that
> will fail. test-compile will work. If you install, then compile will work
> because it will find the test-jar in the local repo. You must not have any
> related snapshot artifacts in the local repo related to this project to
> reproduce.
> If you break the inheritance to the apache parent, it will work. Or, you can
> override the usage of the remote resources plugin and disable it to get the
> project to function.
> It seems to work if I assign the plugin to operate in a late phase -- such as
> prepare-package. Perhaps all that is required is that the plugin operate in
> as late a phase as it can by default?
> If it must operate in compile however, it cannot look for dependencies that
> are not generated until test-compile such as test-jar types.
--
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-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253720#action_253720
]
Kristian Rosenvold commented on MNG-4996:
-
Can you try to set the system property -Dmaven.artifact.threads=1 and see if
the problem goes away ?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
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-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253729#action_253729
]
Kristian Rosenvold commented on MNG-4996:
-
I uplodaded a snapshot version of 3.0.3 to
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/3.0.3-SNAPSHOT/apache-maven-3.0.3-20110201.153244-1-bin.zip
that has a fix.
I would be very happy if you could test this.
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
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: (MRRESOURCES-53) use of remote resources plugin breaks ability to use test-jar artifacts
[
http://jira.codehaus.org/browse/MRRESOURCES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253731#action_253731
]
Benjamin Bentmann commented on MRRESOURCES-53:
--
The issue is not in the {{maven-jar-plugin}}. The
{{maven-remote-resources-plugin}} explicitly resolves the test classpath of the
project ({{ProcessRemoteResourcesMojo.java:697}}) which naturally fails when
the test classes haven't even compiled.
> use of remote resources plugin breaks ability to use test-jar artifacts
> ---
>
> Key: MRRESOURCES-53
> URL: http://jira.codehaus.org/browse/MRRESOURCES-53
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Scott Carey
>Priority: Critical
> Attachments: project.zip
>
>
> I have a dead simple project configuration that breaks if I inherit from
> org.apache:apache . If I disable the remote resources plugin portion, it
> works.
> The plugin is trying to resolve a test-jar artifact during the compile phase,
> but such an artifact does not exist until the test-compile phase.
> To reproduce: unpack the project provided. run 'mvn clean compile'. that
> will fail. test-compile will work. If you install, then compile will work
> because it will find the test-jar in the local repo. You must not have any
> related snapshot artifacts in the local repo related to this project to
> reproduce.
> If you break the inheritance to the apache parent, it will work. Or, you can
> override the usage of the remote resources plugin and disable it to get the
> project to function.
> It seems to work if I assign the plugin to operate in a late phase -- such as
> prepare-package. Perhaps all that is required is that the plugin operate in
> as late a phase as it can by default?
> If it must operate in compile however, it cannot look for dependencies that
> are not generated until test-compile such as test-jar types.
--
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-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
http://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253734#action_253734
]
luke w patterson commented on MNG-4998:
---
what about using a new expression like ${project.properties.myProperty} ?
in the section, it will be resolved dynamic/lazy
in other sections either:
* not interpolated (evaluates to the original string of
"${project.properties.myProperty}")
* it is resolved static/eager
the existing references to ${myProperty} would be resolved just like they are
now
> Variables interpolation: dynamic in Maven 2, static in Maven 3
> --
>
> Key: MNG-4998
> URL: http://jira.codehaus.org/browse/MNG-4998
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> Please, see
> http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
> It demonstrates two examples where expression with ${variables} are
> interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
> and effect expressions interpolated later, Maven 3 also allows
> to update but all expressions are interpolated with their old
> values.
> I believe Maven 2 dynamic behavior is much more preferable than Maven 3
> Ant-like "stickiness" to what's defined in .
--
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: (MSITE-475) Unwanted lifecycle phases triggered by mvn site:site
[
http://jira.codehaus.org/browse/MSITE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253745#action_253745
]
Lukas Theussl commented on MSITE-475:
-
As you said this is triggered by the javadoc plugin, so it's not a bug in the
site plugin, or did I misunderstand something?
> Unwanted lifecycle phases triggered by mvn site:site
>
>
> Key: MSITE-475
> URL: http://jira.codehaus.org/browse/MSITE-475
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Lukas Theussl
> Attachments: huh.tar.gz
>
>
> The attached test cases consists of a detached parent, an aggregating parent,
> and a child.
> Instructions:
> {noformat}
> 1. cd 'parent'; mvn
> 2. mvn site:site
> {noformat}
> observe that the antrun execution from the compile phase is executed.
> Then, if you like, edit the toplevel pom.xml to remove the element
> that points to the parent in the parent directory, and observe that site:site
> stops running the compile phase.
> I can't see anything about that parent that has any reason to make the site
> plugin turn around and launch the standard (non-site) lifecycle, but
> obviously there's something I don't know.
--
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: (MSITE-475) Unwanted lifecycle phases triggered by mvn site:site
[
http://jira.codehaus.org/browse/MSITE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253746#action_253746
]
Benson Margulies commented on MSITE-475:
I saw that the presence of the javadoc plugin triggered it. I didn't debug to
demonstrate whether this is a result of a javadoc plugin bug, or a site plugin
bug ... though i admit on consideration that it's hard to explain it in terms
of the later.
> Unwanted lifecycle phases triggered by mvn site:site
>
>
> Key: MSITE-475
> URL: http://jira.codehaus.org/browse/MSITE-475
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Lukas Theussl
> Attachments: huh.tar.gz
>
>
> The attached test cases consists of a detached parent, an aggregating parent,
> and a child.
> Instructions:
> {noformat}
> 1. cd 'parent'; mvn
> 2. mvn site:site
> {noformat}
> observe that the antrun execution from the compile phase is executed.
> Then, if you like, edit the toplevel pom.xml to remove the element
> that points to the parent in the parent directory, and observe that site:site
> stops running the compile phase.
> I can't see anything about that parent that has any reason to make the site
> plugin turn around and launch the standard (non-site) lifecycle, but
> obviously there's something I don't know.
--
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: (MSITE-475) Unwanted lifecycle phases triggered by mvn site:site
[
http://jira.codehaus.org/browse/MSITE-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253749#action_253749
]
Lukas Theussl commented on MSITE-475:
-
Since there is an equivalent issue now in the javadoc plugin, let's keep it
open there. It sounds more logical there. :)
> Unwanted lifecycle phases triggered by mvn site:site
>
>
> Key: MSITE-475
> URL: http://jira.codehaus.org/browse/MSITE-475
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Benson Margulies
>Assignee: Lukas Theussl
> Attachments: huh.tar.gz
>
>
> The attached test cases consists of a detached parent, an aggregating parent,
> and a child.
> Instructions:
> {noformat}
> 1. cd 'parent'; mvn
> 2. mvn site:site
> {noformat}
> observe that the antrun execution from the compile phase is executed.
> Then, if you like, edit the toplevel pom.xml to remove the element
> that points to the parent in the parent directory, and observe that site:site
> stops running the compile phase.
> I can't see anything about that parent that has any reason to make the site
> plugin turn around and launch the standard (non-site) lifecycle, but
> obviously there's something I don't know.
--
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-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MNG-3321:
Fix Version/s: (was: Issues to be reviewed for 3.x)
3.1
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: 3.1
>
> Attachments: MNG-3321-core-integration-testing.patch,
> MNG-3321-maven-core.patch, MNG-3321-maven-core.patch
>
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
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-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253766#action_253766
]
John Casey commented on MNG-3321:
-
I've noted this on the dev@ ML, but I'll add a short comment here as well.
I think this is a great idea, and I like the approach of the patch. However,
I'd like to see us take it a little further before we consider releasing a
version of Maven with this patch in place. I'd like to have an option to
trigger plugin/execution suppression from somewhere in the POM, not just via
CLI option. This allows us to say, "My build uses the jar packaging, but I
never want the X plugin to run."
To me, this is important because it means we don't have to worry about users
getting the right CLI options in place to run a build (or, more importantly, a
release). In many cases, failing to use the suppressing CLI option may break
the build, but in others it may lead to incorrect build results being released
for public consumption. Also, in cases where it's important that users can
rebuild the project from source (as in cases where ASF votes are taken),
requiring a CLI option to produce a correct build adds a new layer of build
complexity. It takes us away from the common vocabulary that makes Maven so
effective, and back toward something more like Ant, where you have to know the
correct incantation to produce a build.
I hope this patch is applied, but I think we need to spend a little more time
focusing on how to codify these suppressions in the POM before releasing a
Maven version with this patch in place.
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: 3.1
>
> Attachments: MNG-3321-core-integration-testing.patch,
> MNG-3321-maven-core.patch, MNG-3321-maven-core.patch
>
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
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-3321) Skip plugin and/or execution
[
http://jira.codehaus.org/browse/MNG-3321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253778#action_253778
]
Kristian Rosenvold commented on MNG-3321:
-
I'm leaving this issue assigned to "3.1", and requesting that interested
parties attach use cases to this issue. The dev list discussion is at
http://mail-archives.apache.org/mod_mbox/maven-dev/201101.mbox/%3CAANLkTi=djx9q-qed+sq2-41y-ik0g4cj0ehlalmon...@mail.gmail.com%3E
and
http://mail-archives.apache.org/mod_mbox/maven-dev/201102.mbox/%3caanlktikdje+fld4k-0s1-r-f9mhsk-vdqnygf57qk...@mail.gmail.com%3E
> Skip plugin and/or execution
>
>
> Key: MNG-3321
> URL: http://jira.codehaus.org/browse/MNG-3321
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 2.0.8
>Reporter: Paul Gier
> Fix For: 3.1
>
> Attachments: MNG-3321-core-integration-testing.patch,
> MNG-3321-maven-core.patch, MNG-3321-maven-core.patch
>
>
> Add ability to skip the execution of certain plugins. From the command line
> this could look something like:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin
> install {code}
> Also useful would be the ability to skip individual executions of a plugin.
> For example, if the surefire plugin had two executions defined as "ex1" and
> "ex2", you could do something like this:
> {code} mvn -Dskip.plugin:org.apache.maven.plugins:maven-surefire-plugin:ex1
> install {code}
> This would skip ex1 but still run ex2.
--
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: (MECLIPSE-514) eclipse:eclipse always adds project-facet for ejb 2.1
[ http://jira.codehaus.org/browse/MECLIPSE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253791#action_253791 ] Messó commented on MECLIPSE-514: Please add support for JavaEE 6.0 and EJB 3.1, just add some constants to JeeDescriptor, and add a row to JeeUtils. Easy-peasy. Thanks! > eclipse:eclipse always adds project-facet for ejb 2.1 > - > > Key: MECLIPSE-514 > URL: http://jira.codehaus.org/browse/MECLIPSE-514 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 > Environment: Ubuntu Linux 8.10, Eclipse Ganymede, maven 2.0.9, java > 1.6.10 >Reporter: Thorsten Gawantka > Attachments: JeeUtils.java, JeeUtils.patch > > > I have an ejb-project with ejb-version 3.0 specified. (see below) > Now if i execute "mvn eclipse:eclipse" the genereated eclipse project always > contains the facet for ejb 2.1 > If i edit the the facet in the corresponding file to ejb 3.0, and execute > "mvn eclipse:eclipse" again, the facet is reseted to ejb 2.1 > If i add the additonalFacet for ejb 3.0 to the pom, then the corresponding > file contains facets for ejb 2.1 *and* ejb 3.0 > --- pom.xml Sniplets --- > > > org.apache.maven.plugins > maven-compiler-plugin > > 1.5 > 1.5 > > > > org.apache.maven.plugins > maven-eclipse-plugin > > 2.0 > true > > > > maven-ejb-plugin > > 3.0 > > > true > > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-475) hg plugin insists on 'pushing'
[ http://jira.codehaus.org/browse/SCM-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253797#action_253797 ] Sean Flanigan commented on SCM-475: --- Thanks, Olivier! > hg plugin insists on 'pushing' > -- > > Key: SCM-475 > URL: http://jira.codehaus.org/browse/SCM-475 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.2, 1.3, 1.4 >Reporter: Benson Margulies >Assignee: Olivier Lamy > Fix For: 1.5 > > Attachments: SCM-475-maven-scm-provider-hg.patch > > > When I combine the mercurial scm with the release plugin, I'm unhappy to > discover that the scm insists on doing a push. The whole point of a hg or > git-based systems is to work in the local clone and push up to the repo at a > later time. I submit that the plugin should leave the pushing to me, simply > performing the hg manipulations in the local clone. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
http://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253800#action_253800
]
Thiago Leão Moreira commented on MDEP-194:
--
This is the exactly problem that I have. Any intention to fix it? I'm using the
version 2.1
> ArchiverException when using maven dependency plugin in multi-module projects
> -
>
> Key: MDEP-194
> URL: http://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sascha Hofer
> Attachments: plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> Having the following module hierarchy the _unpack-dependencies_ goal of the
> _maven-dependency-plugin_ produces an _ArchiverException_.
> * A
> ** B
> ** C (depends on B)
> I took a quick look into the code and found that when unpacking the
> dependencies of module *C* the method _unpack(File, File, String, String)_ of
> class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
> the *target/classes* directory of *B* as source file (instead of the created
> jar).
> part of the pom.xml which caused the error:
> {noformat}
>
> multi-module-coverage
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-dependencies
> process-classes
>
> unpack-dependencies
>
>
>
> ${project.build.directory}/classes
> tests
>
>
>
>
>
>
>
> {noformat}
> exception:
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-98) The source must not be a directory
[ http://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253801#action_253801 ] Thiago Leão Moreira commented on MDEP-98: - Is there any intention to fix this? > The source must not be a directory > -- > > Key: MDEP-98 > URL: http://jira.codehaus.org/browse/MDEP-98 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack-dependencies >Affects Versions: 2.0-alpha-4 > Environment: Windows XP Professional SP2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) > Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) >Reporter: Pablo Muñiz >Assignee: Brian Fox > > Using maven-dependency-plugin in a multimodule project inside a module wich > has a dependency with another module in the same project the next error > ocurrs : > org.codehaus.plexus.archiver.ArchiverException: The source must not be a > directory. > at > org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98) > at > org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84) > at > org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232) > at > org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > 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:272) > 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) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error unpacking file: > c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to: > c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes > org.codehaus.plexus.archiver.ArchiverException: The source must not be a > directory. > Project structure is as follows: > plataforma > - platform-core > - platform-bundle > - platform-bundle-jar > - platform-bundle-src > and the error happens on executing any goal from parent pom. > maven-dependency-plugin seems to receive a reference to target/classes > directory for platform-core dependency instead of the URL to my local > repository where platform-core is located. -- 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: (MDEP-225) Dependency plugin seems to unpack archive even, if it is already unpacked
[ http://jira.codehaus.org/browse/MDEP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-225: --- Fix Version/s: 2.2 > Dependency plugin seems to unpack archive even, if it is already unpacked > - > > Key: MDEP-225 > URL: http://jira.codehaus.org/browse/MDEP-225 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack >Affects Versions: 2.1 >Reporter: Jason Chaffee >Assignee: Brian Fox > Fix For: 2.2 > > Attachments: MDEP-225-plh.patch, MDEP-225-plh2.patch, MDEP-225.patch, > MDEP-225.patch > > > The plugin used to be smart about not unpacking archives if it found the > archive was already unpacked (maybe I was doing something different than..not > sure). However, now it unpacks the archive every time, no matter what I try > to keep it from doing it, including using overwriteIfNewer. > I would like to be able to run the build once to extract the archive, then > not have it extracted again, unless I clean the target directory because the > archive takes several minutes to unpack. > Here are the steps. > 1) configure unpack in pom > 2) run mvn clean install --> expect unpacking > 3) run mvn install --> do not expect unpacking as it is still unpaced from > step (2) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MDEP-225) Dependency plugin seems to unpack archive even, if it is already unpacked
[ http://jira.codehaus.org/browse/MDEP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-225. -- Resolution: Fixed patch applied, thanks. > Dependency plugin seems to unpack archive even, if it is already unpacked > - > > Key: MDEP-225 > URL: http://jira.codehaus.org/browse/MDEP-225 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: unpack >Affects Versions: 2.1 >Reporter: Jason Chaffee >Assignee: Brian Fox > Attachments: MDEP-225-plh.patch, MDEP-225-plh2.patch, MDEP-225.patch, > MDEP-225.patch > > > The plugin used to be smart about not unpacking archives if it found the > archive was already unpacked (maybe I was doing something different than..not > sure). However, now it unpacks the archive every time, no matter what I try > to keep it from doing it, including using overwriteIfNewer. > I would like to be able to run the build once to extract the archive, then > not have it extracted again, unless I clean the target directory because the > archive takes several minutes to unpack. > Here are the steps. > 1) configure unpack in pom > 2) run mvn clean install --> expect unpacking > 3) run mvn install --> do not expect unpacking as it is still unpaced from > step (2) -- 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-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253808#action_253808
]
Kari J. Niemi commented on MNG-4996:
Thanks Kristian. I tried both, the fixed version and also the
-Dmaven.artifact.threads=1. I still get the same error.
I wonder which part of maven(or some plugin) is setting up&handing out the
classpath?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
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: (MENFORCER-68) Add an enforcer rule RequireSkinVersion
[ http://jira.codehaus.org/browse/MENFORCER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253810#action_253810 ] jieryn commented on MENFORCER-68: - This is a great idea, thank you Benjamin! Please Brian, status on this? Patch is attached... > Add an enforcer rule RequireSkinVersion > --- > > Key: MENFORCER-68 > URL: http://jira.codehaus.org/browse/MENFORCER-68 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Attachments: MENFORCER-35.zip, require-skin-version.patch, > require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253817#action_253817
]
Kari J. Niemi commented on MNG-4996:
I tried them both separately but not together. Is that relevant?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus.plexus:plexus-utils:jar:2.0.5:compile,
> junit:junit=junit:junit:jar:3.8.1:compile,
> org.apache.maven.reporting:maven-reporting-api=org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile}
>
> I'm really using jbi-maven-plugin for most of the modules, and that plugin
> binds the other plugins -also the compiler-plugin -to maven life-cycle phases.
--
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-4996) Maven3 parallel build fails occasionally for classpath problems.
[
http://jira.codehaus.org/browse/MNG-4996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253819#action_253819
]
Kristian Rosenvold commented on MNG-4996:
-
Thanks a lot, that's two very good pieces of information.
Artifact resolution (and classpath building) is a fairly long-winded process in
maven core. MavenProject#getCompileClasspathElements is probably a nice place
to start looking. (MaveProject line 419).
I would be very interested in knowing if the build files if you add the
following few lines:
public List getCompileClasspathElements()
throws DependencyResolutionRequiredException {
List list = new ArrayList(getArtifacts().size() + 1);
list.add(getBuild().getOutputDirectory());
if (resolvedArtifacts.size() == 0)
{
throw new InvalidStateException("No resolved artifacts?");
}
... rest of method ...
}
(Check out from https://svn.apache.org/repos/asf/maven/maven-3/trunk, mvn clean
install, zip file is in apache-maven/target/)
I do not think this should fail for most regular builds.
So if we could determine if resolvedArtifacts.size is 0 at the time you crash,
we would effectively split the
entire code base in 2. Binary search is a powerful tool with these things. Make
sure the patch works non-threaded first ;)
I am assuming these are all non-public builds ?
> Maven3 parallel build fails occasionally for classpath problems.
>
>
> Key: MNG-4996
> URL: http://jira.codehaus.org/browse/MNG-4996
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.0.1
> Environment: maven 3.0.1, maven 3.0
>Reporter: Kari J. Niemi
>Assignee: Kristian Rosenvold
>
> In a multimodule (>120 modules) maven build, the compiler plug-in would seem
> to fail in creating a correct class-path every now and then.
> Instead of this entry in maven -X logs for a single module build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ..
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes,
> /home/karniemi/.m2/repository/org/apache/servicemix/servicemix-utils/1.2.0/servicemix-utils-1.2.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-stax-api_1.0_spec/1.0.1/geronimo-stax-api_1.0_spec-1.0.1.jar,
>
> /home/karniemi/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.6/wstx-asl-3.2.6.jar,
>
> /home/karniemi/.m2/repository/org/apache/servicemix/specs/org.apache.servicemix.specs.jbi-api-1.0/1.4.0/org.apache.servicemix.specs.jbi-api-1.0-1.4.0.jar,
>
> /home/karniemi/.m2/repository/org/apache/geronimo/specs/geronimo-activation_1.1_spec/1.0.2/geronimo-activation_1.1_spec-1.0.2.jar,
> /home/karniemi/.m2/repository/log4j/log4j/1.2.14/log4j-1.2.14.jar]
>
> every now and then I get this in the parallel build:
>
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
> configurator -->
> ...
> [DEBUG] (f) classpathElements =
> [/home/karniemi/"mymodulepath"/target/classes]
>
> And of course the compilation fails because none of the dependencies are
> added to the classpath. Sometimes it goes fine in the multi-module build, but
> every now and then it fails for this.
> In both maven runs I can see that the dependencies are resolved fine:
> --
> [DEBUG] "mymodule":jar:DYNAMIC-SNAPSHOT
> [DEBUG]junit:junit:jar:4.7:test
> [DEBUG]org.apache.servicemix:servicemix-utils:jar:1.2.0:provided
> [DEBUG]
> org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:provided
> [DEBUG] org.codehaus.woodstox:wstx-asl:jar:3.2.6:provided
> [DEBUG]
> org.apache.servicemix.specs:org.apache.servicemix.specs.jbi-api-1.0:jar:1.4.0:provided
> (scope managed from compile) (version managed from 1.1.0)
> [DEBUG]
> org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:provided
> [DEBUG]log4j:log4j:jar:1.2.14:provided
> ---
>
> The pluginArtifactMap looks like this:
>
> [DEBUG] (s) pluginArtifactMap =
> {org.apache.maven.plugins:maven-surefire-plugin=org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.6:,
>
> org.apache.maven.surefire:surefire-booter=org.apache.maven.surefire:surefire-booter:jar:2.6:compile,
>
> org.apache.maven.surefire:surefire-api=org.apache.maven.surefire:surefire-api:jar:2.6:compile,
>
> org.apache.maven.surefire:maven-surefire-common=org.apache.maven.surefire:maven-surefire-common:jar:2.6:compile,
>
> org.apache.maven.shared:maven-common-artifact-filters=org.apache.maven.shared:maven-common-artifact-filters:jar:1.2:compile,
>
> org.codehaus.plexus:plexus-utils=org.codehaus
