[jira] Updated: (SCM-648) Checkout should return 0 when cloning empty repo, with no master branch
[ https://jira.codehaus.org/browse/SCM-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-648: - Fix Version/s: 1.6 Assignee: Olivier Lamy > Checkout should return 0 when cloning empty repo, with no master branch > --- > > Key: SCM-648 > URL: https://jira.codehaus.org/browse/SCM-648 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Bertrand Paquet >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: patch, patch > > > The checkout git command fail if repo does not contain a master branch, > because the checkout try to do a git pull. > In the case of an empty remote repo, this patch only do a git clone. > After a such checkout, you can checkin a file, the remote branch will be > automatically created by git. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-648) Checkout should return 0 when cloning empty repo, with no master branch
[ https://jira.codehaus.org/browse/SCM-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-648. Resolution: Fixed fixed [rev 1204747|http://svn.apache.org/viewvc?view=revision&revision=1204747] Thanks ! > Checkout should return 0 when cloning empty repo, with no master branch > --- > > Key: SCM-648 > URL: https://jira.codehaus.org/browse/SCM-648 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Bertrand Paquet >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: patch, patch > > > The checkout git command fail if repo does not contain a master branch, > because the checkout try to do a git pull. > In the case of an empty remote repo, this patch only do a git clone. > After a such checkout, you can checkin a file, the remote branch will be > automatically created by git. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SCM-648) Checkout should return 0 when cloning empty repo, with no master branch
[ https://jira.codehaus.org/browse/SCM-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened SCM-648: -- reopen as something as suck with git svn and all test git repo during my commit :-( > Checkout should return 0 when cloning empty repo, with no master branch > --- > > Key: SCM-648 > URL: https://jira.codehaus.org/browse/SCM-648 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Bertrand Paquet >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: patch, patch > > > The checkout git command fail if repo does not contain a master branch, > because the checkout try to do a git pull. > In the case of an empty remote repo, this patch only do a git clone. > After a such checkout, you can checkin a file, the remote branch will be > automatically created by git. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-648) Checkout should return 0 when cloning empty repo, with no master branch
[ https://jira.codehaus.org/browse/SCM-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-648. Resolution: Fixed fixed [rev 1207047|http://svn.apache.org/viewvc?rev=1207047&view=rev] Thanks > Checkout should return 0 when cloning empty repo, with no master branch > --- > > Key: SCM-648 > URL: https://jira.codehaus.org/browse/SCM-648 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Bertrand Paquet >Assignee: Olivier Lamy >Priority: Minor > Fix For: 1.6 > > Attachments: patch, patch > > > The checkout git command fail if repo does not contain a master branch, > because the checkout try to do a git pull. > In the case of an empty remote repo, this patch only do a git clone. > After a such checkout, you can checkin a file, the remote branch will be > automatically created by git. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-647) SvnChangeLogConsumer parses filename incorrectly when file is copied from existing one
[
https://jira.codehaus.org/browse/SCM-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed SCM-647.
Resolution: Fixed
Fix Version/s: 1.6
Assignee: Olivier Lamy
fixed r1207257
Thanks !
> SvnChangeLogConsumer parses filename incorrectly when file is copied from
> existing one
> --
>
> Key: SCM-647
> URL: https://jira.codehaus.org/browse/SCM-647
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-svn
>Affects Versions: 1.5, 1.6
>Reporter: Petr Kozelka
>Assignee: Olivier Lamy
> Fix For: 1.6
>
> Attachments: scm-svn-origfile.patch
>
>
> Current implementations uses non-xml svn log for gathering information. It
> always returns everything after 5th char as the filename, which is a bug in
> cases like this:
> {quote} A
> /maven/scm/trunk/maven-scm-test/src/main/java/org/apache/maven/scm/ScmTestCase.java
> (from
> /maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/ScmTestCase.java:191665){quote}
> which indicate copying a path from existing revision.
> Note that this example was taken from the [svnlog2.txt line
> 510|https://svn.apache.org/viewvc/maven/scm/trunk/maven-scm-providers/maven-scm-providers-svn/maven-scm-provider-svnexe/src/test/resources/svn/changelog/svnlog2.txt?view=markup#l510]
> file in test resources.
> I suggest to fix it with the attached patch. It also enhances tests to assert
> that the parsed filenames are correct - not containing spaces and beginning
> with common path.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-581) Allow formats in configuration to override descriptor
[ https://jira.codehaus.org/browse/MASSEMBLY-581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284436#comment-284436 ] John Casey commented on MASSEMBLY-581: -- It seems like a reasonable enough thing, especially since the calculation of the assembly contents is meant to be format-agnostic as much as possible. I still think it's a good idea to have a "default" set of formats specified in the assembly itself, but overriding with a format subset (or even something completely separate) via plugin configuration makes sense, especially when reusing standard descriptors. > Allow formats in configuration to override descriptor > - > > Key: MASSEMBLY-581 > URL: https://jira.codehaus.org/browse/MASSEMBLY-581 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Benson Margulies > > I constantly find myself creating families of several descriptors that differ > only in 'formats'. I claim that it makes sense to treat formats as not part > of the spec of the assembly, but rather of how the spec is applied. > If no one objects, I'll write the code so that the configuration can contain > formats that override the descriptor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-621) Mercurial provider checkout should not default to tip
[ https://jira.codehaus.org/browse/SCM-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-621. Resolution: Fixed fixed r1207266. Thanks! > Mercurial provider checkout should not default to tip > - > > Key: SCM-621 > URL: https://jira.codehaus.org/browse/SCM-621 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.5 >Reporter: Kevin Calcagno >Assignee: Olivier Lamy >Priority: Critical > Fix For: 1.6 > > Attachments: hg-checkout-no-tip.patch > > > The checkout command for the Mercurial provider defaults to using "tip" as > the revision to clone if no explicit revision is specified, for example via > the scmVersion property when using the SCM plugin. > This poses a problem for repositories with branches because tip always points > to the most recent changeset in the repository regardless of branch. Thus > subsequent checkouts, even moments apart, using the same options could wind > up fetching completely different branches of code. > A better option is to simply not pass a revision to Hg if no scmVersion is > specified. This will cause Hg to resort to its default behavior: grab the > tip-most changeset from the default branch, or "tip" itself if the default > branch doesn't exist. > One potential downside of this solution is that it will result in cloning the > entire repository rather than just tip and its required ancestors. > Predictable behavior is worth the cost, however, and users with large > repositories can work around that limitation by explicitly making "default" > their default value for scmVersion. (Or "tip" if they want to preserve the > current behavior.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-623) Add a configuration mode to be able to use git svn (at least for release plugin)
[ https://jira.codehaus.org/browse/SCM-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-623: - Fix Version/s: (was: 1.6) 1.7 > Add a configuration mode to be able to use git svn (at least for release > plugin) > > > Key: SCM-623 > URL: https://jira.codehaus.org/browse/SCM-623 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Affects Versions: 1.5 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.7 > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-631) Mercurial SCM provider works with repository like centralized SCM's do
[ https://jira.codehaus.org/browse/SCM-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-631. Resolution: Fixed Assignee: Olivier Lamy fixed r1207290 Thanks! > Mercurial SCM provider works with repository like centralized SCM's do > -- > > Key: SCM-631 > URL: https://jira.codehaus.org/browse/SCM-631 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.6 > Environment: Ubuntu 11.04/ArchLinux > Maven 3.0.3 > Mercurial 1.7.5/1.9.1 >Reporter: Alexander Betaev >Assignee: Olivier Lamy > Fix For: 1.6 > > Attachments: maven-scm.patch, maven-scm-plugin.patch > > > Mercurial SCM provider works with repositories as if it is centralized SCM: > all operations are preceeded by "Clone" operation. > I assume that it should be very useful to put an option which switches > behaviour and turns off work with central repo. > Please look at the patch in attachment. I have turned pushChanges flag into > option I describe. It works for 'update' and 'checkout' operations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-631) Mercurial SCM provider works with repository like centralized SCM's do
[ https://jira.codehaus.org/browse/SCM-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284440#comment-284440 ] Olivier Lamy commented on SCM-631: -- @Alexander due to some other changes I have modified a bit the patch to be able to integrate it. Can you test it ? Thanks in advance. > Mercurial SCM provider works with repository like centralized SCM's do > -- > > Key: SCM-631 > URL: https://jira.codehaus.org/browse/SCM-631 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-mercurial (hg) >Affects Versions: 1.6 > Environment: Ubuntu 11.04/ArchLinux > Maven 3.0.3 > Mercurial 1.7.5/1.9.1 >Reporter: Alexander Betaev >Assignee: Olivier Lamy > Fix For: 1.6 > > Attachments: maven-scm.patch, maven-scm-plugin.patch > > > Mercurial SCM provider works with repositories as if it is centralized SCM: > all operations are preceeded by "Clone" operation. > I assume that it should be very useful to put an option which switches > behaviour and turns off work with central repo. > Please look at the patch in attachment. I have turned pushChanges flag into > option I describe. It works for 'update' and 'checkout' operations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[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-tabpanel&focusedCommentId=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 (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 () 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 > is not set in the 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 > in you element. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMD-135) Update to use and require Java 5
Update to use and require Java 5 Key: MPMD-135 URL: https://jira.codehaus.org/browse/MPMD-135 Project: Maven 2.x PMD Plugin Issue Type: Improvement Affects Versions: 2.6 Reporter: Dennis Lundberg We are currently using a backported version of the pmd library for Java 1.4. Starting with PMD 4.3 this is no longer available. We should update to use the Java 5 version of PMD and also update the plugin to take advantage of Java 5 features. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-581) Allow formats in configuration to override descriptor
[ https://jira.codehaus.org/browse/MASSEMBLY-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MASSEMBLY-581. -- Resolution: Fixed Fix Version/s: 2.3 /Users/benson/asf/mvn/plugins/maven-assembly-plugin svn log -r1207724 r1207724 | bimargulies | 2011-11-28 19:56:09 -0500 (Mon, 28 Nov 2011) | 2 lines MASSEMBLY-581: Allow formats in configuration to override descriptor > Allow formats in configuration to override descriptor > - > > Key: MASSEMBLY-581 > URL: https://jira.codehaus.org/browse/MASSEMBLY-581 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.1 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: 2.3 > > > I constantly find myself creating families of several descriptors that differ > only in 'formats'. I claim that it makes sense to treat formats as not part > of the spec of the assembly, but rather of how the spec is applied. > If no one objects, I'll write the code so that the configuration can contain > formats that override the descriptor. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-22) improve integration of the site into the assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-22: -- Issue Type: Improvement (was: Bug) > improve integration of the site into the assembly > - > > Key: MASSEMBLY-22 > URL: https://jira.codehaus.org/browse/MASSEMBLY-22 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Brett Porter > Fix For: 2.3 > > > it would be good to be able to automate the calling of site:site via a > lifecycle binding, but not sure how to make this optional depending on > arguments in the mojo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-22) improve integration of the site into the assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284462#comment-284462 ] Benson Margulies commented on MASSEMBLY-22: --- This no longer seems consistent with the way people use the assembly plugin (bound in the lifecycle). > improve integration of the site into the assembly > - > > Key: MASSEMBLY-22 > URL: https://jira.codehaus.org/browse/MASSEMBLY-22 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Brett Porter > Fix For: 2.3 > > > it would be good to be able to automate the calling of site:site via a > lifecycle binding, but not sure how to make this optional depending on > arguments in the mojo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-147) In multi project assembly, parent pom.xml not included in tar assembly
[
https://jira.codehaus.org/browse/MASSEMBLY-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MASSEMBLY-147.
--
Resolution: Cannot Reproduce
Fix Version/s: (was: 2.3)
Assignee: Benson Margulies
No repro after over a year.
> In multi project assembly, parent pom.xml not included in tar assembly
> --
>
> Key: MASSEMBLY-147
> URL: https://jira.codehaus.org/browse/MASSEMBLY-147
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Dominic Zaza
>Assignee: Benson Margulies
>Priority: Minor
>
> I'm trying to create a source bundle for a multi module project.
> I followed steps in
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-source-inclusion-simple.html
> and was able to product a tar file.
> However, my parent pom.xml is not included in the result tar file.
> Additionally, I would like to "not" include my tests. I attempted to use the
> following
>
>
>
> ${artifactId}
>
> */src/test/*
>
>
>
>
> However, didn't work
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-203) assembly:attached creates empty assemblies in reactor builds, but works fine in normal builds
[ https://jira.codehaus.org/browse/MASSEMBLY-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MASSEMBLY-203. -- Resolution: Won't Fix Fix Version/s: (was: 2.3) Assignee: Benson Margulies This goal is deprecated. > assembly:attached creates empty assemblies in reactor builds, but works fine > in normal builds > - > > Key: MASSEMBLY-203 > URL: https://jira.codehaus.org/browse/MASSEMBLY-203 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: java version "1.5.0_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_09-b01, mixed mode) >Reporter: Graham Leggett >Assignee: Benson Margulies > > When attaching an assemply to the package phase as below, and running mvn > install, the assembly is built without a problem. > If however the assembly is a sub-artifact built as part of a reactor / > multimodule build, mvn install in the root pom produces an empty assembly. > The kludge workaround is to cd to the assembly artifact directory and run mvn > install from there. > > maven-assembly-plugin > 2.2-beta-1 > > > assembly.xml > > > > > make-assembly > package > > attached > > > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-252) Please create an executable archive (xar) plugin similar to war
[ https://jira.codehaus.org/browse/MASSEMBLY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MASSEMBLY-252. -- Resolution: Not A Bug This is a request for a new maven plugin, not a feature of the assembly plugin. > Please create an executable archive (xar) plugin similar to war > --- > > Key: MASSEMBLY-252 > URL: https://jira.codehaus.org/browse/MASSEMBLY-252 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.2-beta-1 > Environment: any >Reporter: Iyad Elian > > There is no archetype to build an executable jar for batchapp's. clone the > war plugin and modify slightly to have APP-INF instead of WEB-INF and > command-config.xml instead of web.xml. META-INF/MANIFEST.MF is a must. it has > a main class and specifies jars under APP-INF/lib in its classpath. artifact > produced can then be executed from the command line using java -jar > . Can contribute code if description not clear. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-219) repository stores SNAPSHOTs in a wrong location
[ https://jira.codehaus.org/browse/MASSEMBLY-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-219: --- Fix Version/s: (was: 2.3) > repository stores SNAPSHOTs in a wrong location > --- > > Key: MASSEMBLY-219 > URL: https://jira.codehaus.org/browse/MASSEMBLY-219 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 >Reporter: Stephane Nicoll > > I am creating a simple repository with SNAPSHOTs > true test > repo > The assembly plugins stores SNAPSHOTs in a wrong location (see the name of > the directory with the timestamp) shared > |-- bar > | `-- foo-bar > | |-- 5.10.4-20070613.122033-2 > | | |-- foo-bar-5.10.4-20070613.122033-2-obfuscated.jar > | | |-- foo-bar-5.10.4-20070613.122033-2-obfuscated.jar.md5 > | | `-- foo-bar-5.10.4-20070613.122033-2-obfuscated.jar.sha1 > | |-- 5.10.4-SNAPSHOT > | | |-- foo-bar-5.10.4-SNAPSHOT.pom > | | |-- foo-bar-5.10.4-SNAPSHOT.pom.md5 > | | `-- foo-bar-5.10.4-SNAPSHOT.pom.sha1 > | |-- maven-metadata-central.xml > | |-- maven-metadata-central.xml.md5 > | |-- maven-metadata-central.xml.sha1 > | |-- maven-metadata.xml > | |-- maven-metadata.xml.md5 > | `-- maven-metadata.xml.sha1 > Non snapshot artifacts are stored properly -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-553) Assembly plugin ignores attached assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MASSEMBLY-553:
---
Fix Version/s: (was: 2.3)
> Assembly plugin ignores attached assemblies
> ---
>
> Key: MASSEMBLY-553
> URL: https://jira.codehaus.org/browse/MASSEMBLY-553
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 2.2.1
>Reporter: SebbASF
>Assignee: John Casey
>Priority: Critical
> Attachments: assembly-bug.zip
>
>
> This used to work in 2.2-beta-5, but both 2.2 and 2.2.1 seem to ignore
> attached descriptors in "mvn install"
> Sample project to follow.
> This works:
> mvn -Dass.vers=2.2-beta-5 install -Prc
> This does not:
> mvn -Dass.vers=2.2.1 install -Prc
> If you compare the ouput from the two runs, you will see that the following
> is missing from 2.2.1:
> [INFO] [assembly:attached {execution: default}]
> [INFO] Reading assembly descriptor: src/assembly/bin.xml
> [INFO] Reading assembly descriptor: src/assembly/src.xml
> [INFO] Building zip:
> D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-bin.zip
> [INFO] Building zip:
> D:\maven-tests\assembly-bug\target\assembly-bug-1.0-SNAPSHOT-src.zip
> Apache Commons cannot use 2.2 or 2.2.1 as a result of this bug
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-434) Repository: Impossible to exclude POMs or POM checksums from repository
[
https://jira.codehaus.org/browse/MASSEMBLY-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MASSEMBLY-434:
---
Fix Version/s: (was: 2.3)
> Repository: Impossible to exclude POMs or POM checksums from repository
> ---
>
> Key: MASSEMBLY-434
> URL: https://jira.codehaus.org/browse/MASSEMBLY-434
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-4
>Reporter: John Casey
>
> POMs and POM checksum files should be excluded if
> {noformat}
> includeMetadata == false
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-555) Need a better solution than packaging == pom for distribution modules whose output is an assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-555: --- Fix Version/s: (was: 2.3) > Need a better solution than packaging == pom for distribution modules whose > output is an assembly > - > > Key: MASSEMBLY-555 > URL: https://jira.codehaus.org/browse/MASSEMBLY-555 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2.1 >Reporter: John Casey >Assignee: John Casey > > It's common practice to use a purpose-built module to create a distribution > assembly for a project. However, there is no packaging that accommodates > this. We need one or more packagings added to the assembly plugin that will > allow a proper non-pom packaging. > Currently, this is an issue if someone tries to create one assembly from a > purpose-built module - say, for an examples aggregation - and then use it in > another assembly via moduleSet/binaries. Since the packaging is 'pom', the > project is NOT included in the moduleSet, because POMs are assumed not to > have binaries. Or, if they do, they're assumed to have binaries that are > addressable via some classifier...which I'm still not sure would even work > with the assembly plugin. > Bottom line is, we need a better solution than abusing the pom packaging for > assembly modules. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-22) improve integration of the site into the assembly
[ https://jira.codehaus.org/browse/MASSEMBLY-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-22: -- Fix Version/s: (was: 2.3) > improve integration of the site into the assembly > - > > Key: MASSEMBLY-22 > URL: https://jira.codehaus.org/browse/MASSEMBLY-22 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Brett Porter > > it would be good to be able to automate the calling of site:site via a > lifecycle binding, but not sure how to make this optional depending on > arguments in the mojo. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-551) dependencySet with useTransitiveDependencies == false does not process relocations
[ https://jira.codehaus.org/browse/MASSEMBLY-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-551: --- Fix Version/s: (was: 2.3) > dependencySet with useTransitiveDependencies == false does not process > relocations > -- > > Key: MASSEMBLY-551 > URL: https://jira.codehaus.org/browse/MASSEMBLY-551 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.2.1 >Reporter: John Casey >Assignee: John Casey > > relocations processing happens in the dependency collector in Maven, which is > used to create the full list of transitive dependencies during the resolution > process. When the assembly plugin processes a dependencySet non-transitively > it bypasses this dependency collector, and relocations are never processed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-101) META-INF/plexus/components.xml are being processed even if it is excluded or not included
[ https://jira.codehaus.org/browse/MASSEMBLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-101: --- Fix Version/s: (was: 2.3) > META-INF/plexus/components.xml are being processed even if it is excluded or > not included > - > > Key: MASSEMBLY-101 > URL: https://jira.codehaus.org/browse/MASSEMBLY-101 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: Edwin Punzalan >Priority: Minor > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-96) using fileSet -> lineEnding will always put the selected lineEnding at the end of the file, even if the original file does not end in one
[
https://jira.codehaus.org/browse/MASSEMBLY-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MASSEMBLY-96:
--
Fix Version/s: (was: 2.3)
> using fileSet -> lineEnding will always put the selected lineEnding at the
> end of the file, even if the original file does not end in one
> -
>
> Key: MASSEMBLY-96
> URL: https://jira.codehaus.org/browse/MASSEMBLY-96
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Edwin Punzalan
>
> example
> Original File:
> {code}
> first line\r\n
> second line
> {code}
> New File:
> {code}
> first line\n
> second line\n
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-442) no way to avoid using detected user/group information for files and directories in tarballs
[ https://jira.codehaus.org/browse/MASSEMBLY-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-442: --- Fix Version/s: (was: 2.3) > no way to avoid using detected user/group information for files and > directories in tarballs > --- > > Key: MASSEMBLY-442 > URL: https://jira.codehaus.org/browse/MASSEMBLY-442 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 >Reporter: John Casey >Priority: Critical > > this involves quite a bit of new code, to support specifying > user/group/uid/gid for all (files, fileSets, directories (unpacked, > reformatted dependencies), and dependencies unpacked directly into the new > archive. > Moving to 2.3-beta-1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-373) Support overriding a file found in successive fileSet/dependencySet/file entries
[ https://jira.codehaus.org/browse/MASSEMBLY-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-373: --- Fix Version/s: (was: 2.3) > Support overriding a file found in successive fileSet/dependencySet/file > entries > > > Key: MASSEMBLY-373 > URL: https://jira.codehaus.org/browse/MASSEMBLY-373 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-3 >Reporter: John Casey > > currently, the default behavior is to skip successive files that collide with > those already added to an archive. We have the ability to add all copies, > which is next to useless, but we don't have the ability to overwrite previous > copies with successive ones. This is a pretty complex change to > plexus-archiver, so I'm branching this issue off from MASSEMBLY-285 to track > it for the 2.2 release. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-218) repository does not handle classified artifacts properly
[
https://jira.codehaus.org/browse/MASSEMBLY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MASSEMBLY-218:
---
Fix Version/s: (was: 2.3)
> repository does not handle classified artifacts properly
>
>
> Key: MASSEMBLY-218
> URL: https://jira.codehaus.org/browse/MASSEMBLY-218
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Stephane Nicoll
>
> I am creating a simple repository with a project that contains classified
> dependencies (obfuscated jars):
> true test
> repo
> The assembly plugins generates a weird structure based on that: shared
> {noformat}
> |-- bar
> | `-- foo-bar
> | |-- 5.10.4-20070613.122033-2
> | | |-- foo-bar-5.10.4-20070613.122033-2-obfuscated.jar
> | | |-- foo-bar-5.10.4-20070613.122033-2-obfuscated.jar.md5
> | | `-- foo-bar-5.10.4-20070613.122033-2-obfuscated.jar.sha1
> | |-- 5.10.4-SNAPSHOT
> | | |-- foo-bar-5.10.4-SNAPSHOT.pom
> | | |-- foo-bar-5.10.4-SNAPSHOT.pom.md5
> | | `-- foo-bar-5.10.4-SNAPSHOT.pom.sha1
> | |-- maven-metadata-central.xml
> | |-- maven-metadata-central.xml.md5
> | |-- maven-metadata-central.xml.sha1
> | |-- maven-metadata.xml
> | |-- maven-metadata.xml.md5
> | `-- maven-metadata.xml.sha1
> {noformat}
> Non classified dependencies are stored properly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-45) Support for mappers in assembly desriptors
[ https://jira.codehaus.org/browse/MASSEMBLY-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-45: -- Fix Version/s: (was: 2.3) > Support for mappers in assembly desriptors > -- > > Key: MASSEMBLY-45 > URL: https://jira.codehaus.org/browse/MASSEMBLY-45 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Reporter: Anuerin Diaz > Attachments: maven-assembly-plugin.patch > > > I would like to forward a wish to have the assembly plugin support the notion > of file mappers similar to the ones in Ant[1]. To illustrate, assuming a > multi-module project with the following layout: > Root >|-Module1 >|-Module2 >|-Container >| |-Module3 >| |-Module4 >|-Module5 >|- pom.xml > and an assembly desriptor entry for the contained modules like this > > > Container > > > **/target/*.jar > > > > The assembly plugin will be able to get all jar files produced by Module3 and > Module4 but the "Container//target" structure will still be > included. One workaround is to enumerate each artifact but > problematic if the number of contained sub-modules is numerous. Support for > filemappers which look like this: > > > Container > > > **/target/*.jar > > > > > will cause all contained jar files to be copied without their original > structure. This feature would be useful for globbing artifact names as well > as for physically organizing project structures according to type. > [1] http://ant.apache.org/manual/CoreTypes/mapper.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-215) The maven-assembly-plugin doesn't support unpacking .rar extensions
[ https://jira.codehaus.org/browse/MASSEMBLY-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-215: --- Fix Version/s: (was: 2.3) > The maven-assembly-plugin doesn't support unpacking .rar extensions > --- > > Key: MASSEMBLY-215 > URL: https://jira.codehaus.org/browse/MASSEMBLY-215 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2-beta-1 > Environment: Any >Reporter: James Abley >Priority: Minor > > [INFO] Failed to create assembly: Error adding file-set for > 'org.apache.jackrabbit:jackrabbit-jca:rar:1.3' to archive: Error > adding archived file-set. UnArchiver not found for: C:\ > Users\jabley\.m2\repository\org\apache\jackrabbit\jackrabbit-jca\1.3\jackrabbit-jca-1.3.rar > No such archiver: 'rar'. > See also http://jira.codehaus.org/browse/PLXCOMP-67 > Perhaps the type of unarchiver should be configurable? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-357) transitive dependencies erroneously excluded from dependencySet in some cases
[
https://jira.codehaus.org/browse/MASSEMBLY-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MASSEMBLY-357:
---
Fix Version/s: (was: 2.3)
> transitive dependencies erroneously excluded from dependencySet in some cases
> -
>
> Key: MASSEMBLY-357
> URL: https://jira.codehaus.org/browse/MASSEMBLY-357
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: John Casey
>
> Given the following dependencies in a POM:
> {code:xml}
>
> commons-codec
> commons-codec
> 1.3
>
>
> commons-httpclient
> commons-httpclient
> 3.1
>
> {code}
> ..and the following assembly descriptor snippet:
> {code:xml}
>
>
> commons-codec*
>
> codec
> false
> true
>
>
>
> commons-httpclient*
>
> httpclient
> true
> true
> false
>
> {code}
> commons-codec *should* wind up in both the codec and httpclient dirs, but
> it's only in the codec dir. The reason for this is found in the
> maven-artifact code used to resolve dependencies. Since commons-codec is
> present as a direct dependency, it's *removed* from the sub-tree rooted by
> commons-httpclient, and its dependency trail doesn't contain even a whisper
> of this sub-tree structure. Since the transitive inclusions in dependencySets
> are calculated using artifact identifications (dependencyConflictId and id
> itself), along with the dependency trail it contains, the assembly plugin
> can't see the association between commons-httpclient and commons-codec,
> resulting in incomplete filtering for the dependencySet.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-176) Assembly goal does not handle ear files with zip format
[ https://jira.codehaus.org/browse/MASSEMBLY-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-176: --- Fix Version/s: (was: 2.3) > Assembly goal does not handle ear files with zip format > --- > > Key: MASSEMBLY-176 > URL: https://jira.codehaus.org/browse/MASSEMBLY-176 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Windows Server 2003 Enterprise Edition >Reporter: Gary Tilden > > When using the assembly goal and creating a zip file with a dependency on an > ear the ear is lost when installed. > However, when the directory-inline goal is used the ear is included, but with > a file name that has extra characters. I don't know if the ZIP format has a > problem with ear files. Another reason could be that the ear is currently a > SNAPSHOT version. > I haven't found any documentation on this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-433) In , exclusion matching project artifact also excludes all project dependencies.
[ https://jira.codehaus.org/browse/MASSEMBLY-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-433: --- Fix Version/s: (was: 2.3) > In , exclusion matching project artifact also excludes all > project dependencies. > > > Key: MASSEMBLY-433 > URL: https://jira.codehaus.org/browse/MASSEMBLY-433 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-4 >Reporter: John Casey > > I need a way to create a repository containing all of the project > dependencies at a certain scope. It appears that if I add an exclusion > pattern to exclude the project artifact, all project dependencies are > excluded as well. If I don't exclude the project artifact, it lands in the > repository along with the project dependencies. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-556) mvn assembly:assembly NPEs with install:install-file'd artifacts
[
https://jira.codehaus.org/browse/MASSEMBLY-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MASSEMBLY-556:
---
Fix Version/s: (was: 2.3)
> mvn assembly:assembly NPEs with install:install-file'd artifacts
>
>
> Key: MASSEMBLY-556
> URL: https://jira.codehaus.org/browse/MASSEMBLY-556
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-5
> Environment: Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) on Win
> 7 x64, Sun Java 6u24 x64.
>Reporter: Chris West (Faux)
>Assignee: John Casey
> Attachments: build.log, massembly-556-2.tar.gz, massembly-556.tar.gz,
> pom.xml, repository.xml
>
>
> I have 3rd-party jars installed via. {{mvn install:install-file}}. This
> causes {{mvn assembly:assembly}} to NPE around:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.getLocalFilename(AbstractRepositoryMetadata.java:61)
> at
> org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOfLocalRepositoryMetadata(DefaultRepositoryLayout.java:72)
> ...
> {code}
> To reproduce, first, install:install-file a random file:
> {code}
> mvn install:install-file -Dfile=pom.xml -DgroupId=com.goeswhere.test
> -DartifactId=a -Dversion=0 -Dpackaging=jar
> {code}
> Then, create pom.xml (attached):
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.goeswhere.test
> b
> 1.0-SNAPSHOT
> jar
>
>
> com.goeswhere.test
> a
> 0
>
>
>
>
>
> maven-assembly-plugin
>
>
>
> ./repository.xml
>
>
>
>
>
>
> {code}
> and repository.xml (attached):
> {code:xml}
>
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> repository
>
> jar
>
>
>
> true
> maven2
>
>
>
> {code}
> And run {{mvn assembly:assembly}}. See attached build.log.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-75) Unpacked TAR dependencies do not preserve file mode nor uid/gid
[ https://jira.codehaus.org/browse/MASSEMBLY-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-75: -- Fix Version/s: (was: 2.3) > Unpacked TAR dependencies do not preserve file mode nor uid/gid > --- > > Key: MASSEMBLY-75 > URL: https://jira.codehaus.org/browse/MASSEMBLY-75 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.0.1 >Reporter: Maciej Szefler >Assignee: John Casey > > "TAR" Assemblies generated from unpacking another TAR do not preserver the > extended file information (uid/gid/mod). For example: > if bar.tar contains an executable file "baz" and > if our .pom has the following dependency: > > foo > bar > tar > compile > > and our assembly.xml has the following: > > > > tar.gz > > > > > compile > > > foo:bar > > true > > then the generated assembly will contain "baz", but it will no longer be > executable. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-399) jar-with-dependencies descriptor adding files twice
[ https://jira.codehaus.org/browse/MASSEMBLY-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MASSEMBLY-399: --- Fix Version/s: (was: 2.3) > jar-with-dependencies descriptor adding files twice > --- > > Key: MASSEMBLY-399 > URL: https://jira.codehaus.org/browse/MASSEMBLY-399 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-3 > Environment: windows xp > maven 2.0.7 >Reporter: Soraya Sanchez >Assignee: John Casey > > When generating a .jar with the project dependencies, files are being added > twice to the jar (but in a location related to the absolute location). > When the plugin configuration is as follows: > > maven-assembly-plugin > 2.2-beta-3 > > > jar-with-dependencies > > > > > src/main/resources/META-INF/MANIFEST.MF > > > > > package > > attached > > > > > The generated jar is: > + the-jar > + com > + ... > + TheClass.class >+ C: > + workspace > + ... > + TheClass.class > that is, the files are being properly added from the project but, the C: > folder should not exist (it contains, once more, the files located under com) > If using the plugin version 2.2-beta-2 the files are included twice as well > but, the following way: > + the-jar > + com > + TheClass.class > + TheClass.class > whereas, if using version is 2.2-beta-1 the file is being generated properly > (no duplicate files at all). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-567) Version wildcard in dependencySet include does not work
[ https://jira.codehaus.org/browse/MASSEMBLY-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284466#comment-284466 ] Benson Margulies commented on MASSEMBLY-567: It's not just wildcards that are broken, even putting the correct version into place manually fails. > Version wildcard in dependencySet include does not work > --- > > Key: MASSEMBLY-567 > URL: https://jira.codehaus.org/browse/MASSEMBLY-567 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.2.1 > Environment: Windows XP > maven 2.2.1, 3.0.3 >Reporter: Stephan Oudmaijer >Priority: Critical > > In our assembly descriptor we use a version wildcard for a dependencySet > include, see the following snippet: > > ./configuration > > com.xyz.admin:xyz-admin-tool-config:*:zip:config > > true > > This used to work in version 2.2-beta-5 but since 2.2 but also in 2.2.1 this > does not work anymore. The version wildcard causes problems. According to the > documentation: > Artifacts are matched by a set of identifier strings. In the following > strings, type is 'jar' by default, and classifier is omitted if null. > groupId:artifactId:version:type:classifier ( artifact.getId() ) > Any '*' character in an include/exclude pattern will result in the pattern > being split, and the sub-patterns being matched within the three artifact > identifiers mentioned above, using String.indexOf(..). > I suspect this is a bug? Or the behavior has changed, but this is not in-line > with the documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-567) Version wildcard in dependencySet include does not work
[ https://jira.codehaus.org/browse/MASSEMBLY-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=284467#comment-284467 ] Benson Margulies edited comment on MASSEMBLY-567 at 11/28/11 7:54 PM: -- As far as I can tell, the spec order has always been the following, which is what is in the doc. I just tried it (with the current snapshot) and it worked fine, with a * in version. groupId:artifactId:type:version[:classifier] was (Author: bmargulies): groupId:artifactId:type:version[:classifier] > Version wildcard in dependencySet include does not work > --- > > Key: MASSEMBLY-567 > URL: https://jira.codehaus.org/browse/MASSEMBLY-567 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.2.1 > Environment: Windows XP > maven 2.2.1, 3.0.3 >Reporter: Stephan Oudmaijer >Assignee: Benson Margulies >Priority: Critical > Fix For: 2.2.1 > > > In our assembly descriptor we use a version wildcard for a dependencySet > include, see the following snippet: > > ./configuration > > com.xyz.admin:xyz-admin-tool-config:*:zip:config > > true > > This used to work in version 2.2-beta-5 but since 2.2 but also in 2.2.1 this > does not work anymore. The version wildcard causes problems. According to the > documentation: > Artifacts are matched by a set of identifier strings. In the following > strings, type is 'jar' by default, and classifier is omitted if null. > groupId:artifactId:version:type:classifier ( artifact.getId() ) > Any '*' character in an include/exclude pattern will result in the pattern > being split, and the sub-patterns being matched within the three artifact > identifiers mentioned above, using String.indexOf(..). > I suspect this is a bug? Or the behavior has changed, but this is not in-line > with the documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-567) Version wildcard in dependencySet include does not work
[ https://jira.codehaus.org/browse/MASSEMBLY-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MASSEMBLY-567. -- Resolution: Not A Bug Fix Version/s: 2.2.1 Assignee: Benson Margulies groupId:artifactId:type:version[:classifier] > Version wildcard in dependencySet include does not work > --- > > Key: MASSEMBLY-567 > URL: https://jira.codehaus.org/browse/MASSEMBLY-567 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.2.1 > Environment: Windows XP > maven 2.2.1, 3.0.3 >Reporter: Stephan Oudmaijer >Assignee: Benson Margulies >Priority: Critical > Fix For: 2.2.1 > > > In our assembly descriptor we use a version wildcard for a dependencySet > include, see the following snippet: > > ./configuration > > com.xyz.admin:xyz-admin-tool-config:*:zip:config > > true > > This used to work in version 2.2-beta-5 but since 2.2 but also in 2.2.1 this > does not work anymore. The version wildcard causes problems. According to the > documentation: > Artifacts are matched by a set of identifier strings. In the following > strings, type is 'jar' by default, and classifier is omitted if null. > groupId:artifactId:version:type:classifier ( artifact.getId() ) > Any '*' character in an include/exclude pattern will result in the pattern > being split, and the sub-patterns being matched within the three artifact > identifiers mentioned above, using String.indexOf(..). > I suspect this is a bug? Or the behavior has changed, but this is not in-line > with the documentation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
