[jira] [Created] (MENFORCER-389) Exclusions are not considered when looking at parent for requireReleaseDeps
Henri Tremblay created MENFORCER-389:
Summary: Exclusions are not considered when looking at parent for
requireReleaseDeps
Key: MENFORCER-389
URL: https://issues.apache.org/jira/browse/MENFORCER-389
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 3.0.0
Reporter: Henri Tremblay
I would like to prevent parent poms to be a snapshots. But I have a
multi-module project. The rule is this on the parent pom:
{code:java}
No Snapshots Allowed!
${project.groupId}:*
true
{code}
I would expect this to fail only when the parent pom is not in my groupId. But
it's not what it does. It just makes {{failWhenParentIsSnapshot}} unusable for
multi-module projects.
See [https://github.com/henri-tremblay/enforce-parent-bug] for a full project
to reproduce. Just type {{mvn enforcer:enforce}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] Commented: (MNG-5146) parent.relativePath Warning is very misleading
[ https://jira.codehaus.org/browse/MNG-5146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=284442#comment-284442 ] Henri Tremblay commented on MNG-5146: - From what I've seen (Maven 3.0.3) it seems that maven use a default parent relative path set to ... This is indeed invalid when the parent pom is not the in parent directory. What is strange is that this default value doesn't appear in the effective pom. So I can just guess that's what is happening. The workaround seems to be to set the relative path to relativePath/relativePath (empty path). The error then disappear but I don't know if there's any side effect. Maybe the simplest fix would be to mention the workaround in the error. Can't find the parent pom using the default relative path which is the parent directory of the project. Please set it to the actual path of your parent pom or disable the warning by setting an empty relative path (relativePath/relativePath) if the pom is not available on your local directory. ... probably could be nicer than that but you get the idea. parent.relativePath Warning is very misleading -- Key: MNG-5146 URL: https://jira.codehaus.org/browse/MNG-5146 Project: Maven 2 3 Issue Type: Bug Components: Errors Environment: Maven 3.0.3 Reporter: Scott MacDonald Priority: Minor When a parent pom.xml is located in a sibling directory as the children, and relativePath is not set in the parent element of the children, maven spits out a completely bogus, very misleading, warning message. For example, suppose com.fubar and com.parent are in sibling directories (along with a bunch of other modules), and com.fubar specifies com.parent as its parent, but does snot specify a parent.relativePath in it parent element. When you run a build, you get the following... [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for com.fubar:jar:1234.5 [WARNING] 'parent.relativePath' points at com.someRandomModule instead of com.parent, please verify your project structure @ line 10, column 11 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] The warning incorrectly states that the child pom has specified com.someRandomModule (a completely unrelated module) as its parent when that is completely not the case. The unlreated module, in this case, happens to be an existing module in a differrnt sibling directory, but otherwise has no relation whatsoever to the parent or child. It would be much better to warn about the actual problem The actual problem is that maven first tries to resolve parent poms locally based on the value of relativePath in the parent element of the child. IF it does not find it there, it will then resolve the parent from the repos. The current default value of relativepath is ../pom.xml (which in my case doesn;t work because my parent is in a sibling directory) The warning should be changed to something useful, such as [WARNING] Could not resolve parent pom locally using parent.relativePath value of ../pom.xml. Parent pom will be resolved from local or remote repository. To disable local parent pom resolution, specify relativePathrelativePath in you parent element. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2779) Please remove synchronisation for projects EasyMock and Objenesis
Please remove synchronisation for projects EasyMock and Objenesis - Key: MAVENUPLOAD-2779 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2779 Project: Maven Upload Requests Issue Type: Task Reporter: Henri Tremblay Both are synchronized from the EasyMock repository at this address http://www.easymock.org/maven/repository/ They will now be uploaded to Sonatype repository. URLs: http://www.easymock.org http://www.objenesis.org Contributor: http://www.easymock.org http://objenesis.googlecode.com/svn/docs/acknowledgements.html -- 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: (WAGON-306) maven-metadata-repository.xml not generated when deploying to repository via scpexe protocol
[ http://jira.codehaus.org/browse/WAGON-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=220416#action_220416 ] Henri Tremblay commented on WAGON-306: -- Erratum: It worked by luck once for some reason. I'm not sure if the error comes from SourceForge that is not fast enough or because of wagon. However, if I upload a release instead of a snapshot, eveything works fine. maven-metadata-repository.xml not generated when deploying to repository via scpexe protocol -- Key: WAGON-306 URL: http://jira.codehaus.org/browse/WAGON-306 Project: Maven Wagon Issue Type: Bug Components: wagon-ssh-external Environment: Linux u-235 2.6.10-gentoo-r4 #1 SMP Mon Jan 10 14:53:56 EST 2005 i686 AMD Athlon(tm) MP 2400+ AuthenticAMD GNU/Linux java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Lin Zhu Fix For: 1.0-alpha-4 Further to the below, if I deploy a project to the remote repository successfully via NFS and then switch over to scpexe, subsequent deployments over scpexe work as expected. This appears to be due to the presence of the maven-metadata.xml files in the repository. If I remove these the deployment breaks again. The root problem appears to be with the deployment and/or generation of the metadata when using scpexe. When broken, the root exception in the stack trace is: Caused by: java.io.FileNotFoundException: /home/amm/.m2/repository/com/distra/useful/useful/maven-metadata-distra.xml.tmp (No such file or directory) Checking my local repository reveals that the maven-metadata-distra.xml has not been generated. maven-metadata-local.xml is still generated. maven-metadata-distra.xml IS generated when deploying via NFS. So, in a nutshell, maven-metadata-repository.xml does not appear to be generated correctly when using the scpexe protocol. Would anyone care to confirm this before I raise a bug? I have tested with the normal scp protocol and deployment works as expected. Using scp however I have to hard-code my key's password in settings.xml. This is what I am trying to get around by using scpexe. Thanks, ...andrew andrew wrote: Maven version: 2.0-beta-1 Hi, Thanks to the maven devs for getting 2.0-beta-1 released. All the hard work is much appreciated. When attempting to deploy to a remote repository (via scpexe) with the new release I am getting a few exceptions [1]. The jar is uploaded to the repository correctly, however the POM is not and the build fails with the metadata related exceptions below. The scpexe protocol appears to be working correctly for the upload but some maven internal metadata processing doesn't like it. If I deploy to the same server path over NFS, everything works as expected. My project POM [2] and local settings.xml [3] are also attached. Any insight into this issue much appreciated. Thanks, ...andrew Listing 1: $ m2 -Dmaven.test.skip=true clean:clean deploy [INFO] Searching repository for plugin with prefix: 'clean'. [INFO] [INFO] Building distra - useful [INFO]task-segment: [clean:clean, deploy] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /secure/home/amm/prj/bt3/distra/useful/useful/target [INFO] [resources:resources] Downloading: http://repo1.maven.org/maven2/sun/java/tools/tools/1.4.2_08/tools-1.4.2_08.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [WARNING] * Using defaults for missing POM sun.java.tools:tools:pom:1.4.2_08 * [INFO] [compiler:compile] Compiling 211 source files to /secure/home/amm/prj/bt3/distra/useful/useful/target/classes [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 73 source files to /secure/home/amm/prj/bt3/distra/useful/useful/target/test-classes [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] [INFO] Building jar: /secure/home/amm/prj/bt3/distra/useful/useful/target/useful-1.0.jar [INFO] [install:install] [INFO] Installing /secure/home/amm/prj/bt3/distra/useful/useful/target/useful-1.0.jar to /home/amm/.m2/repository/com/distra/useful/useful/1.0/useful-1.0.jar [INFO] [deploy:deploy] Uploading: scpexe://office/data/development/bt3/m2/distra/com/distra/useful/useful/1.0/useful-1.0.jar [INFO] Retrieving previous metadata from distra [INFO] [ERROR] BUILD
[jira] Commented: (MNG-3643) maven-metadata-repository.xml not generated when deploying to repository via scpexe protocol
[ http://jira.codehaus.org/browse/MNG-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=220118#action_220118 ] Henri Tremblay commented on MNG-3643: - I just had the exact same issue. I've upgraded from 1.0-beta-5 to wagon-ssh-external version 1.0-beta-6 and it seems to have saved the day. maven-metadata-repository.xml not generated when deploying to repository via scpexe protocol -- Key: MNG-3643 URL: http://jira.codehaus.org/browse/MNG-3643 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Environment: Linux u-235 2.6.10-gentoo-r4 #1 SMP Mon Jan 10 14:53:56 EST 2005 i686 AMD Athlon(tm) MP 2400+ AuthenticAMD GNU/Linux java version 1.4.2_08 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) Reporter: Lin Zhu Fix For: 2.2.x (to be reviewed) Further to the below, if I deploy a project to the remote repository successfully via NFS and then switch over to scpexe, subsequent deployments over scpexe work as expected. This appears to be due to the presence of the maven-metadata.xml files in the repository. If I remove these the deployment breaks again. The root problem appears to be with the deployment and/or generation of the metadata when using scpexe. When broken, the root exception in the stack trace is: Caused by: java.io.FileNotFoundException: /home/amm/.m2/repository/com/distra/useful/useful/maven-metadata-distra.xml.tmp (No such file or directory) Checking my local repository reveals that the maven-metadata-distra.xml has not been generated. maven-metadata-local.xml is still generated. maven-metadata-distra.xml IS generated when deploying via NFS. So, in a nutshell, maven-metadata-repository.xml does not appear to be generated correctly when using the scpexe protocol. Would anyone care to confirm this before I raise a bug? I have tested with the normal scp protocol and deployment works as expected. Using scp however I have to hard-code my key's password in settings.xml. This is what I am trying to get around by using scpexe. Thanks, ...andrew andrew wrote: Maven version: 2.0-beta-1 Hi, Thanks to the maven devs for getting 2.0-beta-1 released. All the hard work is much appreciated. When attempting to deploy to a remote repository (via scpexe) with the new release I am getting a few exceptions [1]. The jar is uploaded to the repository correctly, however the POM is not and the build fails with the metadata related exceptions below. The scpexe protocol appears to be working correctly for the upload but some maven internal metadata processing doesn't like it. If I deploy to the same server path over NFS, everything works as expected. My project POM [2] and local settings.xml [3] are also attached. Any insight into this issue much appreciated. Thanks, ...andrew Listing 1: $ m2 -Dmaven.test.skip=true clean:clean deploy [INFO] Searching repository for plugin with prefix: 'clean'. [INFO] [INFO] Building distra - useful [INFO]task-segment: [clean:clean, deploy] [INFO] [INFO] [clean:clean] [INFO] Deleting directory /secure/home/amm/prj/bt3/distra/useful/useful/target [INFO] [resources:resources] Downloading: http://repo1.maven.org/maven2/sun/java/tools/tools/1.4.2_08/tools-1.4.2_08.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [WARNING] * Using defaults for missing POM sun.java.tools:tools:pom:1.4.2_08 * [INFO] [compiler:compile] Compiling 211 source files to /secure/home/amm/prj/bt3/distra/useful/useful/target/classes [INFO] [resources:testResources] [INFO] [compiler:testCompile] Compiling 73 source files to /secure/home/amm/prj/bt3/distra/useful/useful/target/test-classes [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] [INFO] Building jar: /secure/home/amm/prj/bt3/distra/useful/useful/target/useful-1.0.jar [INFO] [install:install] [INFO] Installing /secure/home/amm/prj/bt3/distra/useful/useful/target/useful-1.0.jar to /home/amm/.m2/repository/com/distra/useful/useful/1.0/useful-1.0.jar [INFO] [deploy:deploy] Uploading: scpexe://office/data/development/bt3/m2/distra/com/distra/useful/useful/1.0/useful-1.0.jar [INFO] Retrieving previous metadata from distra [INFO] [ERROR] BUILD ERROR [INFO]
[jira] Commented: (MAVENUPLOAD-2580) rsync Objenesis to maven central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=191611#action_191611 ] Henri Tremblay commented on MAVENUPLOAD-2580: - Hi, to make things easier, I now own the domain. It shall be active in 2 or 3 days. rsync Objenesis to maven central repository --- Key: MAVENUPLOAD-2580 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2580 Project: Maven Upload Requests Issue Type: Wish Reporter: Henri Tremblay Please configure the rsync for Objenesis which is deployed in the easymock repository. The rsync line: org.objenesis,mavens...@shell.sourceforge.net:/home/groups/e/ea/easymock/htdocs/maven/repository,rsync_ssh,Henri Tremblay,henri.tremb...@gmail.com,, -- 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: (MAVENUPLOAD-2580) rsync Objenesis to maven central repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=191525#action_191525 ] Henri Tremblay commented on MAVENUPLOAD-2580: - Sadly no. Nobody does. It's just the package we picked for objenesis. Older versions were added manually in the central repository following previous jira issues created by me. rsync Objenesis to maven central repository --- Key: MAVENUPLOAD-2580 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2580 Project: Maven Upload Requests Issue Type: Wish Reporter: Henri Tremblay Please configure the rsync for Objenesis which is deployed in the easymock repository. The rsync line: org.objenesis,mavens...@shell.sourceforge.net:/home/groups/e/ea/easymock/htdocs/maven/repository,rsync_ssh,Henri Tremblay,henri.tremb...@gmail.com,, -- 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: (MAVENUPLOAD-2580) rsync Objenesis to maven central repository
rsync Objenesis to maven central repository --- Key: MAVENUPLOAD-2580 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2580 Project: Maven Upload Requests Issue Type: Wish Reporter: Henri Tremblay Please configure the rsync for Objenesis which is deployed in the easymock repository. The rsync line: org.objenesis,mavens...@shell.sourceforge.net:/home/groups/e/ea/easymock/htdocs/maven/repository,rsync_ssh,Henri Tremblay,henri.tremb...@gmail.com,, -- 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: (MREACTOR-11) Can't pass a parameter with a comma to -Dmake.goals
[
http://jira.codehaus.org/browse/MREACTOR-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=187636#action_187636
]
Henri Tremblay commented on MREACTOR-11:
Historically, it wasn't possible to have two -P in the command line.
I just tried with maven 2.1.0 and it now seems to work.
If that's the case, indeed there's a nice workaround to my issue.
Can't pass a parameter with a comma to -Dmake.goals
---
Key: MREACTOR-11
URL: http://jira.codehaus.org/browse/MREACTOR-11
Project: Maven 2.x Reactor Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Henri Tremblay
Attachments: comma.patch
If tried to do
{{mvn reactor:make -Dmake.goals=install,-Pprofile1,profile2}}
If fails because {{-Pprofile1,profile2}} is split in two parameters.
My solution was to be able to escape a comma by doubling it.
Its implementation and the test case are in attachment.
--
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: (MPMD-99) Report doesn't reflect the real PMD version used
[ http://jira.codehaus.org/browse/MPMD-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Tremblay updated MPMD-99: --- Attachment: PmdReportListener.java I little bit dull but working solution is to retrieve the version by reflection. This is what I'm doing in the file. The same thing applies to CpdReportGenerator (although I didn't provided here). It works perfectly and I can't see how to get the version otherwise. Report doesn't reflect the real PMD version used Key: MPMD-99 URL: http://jira.codehaus.org/browse/MPMD-99 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.4 Reporter: Henri Tremblay Attachments: PmdReportListener.java If the PMD dependency is overloaded to a new version of PMD (by having a dependency section attached to the plugin definition in the pom.xml), PMD won't show the real PMD version used. This is because, the version shown following the The following document contains the results of on the html report is taken from PMD.VERSION which is inlined by the compiler at compilation and so is always 4.2.2. The solution is to use the one in the pmd.xml header (pmd version=4.2.5 timestamp=2009-06-04T18:29:18.945) which is always right. -- 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: (MPMD-99) Report doesn't reflect the real PMD version used
Report doesn't reflect the real PMD version used Key: MPMD-99 URL: http://jira.codehaus.org/browse/MPMD-99 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.4 Reporter: Henri Tremblay If the PMD dependency is overloaded to a new version of PMD (by having a dependency section attached to the plugin definition in the pom.xml), PMD won't show the real PMD version used. This is because, the version shown following the The following document contains the results of on the html report is taken from PMD.VERSION which is inlined by the compiler at compilation and so is always 4.2.2. The solution is to use the one in the pmd.xml header (pmd version=4.2.5 timestamp=2009-06-04T18:29:18.945) which is always right. -- 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-368) Dependency configuration in DependencyManagement with exclusions is ignored
[ http://jira.codehaus.org/browse/MECLIPSE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172182#action_172182 ] Henri Tremblay commented on MECLIPSE-368: - Any news on this one? It is really annoying and there's a patch and test case attached. I would have expect it sooner :-( Dependency configuration in DependencyManagement with exclusions is ignored --- Key: MECLIPSE-368 URL: http://jira.codehaus.org/browse/MECLIPSE-368 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.4 Environment: Ubuntu Linux 7.10 Reporter: jh Attachments: exclusion-example-20080116.zip, MECLIPSE-368.patch A transitive dependency which is defined in the DependencyManagement section with exclusions does not take these exclusions into account when generating an eclipse classpath. Example: - childProject has a dependency 'acegi-security-tiger' - parentProject has a dependencyManagement section that defines the version and the exclusions - acegi-security-tiger has a transitive dependency to acegi-security - parentProject has defined acegi-security and a number of exclusions one of which is spring-remoting 1.2.7 - childProject's classpath ends up with spring-remoting 1.2.7 as dependency - we are using spring 2.5.1 which does not have spring-remoting If I check dependencies with dependency:tree -Dscope=null the dependency resolving of acegi-security-tiger stops with acegi-security and no other transitive dependencies are added (all are excluded) Workaround is to add acegi-security in childProject's pom. Main concern here is that dependency resolution in the eclipse plugin seems to be different from the dependency 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] Created: (MREACTOR-11) Can't pass a parameter with a comma to -Dmake.goals
Can't pass a parameter with a comma to -Dmake.goals
---
Key: MREACTOR-11
URL: http://jira.codehaus.org/browse/MREACTOR-11
Project: Maven 2.x Reactor Plugin
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Henri Tremblay
Attachments: comma.patch
If tried to do
{{mvn reactor:make -Dmake.goals=install,-Pprofile1,profile2}}
If fails because {{-Pprofile1,profile2}} is split in two parameters.
My solution was to be able to escape a comma by doubling it.
Its implementation and the test case are in attachment.
--
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: (MREACTOR-12) Excluded projects are still in the make dependencies
Excluded projects are still in the make dependencies
Key: MREACTOR-12
URL: http://jira.codehaus.org/browse/MREACTOR-12
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Henri Tremblay
Attachments: exclusion.zip
In the example in attachment, the dependencies are:
* Main depends on Excluded
* Tck depends on main but excludes Excluded
Calling {{mvn reactor:make -Dmake.folders=tck}} will compile all three projects
but one would expect only Main and Tck to be compiled since Excluded is
excluded.
--
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: (MREACTOR-10) Parameters are not passed through
[
http://jira.codehaus.org/browse/MREACTOR-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=150107#action_150107
]
Henri Tremblay commented on MREACTOR-10:
Sorry, missed that in the documentation.
I must say it's quite a harsh syntax.
Some points to help others:
* You must specified a goal (like install) in that case.
{{-Dmake.goals=-Dmaven.test.skip=true}} doesn't work
* The syntax is {{-Dmake.goals=-Dmaven.test.skip=true,install}} (not a dot
between skip and true)
From the code, it's true that DefaultInvoker is quite command line oriented.
But why is it required to launch another process?
Anyway, thanks for the answer and the plugin :)
Parameters are not passed through
-
Key: MREACTOR-10
URL: http://jira.codehaus.org/browse/MREACTOR-10
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Environment: Windows XP. Maven 2.1.0-M1
Reporter: Henri Tremblay
Priority: Blocker
Parameters passed to maven in the -M form are not propogated to the inner
call to maven.
For instance:
{{mvn.bat reactor:make -Dmaven.test.skip=true
-Dmake.folders=java/utils/commons -Pjava,deploy}}
will launch the following call:
{{mvn.bat -B -N -r -D
maven.reactor.includes=java\pom.xml,java\tests\ut\pom.xml,java\utils\commons\pom.xml
install}}
As you can see, the maven.test.skip has disappear and so the tests are ran...
Which in this case prevents me from using the 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] Created: (MREACTOR-10) Parameters are not passed through
Parameters are not passed through
-
Key: MREACTOR-10
URL: http://jira.codehaus.org/browse/MREACTOR-10
Project: Maven 2.x Reactor Plugin
Issue Type: Bug
Affects Versions: 1.0
Environment: Windows XP. Maven 2.1.0-M1
Reporter: Henri Tremblay
Priority: Blocker
Parameters passed to maven in the -M form are not propogated to the inner call
to maven.
For instance:
{{mvn.bat reactor:make -Dmaven.test.skip=true -Dmake.folders=java/utils/commons
-Pjava,deploy}}
will launch the following call:
{{mvn.bat -B -N -r -D
maven.reactor.includes=java\pom.xml,java\tests\ut\pom.xml,java\utils\commons\pom.xml
install}}
As you can see, the maven.test.skip has disappear and so the tests are ran...
Which in this case prevents me from using the plugin. :-(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MREACTOR-6) Be able to build a given project
[ http://jira.codehaus.org/browse/MREACTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149020#action_149020 ] Henri Tremblay commented on MREACTOR-6: --- Awesome! I always thought that was only use to select something than the pom.xml to compile in the current directory. But it does change the basedir. :-) Be able to build a given project Key: MREACTOR-6 URL: http://jira.codehaus.org/browse/MREACTOR-6 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Affects Versions: 1.0 Reporter: Henri Tremblay A lots of times, I found myself doing all over the directory tree of my project to build a given project. It would be really useful to be able to build it from my parent directory. I'm not aware of a way to do so right now and I think the reactor plugin could be the right place. Something like: mvn reactor:build -Dproject=my/project Which would do a little bit like reactor:resume but building only one project. -- 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: (MREACTOR-6) Be able to build a given project
Be able to build a given project Key: MREACTOR-6 URL: http://jira.codehaus.org/browse/MREACTOR-6 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Affects Versions: 1.0 Reporter: Henri Tremblay A lots of times, I found myself doing all over the directory tree of my project to build a given project. It would be really useful to be able to build it from my parent directory. I'm not aware of a way to do so right now and I think the reactor plugin could be the right place. Something like: mvn reactor:build -Dproject=my/project Which would do a little bit like reactor:resume but building only one project. -- 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: (MREACTOR-6) Be able to build a given project
[ http://jira.codehaus.org/browse/MREACTOR-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=148902#action_148902 ] Henri Tremblay commented on MREACTOR-6: --- Hum... I just start to think if it worth it... Since a batch doing: pushd %1 mvn install popd might do pretty much the same thing Be able to build a given project Key: MREACTOR-6 URL: http://jira.codehaus.org/browse/MREACTOR-6 Project: Maven 2.x Reactor Plugin Issue Type: New Feature Affects Versions: 1.0 Reporter: Henri Tremblay A lots of times, I found myself doing all over the directory tree of my project to build a given project. It would be really useful to be able to build it from my parent directory. I'm not aware of a way to do so right now and I think the reactor plugin could be the right place. Something like: mvn reactor:build -Dproject=my/project Which would do a little bit like reactor:resume but building only one project. -- 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: (MAVENUPLOAD-2066) rsync EasyMock to maven central repository
rsync EasyMock to maven central repository -- Key: MAVENUPLOAD-2066 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2066 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Please configure the rsync with the easymock repository. The rsync line: org.easymock,[EMAIL PROTECTED]:/home/groups/e/ea/easymock/htdocs/maven/repository,rsync_ssh,Henri Tremblay,[EMAIL PROTECTED],, The question might be dumb but do I need any particular rights on the repository? (a+r?) And if I remove something from my repo, will it disappear from the central repository? Lastly, can I synchronise projects with another group id? (I'm thinking about Objenesis here) -- 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-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=132717#action_132717 ] Henri Tremblay commented on MNG-3268: - Nice! Thanks Paul Command line doesn't handle multiple -P correctly - Key: MNG-3268 URL: http://jira.codehaus.org/browse/MNG-3268 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.7 Reporter: Henri Tremblay Attachments: MNG-3268-maven-core.patch It is currently not possible to have more than one -P on the same command line. Only the first specified profile is considered. So if you do mvn -Pmain -Ptest only the main profile will be taken into account. This may sound enough but it's not when your maven call is wrapped into a batch file. Let's say you have a batch doing the compilation of a given module: a.bat - mvn install -Pmymodule %* - and you want to pass a special integration tests profile you would do: a.bat -Pintegration-tests But that won't work since you are not allowed to have two -P. To merge them in DOS shell is quite a pain in the *** -- 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-3301) is there any problems with proxy i tried every thing with settings.xml i dont why it happening like this we have to fix this issue
[ http://jira.codehaus.org/browse/MNG-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121699 ] Henri Tremblay commented on MNG-3301: - I had the exact same result and know how to reproduce. I can't tell Vincent is having the same issue. My setup: * settings.xml is in M2_HOME/conf and not in my user profile * I have a proxy defined and a repository mirroring central * antrun plugin is used * antrun is calling the ant/ task aiming to a ant file somewhere else From there, when compiling the project, maven stops using what's in the settings.xml and * try to download directly from central * don't use the proxy * doesn't use the correct local repository path (so I guess it's using the default) is there any problems with proxy i tried every thing with settings.xml i dont why it happening like this we have to fix this issue -- Key: MNG-3301 URL: http://jira.codehaus.org/browse/MNG-3301 Project: Maven 2 Issue Type: Task Components: Command Line Affects Versions: 2.0.7 Reporter: vamsikrishna org.apache.maven.lifecycle.LifecycleExecutionException: Missing: -- 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.wagon -DartifactId=wagon-webdav \ -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.wagon -DartifactId=wagon-webdav \ -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) com.intralinks.qa:qc-super-pom:pom:1.2-SNAPSHOT 2) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-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: (MAVENUPLOAD-1845) Upload Objenesis 1.1 and parent pom
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_118850 ] Henri Tremblay commented on MAVENUPLOAD-1845: - I'll look into it. But do you think you can do an exception for this one? There shouldn't be any new version delivered for a while (and even less of the parent). Upload Objenesis 1.1 and parent pom --- Key: MAVENUPLOAD-1845 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1845 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Attachments: pom.xml Can you upload objenesis 1.1 bundle and its parent pom (provided in attachment). If there's a better way to upload a parent pom, I'll be interested in knowing how. Thanks -- 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: (MAVENUPLOAD-1873) Please upload EasyMock Class Extension 2.3
Please upload EasyMock Class Extension 2.3 -- Key: MAVENUPLOAD-1873 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1873 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Can you please upload EasyMock Class Extension 2.3 to maven repository? - Thanks -- 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-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116129 ] Henri Tremblay commented on MNG-3118: - KlassJan, read the other comments. It seems the problem is coming from Surefire. So you can wait for the fix to be released or build the plugin yourself (if you do so, I would be interested in knowing if it worked) Test-classes should come before classes in the classpath Key: MNG-3118 URL: http://jira.codehaus.org/browse/MNG-3118 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.7 Reporter: Paul Gier Fix For: 2.0.8, 2.1-alpha-1 Attachments: MNG-3118-maven-project-r558713.patch Currently maven-project creates the test classpath in the order: classes, tests-classes, dependencies. It would be better if test-classes came first because sometimes it is useful for a test class to replace a main class during testing. The opposite case is not normally true (i.e. one would not want to override a test class with one of the main classes). -- 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-3118) Test-classes should come before classes in the classpath
[ http://jira.codehaus.org/browse/MNG-3118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115904 ] Henri Tremblay commented on MNG-3118: - Hi, are you sure of the fix? Because I'm using maven 2.0.7 and test-classes was first in the classpath for almost a year now. I just tried with maven 2.0.8, doesn't work anymore. classes path seems to be first. Is there a workaround? Because this ordering is indeed extremely useful. Test-classes should come before classes in the classpath Key: MNG-3118 URL: http://jira.codehaus.org/browse/MNG-3118 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.7 Reporter: Paul Gier Fix For: 2.0.8, 2.1-alpha-1 Attachments: MNG-3118-maven-project-r558713.patch Currently maven-project creates the test classpath in the order: classes, tests-classes, dependencies. It would be better if test-classes came first because sometimes it is useful for a test class to replace a main class during testing. The opposite case is not normally true (i.e. one would not want to override a test class with one of the main classes). -- 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-3268) Command line doesn't handle multiple -P correctly
Command line doesn't handle multiple -P correctly - Key: MNG-3268 URL: http://jira.codehaus.org/browse/MNG-3268 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.7 Reporter: Henri Tremblay It is currently not possible to have more than one -P on the same command line. Only the first specified profile is considered. So if you do mvn -Pmain -Ptest only the main profile will be taken into account. This may sound enough but it's not when your maven call is wrapped into a batch file. Let's say you have a batch doing the compilation of a given module: a.bat - mvn install -Pmymodule %* - and you want to pass a special integration tests profile you would do: a.bat -Pintegration-tests But that won't work since you are not allowed to have two -P. To merge them in DOS shell is quite a pain in the *** -- 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-3268) Command line doesn't handle multiple -P correctly
[ http://jira.codehaus.org/browse/MNG-3268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112412 ] Henri Tremblay commented on MNG-3268: - No. I know I can do -Pmain,test. What I need is two -P. One is directly in the batch file and one is passed by the user calling the batch file. The ones in the batch are the default for the script and the one added by the user are specific to a given batch call. For example, I want to deploy on an application server. The deploy.bat contains a -Pdeploy to tell mvn it should deploy during the build. Then the user pass a -Pdev to tell that he wants to deploy on the dev platform. That is not currently possible. And I don't want him to have to modify his settings.xml all the time. Command line doesn't handle multiple -P correctly - Key: MNG-3268 URL: http://jira.codehaus.org/browse/MNG-3268 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.7 Reporter: Henri Tremblay It is currently not possible to have more than one -P on the same command line. Only the first specified profile is considered. So if you do mvn -Pmain -Ptest only the main profile will be taken into account. This may sound enough but it's not when your maven call is wrapped into a batch file. Let's say you have a batch doing the compilation of a given module: a.bat - mvn install -Pmymodule %* - and you want to pass a special integration tests profile you would do: a.bat -Pintegration-tests But that won't work since you are not allowed to have two -P. To merge them in DOS shell is quite a pain in the *** -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-239) In format dir, be able to create a dir without the suffix .dir
In format dir, be able to create a dir without the suffix .dir -- Key: MASSEMBLY-239 URL: http://jira.codehaus.org/browse/MASSEMBLY-239 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-1 Reporter: Henri Tremblay For a assembly in format directory, it would be nice to be able to get rid of the format suffix (.dir). In a general way, I think being able to change the file extension would be nice. This will allow to remote the .dir (make sure le dot is also removable) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-239) In format dir, be able to create a dir without the suffix .dir
[ http://jira.codehaus.org/browse/MASSEMBLY-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106966 ] Henri Tremblay commented on MASSEMBLY-239: -- I can't change it but maybe priority major is a little bit high. I know that in the case of multiple formats, it won't work. So maybe the solution is to enrich the assembly descriptor to have: format name/name suffix/suffix /format Where suffix is by default the name. In format dir, be able to create a dir without the suffix .dir -- Key: MASSEMBLY-239 URL: http://jira.codehaus.org/browse/MASSEMBLY-239 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-1 Reporter: Henri Tremblay For a assembly in format directory, it would be nice to be able to get rid of the format suffix (.dir). In a general way, I think being able to change the file extension would be nice. This will allow to remote the .dir (make sure le dot is also removable) -- 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: (MAVENUPLOAD-1633) Request to upload EasyMock 2.3 to maven repository
Request to upload EasyMock 2.3 to maven repository -- Key: MAVENUPLOAD-1633 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1633 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Can you please upload EasyMock 2.3 to the maven repository. Thanks. -- 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: (MAVENUPLOAD-1474) Upload EasyMock class extension 2.2.2 to maven 1 and 2 repo
Upload EasyMock class extension 2.2.2 to maven 1 and 2 repo --- Key: MAVENUPLOAD-1474 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1474 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Assignee: Carlos Sanchez Can you please upload EasyMock class extension 2.2.1 to maven 1 and 2 repository -- 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: (MAVENUPLOAD-1474) Upload EasyMock class extension 2.2.2 to maven 1 and 2 repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Tremblay closed MAVENUPLOAD-1474. --- Resolution: Won't Fix Was expecting to be able to modify the issue after cloning it... Doesn't seem to be the case so I'll create a brand-new one. Upload EasyMock class extension 2.2.2 to maven 1 and 2 repo --- Key: MAVENUPLOAD-1474 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1474 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Assignee: Carlos Sanchez Can you please upload EasyMock class extension 2.2.1 to maven 1 and 2 repository -- 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: (MAVENUPLOAD-1475) Upload EasyMock class extension 2.2.2 to maven 1 and 2 repo
Upload EasyMock class extension 2.2.2 to maven 1 and 2 repo --- Key: MAVENUPLOAD-1475 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1475 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Can you please upload EasyMock class extension 2.2.2 to maven 1 and 2 repository? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-179) Assembled jar includes artifact names in path
[
http://jira.codehaus.org/browse/MASSEMBLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86111
]
Henri Tremblay commented on MASSEMBLY-179:
--
I totally agree with Milos. It works but assuming that it's a maybe useful
regression, it should at least be heavily documented.
Assembled jar includes artifact names in path
-
Key: MASSEMBLY-179
URL: http://jira.codehaus.org/browse/MASSEMBLY-179
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Jonathan Komorek
Priority: Critical
This issue does not occur in 2.1 and began occurring in 2.2-SNAPSHOT
(roughly) a couple months ago.
After assembling a jar, the path for each of the included files begins with
what seems to be ${artifactId}-${version}.${packaging}
This includes files from dependent jars and files from sub-modules - all
files.
The plugin is configured in the POM as follows:
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
executions
execution
id1/id
phasepackage/phase
goals
goalattached/goal
/goals
/execution
/executions
version2.2-SNAPSHOT/version
configuration
descriptorassembly.xml/descriptor
/configuration
/plugin
/plugins
/build
The entire assembly.xml is as follows:
assembly
iddependencies/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
scoperuntime/scope
/dependencySet
/dependencySets
/assembly
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-179) Assembled jar includes artifact names in path
[
http://jira.codehaus.org/browse/MASSEMBLY-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85730
]
Henri Tremblay commented on MASSEMBLY-179:
--
I think I've encountered the same issue. I use, in 2.1, to have a jar
containing a merge of jars from submodules. No, inside the final jar, there is
a root dir for project.
e.g.:
parent
sub-x
sub-y
will create a jar containing:
sub-x-0.1/.../my classes from sub-x
sub-y-0.1/.../my classes from sub-y
For sources/, the solution was to add
includeModuleDirectoryfalse/includeModuleDirectory but it isn't supported
for binaries. If definetly should and it it quite critical... I can't build
my application anymore with this plugin.
Assembled jar includes artifact names in path
-
Key: MASSEMBLY-179
URL: http://jira.codehaus.org/browse/MASSEMBLY-179
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Jonathan Komorek
Priority: Critical
This issue does not occur in 2.1 and began occurring in 2.2-SNAPSHOT
(roughly) a couple months ago.
After assembling a jar, the path for each of the included files begins with
what seems to be ${artifactId}-${version}.${packaging}
This includes files from dependent jars and files from sub-modules - all
files.
The plugin is configured in the POM as follows:
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
executions
execution
id1/id
phasepackage/phase
goals
goalattached/goal
/goals
/execution
/executions
version2.2-SNAPSHOT/version
configuration
descriptorassembly.xml/descriptor
/configuration
/plugin
/plugins
/build
The entire assembly.xml is as follows:
assembly
iddependencies/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
outputDirectory//outputDirectory
unpacktrue/unpack
scoperuntime/scope
/dependencySet
/dependencySets
/assembly
--
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: (MAVENUPLOAD-1218) Upload EasyMock class extension 2.2.1 to maven 1 and 2 repo
Upload EasyMock class extension 2.2.1 to maven 1 and 2 repo --- Key: MAVENUPLOAD-1218 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1218 Project: maven-upload-requests Issue Type: Task Reporter: Henri Tremblay Can you please upload EasyMock class extension 2.2.1 to maven 1 and 2 repository -- 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] Reopened: (MAVENUPLOAD-844) Easymock class extension 2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-844?page=all ] Henri Tremblay reopened MAVENUPLOAD-844: Sadly it still wrong. My pom.xml is ok but the one in the repository is using 2.1.3 as the cglib version. It should be 2.1_3 with and underscore (yes, cglib is versionning strangely the jars). The dependecy is the following: dependency groupIdcglib/groupId artifactIdcglib-nodep/artifactId version2.1_3/version /dependency Easymock class extension 2.2 Key: MAVENUPLOAD-844 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-844 Project: maven-upload-requests Type: Task Reporter: Henri Tremblay Assignee: Carlos Sanchez -- 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] Reopened: (MAVENUPLOAD-844) Easymock class extension 2.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-844?page=all ] Henri Tremblay reopened MAVENUPLOAD-844: I just learn the hard way how maven 2 is working compared to maven 1... So indeed, the cglib dependency is wrong in the pom. I've just fix it, tested it and re-upload the bundle at the same place. Can you please upload the new version? Sorry about that, Henri Easymock class extension 2.2 Key: MAVENUPLOAD-844 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-844 Project: maven-upload-requests Type: Task Reporter: Henri Tremblay Assignee: Carlos Sanchez -- 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
