[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
dependency
groupIdcom.bla/groupId
artifactIdblabla/artifactId
version1.0-SNAPSHOT/version
typetest-jar/type
scopetest/scope
/dependency
dependency
groupIdcom.bla/groupId
artifactIdblabla/artifactId
version1.0-SNAPSHOT/version
/dependency
{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=1065954view=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
distributionManagement
site
url${project.parent.distributionManagement.site.url}/subdir/url
/site
/distributionManagement
{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-tabpanelfocusedCommentId=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 parent/ 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-tabpanelfocusedCommentId=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 parent/ 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 configuration 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=253734#action_253734
]
luke w patterson commented on MNG-4998:
---
what about using a new expression like ${project.properties.myProperty} ?
in the plugin configuration 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
properties and effect expressions interpolated later, Maven 3 also allows
to update properties 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 properties.
--
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-tabpanelfocusedCommentId=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 parent/ 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-tabpanelfocusedCommentId=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 parent/ 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-tabpanelfocusedCommentId=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 parent/ 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 --- plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-eclipse-plugin/artifactId configuration wtpversion2.0/wtpversion downloadSourcestrue/downloadSources /configuration /plugin plugin artifactIdmaven-ejb-plugin/artifactId configuration ejbVersion3.0/ejbVersion archive manifest addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /plugins -- 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
profile
idmulti-module-coverage/id
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
executions
execution
idunpack-dependencies/id
phaseprocess-classes/phase
goals
goalunpack-dependencies/goal
/goals
configuration
outputDirectory${project.build.directory}/classes/outputDirectory
excludeClassifierstests/excludeClassifiers
/configuration
/execution
/executions
/plugin
/plugins
/build
/profile
{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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 uphanding 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 ListString getCompileClasspathElements()
throws DependencyResolutionRequiredException {
ListString list = new ArrayListString(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.plexus:plexus-utils:jar:2.0.5:compile,
