[jira] (MSHARED-257) extract merge feature from Xpp3Dom
Herve Boutemy created MSHARED-257: - Summary: extract merge feature from Xpp3Dom Key: MSHARED-257 URL: https://jira.codehaus.org/browse/MSHARED-257 Project: Maven Shared Components Issue Type: Wish Components: maven-shared-utils Affects Versions: maven-shared-utils-0.1 Reporter: Herve Boutemy 2 static "mergeXpp3Dom" methods + constants: nothing that really belongs to Xpp3Dom BTW, this will ease MSHARED-255 (and perhaps the same DomUtils class should provide the API simultaneously for Xpp3Dom and W3C DOM) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-221) DefaultMojoAnnotationsScanner fails to scan some dependencies
[
https://jira.codehaus.org/browse/MPLUGIN-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPLUGIN-221.
-
Resolution: Not A Bug
Assignee: Herve Boutemy
as written in MPIR-142
{quote}it's a known bug in icu4j 2.6: see [ticket
#6505|http://icu-project.org/trac/ticket/6505], which shows the problem wihtout
Maven or bcel but directly a JVM
marked as fixed in icu4j 2.8: see [ticket
#3209|http://icu-project.org/trac/ticket/3209]{quote}
> DefaultMojoAnnotationsScanner fails to scan some dependencies
> -
>
> Key: MPLUGIN-221
> URL: https://jira.codehaus.org/browse/MPLUGIN-221
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Affects Versions: 3.1
>Reporter: Tony Chemit
>Assignee: Herve Boutemy
>
> there is some dependencies which fails on scan, for example
> {code}
> com.ibm.icu
> icu4j
> {code}
> Will cause this error (I add a log comment to obtain bad class):
> {code}
> [ERROR] Error while analyzing class
> com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class
> java.lang.ArrayIndexOutOfBoundsException: 48188
> at org.objectweb.asm.ClassReader.readClass(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at org.objectweb.asm.ClassReader.accept(Unknown Source)
> at
> org.apache.maven.tools.plugin.annotations.scanner.DefaultMojoAnnotationsScanner.scanFile(DefaultMojoAnnotationsScanner.java:141)
> at
> org.apache.maven.tools.plugin.annotations.scanner.DefaultMojoAnnotationsScanner.scan(DefaultMojoAnnotationsScanner.java:85)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanAnnotations(JavaAnnotationsMojoDescriptorExtractor.java:125)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:104)
> at
> org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108)
> at
> org.apache.maven.plugin.plugin.AbstractGeneratorMojo.execute(AbstractGeneratorMojo.java:233)
> at
> org.apache.maven.plugin.plugin.DescriptorGeneratorMojo.execute(DescriptorGeneratorMojo.java:82)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-225) Make MojoExecution available as Component
[
https://jira.codehaus.org/browse/MPLUGIN-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MPLUGIN-225.
-
Resolution: Cannot Reproduce
Assignee: Herve Boutemy
it's already done in MPLUGIN-204, with ITs (java-basic and
java-basic-annotations) which check MojoExecution recognition
or I'm missing something :)
> Make MojoExecution available as Component
> -
>
> Key: MPLUGIN-225
> URL: https://jira.codehaus.org/browse/MPLUGIN-225
> Project: Maven 2.x Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Affects Versions: 3.1
>Reporter: Robert Scholte
>Assignee: Herve Boutemy
>Priority: Minor
>
> Just like {{MavenProject}} it should be possible to define the
> {{MojoExecution}} as:
> {code}
> @Component
> private MojoExecution mojoExecution ;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-227) HelpMojo javadoc generated in "unnamed package"
[ https://jira.codehaus.org/browse/MPLUGIN-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MPLUGIN-227. - Resolution: Fixed Fix Version/s: 3.1.1 Assignee: Herve Boutemy fixed in [r1405260|http://svn.apache.org/viewvc?rev=1405260&view=rev] > HelpMojo javadoc generated in "unnamed package" > --- > > Key: MPLUGIN-227 > URL: https://jira.codehaus.org/browse/MPLUGIN-227 > Project: Maven 2.x Plugin Tools > Issue Type: Bug >Affects Versions: 3.0, 3.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: 3.1.1 > > > see > http://maven.apache.org/plugins/maven-javadoc-plugin-2.9/apidocs/package-summary.html > or > http://maven.apache.org/plugins/maven-ear-plugin/apidocs/package-summary.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-636) Directory permissions still not correct for dirs created by dependencySet
[
https://jira.codehaus.org/browse/MASSEMBLY-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312809#comment-312809
]
Jason Dillon commented on MASSEMBLY-636:
BTW, this appears to only affect the .zip format, the .tgz format appears to
have the proper permissions.
> Directory permissions still not correct for dirs created by dependencySet
> -
>
> Key: MASSEMBLY-636
> URL: https://jira.codehaus.org/browse/MASSEMBLY-636
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.3
>Reporter: Jason Dillon
>Priority: Critical
>
> While 2.3 did fix some of the permission problems, it still seems to have
> issues creating proper permissions in zip files for directories created by
> dependencySet, even with directoryMode configured.
> I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures
> version 2.3 of the m-assembly-p:
> https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
> {noformat}
> mvn clean install -Dtest=skip
> unzip -d target
> nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
> find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
> {noformat}
> Shows that the lib and nexus directories are 777:
> {noformat}
> 1574536150 drwxrwxrwx 23 jasonstaff 782
> Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
> 1574528520 drwxrwxrwx 12 jasonstaff 408
> Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
> {noformat}
> Both of these directories are created by a dependencySet with directoryMode
> set to 0755.
> The last version of the m-assembly-p which actually functions correct for
> perms/assembly configuration is 2.2-beta-3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-636) Directory permissions still not correct for dirs created by dependencySet
[
https://jira.codehaus.org/browse/MASSEMBLY-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated MASSEMBLY-636:
---
Description:
While 2.3 did fix some of the permission problems, it still seems to have
issues creating proper permissions in zip files for directories created by
dependencySet, even with directoryMode configured.
I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures
version 2.3 of the m-assembly-p:
https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
{noformat}
mvn clean install -Dtest=skip
unzip -d target
nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
{noformat}
Shows that the lib and nexus directories are 777:
{noformat}
1574536150 drwxrwxrwx 23 jasonstaff 782
Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
1574528520 drwxrwxrwx 12 jasonstaff 408
Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
{noformat}
Both of these directories are created by a dependencySet with directoryMode set
to 0755.
The last version of the m-assembly-p which actually functions correct for
perms/assembly configuration is 2.2-beta-3.
was:
While 2.3 did fix some of the permission problems, it still seems to have
issues creating proper permissions in zip files for directories created by
dependencySet, even with directoryMode configured.
I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures
version 2.3 of the m-assembly-p:
https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
{noformat}
mvn clean install -Dtest=skip
unzip -d target
nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
{noformat}
Shows that the lib and nexus directories are 777:
{noformat}
1574536150 drwxrwxrwx 23 jasonstaff 782
Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
1574528520 drwxrwxrwx 12 jasonstaff 408
Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
{noformat}
Both of these directories are created by dependencySet.
The last version of the m-assembly-p which actually functions correct for
perms/assembly configuration is 2.2-beta-3.
> Directory permissions still not correct for dirs created by dependencySet
> -
>
> Key: MASSEMBLY-636
> URL: https://jira.codehaus.org/browse/MASSEMBLY-636
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.3
>Reporter: Jason Dillon
>Priority: Critical
>
> While 2.3 did fix some of the permission problems, it still seems to have
> issues creating proper permissions in zip files for directories created by
> dependencySet, even with directoryMode configured.
> I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures
> version 2.3 of the m-assembly-p:
> https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
> {noformat}
> mvn clean install -Dtest=skip
> unzip -d target
> nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
> find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
> {noformat}
> Shows that the lib and nexus directories are 777:
> {noformat}
> 1574536150 drwxrwxrwx 23 jasonstaff 782
> Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
> 1574528520 drwxrwxrwx 12 jasonstaff 408
> Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
> {noformat}
> Both of these directories are created by a dependencySet with directoryMode
> set to 0755.
> The last version of the m-assembly-p which actually functions correct for
> perms/assembly configuration is 2.2-beta-3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-636) Directory permissions still not correct for dirs created by dependencySet
Jason Dillon created MASSEMBLY-636:
--
Summary: Directory permissions still not correct for dirs created
by dependencySet
Key: MASSEMBLY-636
URL: https://jira.codehaus.org/browse/MASSEMBLY-636
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.3
Reporter: Jason Dillon
Priority: Critical
While 2.3 did fix some of the permission problems, it still seems to have
issues creating proper permissions in zip files for directories created by
dependencySet, even with directoryMode configured.
I've setup a branch of nexus 'm-assembly-p-2.3-still-broke' which configures
version 2.3 of the m-assembly-p:
https://github.com/sonatype/nexus/tree/m-assembly-p-2.3-still-broke
{noformat}
mvn clean install -Dtest=skip
unzip -d target
nexus/nexus-oss-webapp/target/nexus-oss-webapp-2.3-SNAPSHOT-bundle.zip
find target/nexus-oss-webapp-2.3-SNAPSHOT -ls | grep rwxrwx
{noformat}
Shows that the lib and nexus directories are 777:
{noformat}
1574536150 drwxrwxrwx 23 jasonstaff 782
Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/lib
1574528520 drwxrwxrwx 12 jasonstaff 408
Nov 2 16:42 target/nexus-oss-webapp-2.3-SNAPSHOT/nexus
{noformat}
Both of these directories are created by dependencySet.
The last version of the m-assembly-p which actually functions correct for
perms/assembly configuration is 2.2-beta-3.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-504) Transitive dependencies missing when two deps rely on them, but one of the deps is excluded
[
https://jira.codehaus.org/browse/MASSEMBLY-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-504:
--
Component/s: dependencySet
> Transitive dependencies missing when two deps rely on them, but one of the
> deps is excluded
> ---
>
> Key: MASSEMBLY-504
> URL: https://jira.codehaus.org/browse/MASSEMBLY-504
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2-beta-5
>Reporter: Guillaume Eyroulet
> Attachments: maven-assembly-example.zip
>
>
> *NOTE:* This will only happen in very specific cases! See comments and linked
> issue.
> In a reactor, there are 4 modules A, B, C and D.
> * A and B depends on C
> * D depends
> ** on B
> ** on A due to a profile.
> When making an assembly from D
> * including A
> * excluding B
> * using transitive dependencies
> {noformat}
>
> dir
>
> false
>
>
> true
> true
>
> example:a
>
>
> example:b
>
>
>
>
> {noformat}
> C isn't in the result directory.
> Remark: C is in the result directory if D depends on A normally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-497) Inclusion of DEPENDENCIES file in the 'bin' descriptor
[
https://jira.codehaus.org/browse/MASSEMBLY-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-497:
--
Component/s: predefined descriptors
Description:
The bin assembly descriptor does not include DEPENDENCIES files. In Apache
Felix, we're using this file to list our dependencies. Despite this file it's
not mandatory, it's always nice to inform users about projects dependencies.
We recently realized that -bin artifacts generated during releases, do not
include DEPENDENCIES files.
Is it possible to include such file by default by just modifying the includes
files in the 'bin' assembly descriptor:
{code:xml}
${project.basedir}/README*
${project.basedir}/LICENSE*
${project.basedir}/NOTICE*
${project.basedir}/DEPENDENCIES*
{code}
Thanks.
was:
The bin assembly descriptor does not include DEPENDENCIES files. In Apache
Felix, we're using this file to list our dependencies. Despite this file it's
not mandatory, it's always nice to inform users about projects dependencies.
We recently realized that -bin artifacts generated during releases, do not
include DEPENDENCIES files.
Is it possible to include such file by default by just modifying the includes
files in the 'bin' assembly descriptor:
${project.basedir}/README*
${project.basedir}/LICENSE*
${project.basedir}/NOTICE*
${project.basedir}/DEPENDENCIES*
Thanks.
> Inclusion of DEPENDENCIES file in the 'bin' descriptor
> --
>
> Key: MASSEMBLY-497
> URL: https://jira.codehaus.org/browse/MASSEMBLY-497
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Components: predefined descriptors
>Affects Versions: 2.2-beta-5
>Reporter: clement escoffier
>
> The bin assembly descriptor does not include DEPENDENCIES files. In Apache
> Felix, we're using this file to list our dependencies. Despite this file it's
> not mandatory, it's always nice to inform users about projects dependencies.
> We recently realized that -bin artifacts generated during releases, do not
> include DEPENDENCIES files.
> Is it possible to include such file by default by just modifying the includes
> files in the 'bin' assembly descriptor:
> {code:xml}
>
>
> ${project.basedir}/README*
> ${project.basedir}/LICENSE*
> ${project.basedir}/NOTICE*
> ${project.basedir}/DEPENDENCIES*
>
>
> {code}
> Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-495) Assembly changes timestamps when extracting dependency sets
[ https://jira.codehaus.org/browse/MASSEMBLY-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-495: -- Component/s: dependencySet > Assembly changes timestamps when extracting dependency sets > --- > > Key: MASSEMBLY-495 > URL: https://jira.codehaus.org/browse/MASSEMBLY-495 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.2-beta-5 >Reporter: Laurens Blankers > Attachments: MASSEMBLY-495.zip > > > When creating an assembly containing dependency sets the timestamp of the > extraced file is set to the current time in stead of keeping the timestamp > from the jar archive. > Steps to reproduce: > 1. Create any assembly with a dependency set > 2. Run > Expected results: > The files are extracted from the archive(s) while maintaining their > creation/modification timestamps > Actual results: > Both creation and modification timestamps are set to current time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-489) Failure to locate component descriptors in another project
[
https://jira.codehaus.org/browse/MASSEMBLY-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-489:
--
Component/s: component descriptor
> Failure to locate component descriptors in another project
> --
>
> Key: MASSEMBLY-489
> URL: https://jira.codehaus.org/browse/MASSEMBLY-489
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2-beta-5
> Environment: Apache Maven 3.0-beta-1 (r935667; 2010-04-19
> 19:00:39+0200)
> Java version: 1.6.0_20
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre
> Default locale: en_CA, platform encoding: UTF-8
> OS name: "linux" version: "2.6.31-22-generic" arch: "i386" Family: "unix"
>Reporter: Andreas Sewe
> Attachments: aggregator.tar.gz
>
>
> The {{maven-assembly-plugin}} seems to search for component descriptors in
> the current project instead of in the one containing the assembly descriptors
> which do the referring. This behavior is probably a bug and makes it quite
> impossible to use such a modularized assembly descriptor from a different
> project.
> The attached multi-module project exemplifies this; just run "mvn install"
> from the aggregator project and you will get the following stack trace:
> {quote}
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5:single
> (default) on project problematic-module: Error reading assemblies: Failed to
> locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:141)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:77)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:69)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:82)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:54)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.singleThreadedBuild(DefaultLifecycleExecutor.java:218)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:190)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:246)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:95)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:430)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:160)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error reading
> assemblies: Failed to locate component descriptor:
> src/main/resources/assemblies/component.xml
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:356)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:133)
> ... 19 more
> Caused by: org.apache.maven.plugin.assembly.io.AssemblyReadException: Failed
> to locate component descriptor: src/main/resources/assemblies/component.xml
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.mergeComponentsWithMainAssembly(DefaultAssemblyReader.java:452)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssembly(DefaultAssemblyReader.java:366)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyForDescriptorReference(DefaultAssemblyReader.java:257)
> at
> org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:149)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:352)
> ... 21 more
> [ERROR]
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent i
[jira] (MASSEMBLY-478) allow overwriting newer files with older files contained within fileset
[
https://jira.codehaus.org/browse/MASSEMBLY-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-478:
--
Description:
I have a situation where I want to unwind a zip file, and then overlay a few
files in it with my own.
I've been using the maven dependency plugin to unwind this zip file and then
maven assembly plugin to overwrite a few of the extracted files with my own
(generally text based configuration that I keep under source code control).
This seems to work until my files have an earlier modification time than the
files that I want to overwrite, in which case my own files do NOT overwite the
others (I want my files to ALWAYS replace those in the zip file).
Thank in advance. Here are the configuration details
>From my pom.xml:
{code:xml}
org.apache.maven.plugins
maven-assembly-plugin
false
false
${project.build.directory}
solaris
true
src/main/assembly/bin.xml
overwrite
process-sources
directory-single
{code}
>From my src/main/assembly/bin.xml:
{code:xml}
dir
false
${basedir}/src/main/bin
${prefix}/jboss/bin
${basedir}/src/main/conf
${prefix}/jboss/server/wsa/conf
${basedir}/src/main/deploy
${prefix}/jboss/server/wsa/deploy
{code}
was:
I have a situation where I want to unwind a zip file, and then overlay a few
files in it with my own.
I've been using the maven dependency plugin to unwind this zip file and then
maven assembly plugin to overwrite a few of the extracted files with my own
(generally text based configuration that I keep under source code control).
This seems to work until my files have an earlier modification time than the
files that I want to overwrite, in which case my own files do NOT overwite the
others (I want my files to ALWAYS replace those in the zip file).
Thank in advance. Here are the configuration details
>From my pom.xml:
org.apache.maven.plugins
maven-assembly-plugin
false
false
${project.build.directory}
solaris
true
src/main/assembly/bin.xml
overwrite
process-sources
directory-single
>From my src/main/assembly/bin.xml:
dir
false
${basedir}/src/main/bin
${prefix}/jboss/bin
${basedir}/src/main/conf
${prefix}/jboss/server/wsa/conf
${basedir}/src/main/deploy
${prefix}/jboss/server/wsa/deploy
> allow overwriting newer files with older files contained within fileset
> ---
>
> Key: MASSEMBLY-478
> URL: https://jira.codehaus.org/browse/MASSEMBLY-478
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 13:16:01-0600)
> Java version: 1.6.0_17
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.17/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.29-bpo.2-amd64" arch: "amd64" Family: "unix"
>Reporter: deckrider
>
> I have a situation where I want to unwind a zip file, and then overlay a few
> files in it with my own.
> I've been using the maven dependency plugin to unwind this zip file and then
> maven assembly plugin to overwrite a few of the extracted files with my own
> (generally text based configuration that I keep under source code control).
> This seems to work until my files have an earlier modification time than the
> files that I want to overwrite, in which case my own files do NOT overwite
> the others (I want my files to ALWAYS replace those in the zip file).
> Thank in advance. Here are the configuration details
> From my pom.xml:
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
> false
> false
> ${project.build.directory}
> solaris
> true
>
> src/main/assembly/bin.xml
>
>
>
>
> overwrite
> process-sources
>
> directory-single
>
>
>
>
> {code}
> From my src/main/assembly/bin.xml:
> {code:xml}
>
>
> dir
>
> false
>
>
> ${basedir}/src/main/bin
> ${prefix}/jboss/bin
>
>
> ${basedir}/src/main/conf
> ${prefix}/jboss/server/ws
[jira] (MASSEMBLY-477) Add option "failOnMissingClassifierArtifact" for multimodule projects
[
https://jira.codehaus.org/browse/MASSEMBLY-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-477:
--
Component/s: moduleSet
Description:
I have a large multimodule projects that need to create compact distribution
files at the root of the modules hierarchy. I want to use the assembly plugin
with predefined descriptors for merging submodules classes, sources, tests,
resources, configuration, etc. The following descriptor shows the sample of my
definition. But there is an issue with usage of , when
used and some submodule does not support this classifier, than the
{code:java}
InvalidAssemblerConfigurationException( "Cannot find attachment with
classifier: " + classifier + " in module project: " + project.getId() + ".
Please exclude this module from the module-set." )
{code}
is thrown. It will be great, that the new
could be supported - it is inspired by the sameoption in
maven-dependency-plugin:
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html#failOnMissingClassifierArtifact
{code:xml}
*-api
sources
false
/
true
false
{code}
At this time I patched the
org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase.java to
ignore exception and provide only logger.info message.
was:
I have a large multimodule projects that need to create compact distribution
files at the root of the modules hierarchy. I want to use the assembly plugin
with predefined descriptors for merging submodules classes, sources, tests,
resources, configuration, etc. The following descriptor shows the sample of my
definition. But there is an issue with usage of , when
used and some submodule does not support this classifier, than the
InvalidAssemblerConfigurationException( "Cannot find attachment with
classifier: " + classifier + " in module project: " + project.getId() + ".
Please exclude this module from the module-set." )
is thrown. It will be great, that the new
could be supported - it is inspired by the sameoption in
maven-dependency-plugin:
http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html#failOnMissingClassifierArtifact
*-api
sources
false
/
true
false
At this time I patched the
org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase.java to
ignore exception and provide only logger.info message.
Patch Submitted: Yes
> Add option "failOnMissingClassifierArtifact" for multimodule projects
> --
>
> Key: MASSEMBLY-477
> URL: https://jira.codehaus.org/browse/MASSEMBLY-477
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Components: moduleSet
>Affects Versions: 2.2-beta-5
> Environment: Maven 2.2.1, Sun JDK 1.6.0_u18, Win7/Linux
>Reporter: Kek
> Attachments: ModuleSetAssemblyPhase.java
>
>
> I have a large multimodule projects that need to create compact distribution
> files at the root of the modules hierarchy. I want to use the assembly plugin
> with predefined descriptors for merging submodules classes, sources, tests,
> resources, configuration, etc. The following descriptor shows the sample of
> my definition. But there is an issue with usage of ,
> when used and some submodule does not support this classifier, than the
> {code:java}
> InvalidAssemblerConfigurationException( "Cannot find attachment with
> classifier: " + classifier + " in module project: " + project.getId() + ".
> Please exclude this module from the module-set." )
> {code}
> is thrown. It will be great, that the new
> could be supported - it is inspired by the sameoption in
> maven-dependency-plugin:
> http://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html#failOnMissingClassifierArtifact
> {code:xml}
>
>
>
> *-api
>
>
> sources
>
> false
> /
> true
> false
>
>
>
> {code}
> At this time I patched the
> org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase.java to
> ignore exception and provide only logger.info message.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-476) Use classpath resources as fileSets
[
https://jira.codehaus.org/browse/MASSEMBLY-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MASSEMBLY-476.
-
Resolution: Not A Bug
> Use classpath resources as fileSets
> ---
>
> Key: MASSEMBLY-476
> URL: https://jira.codehaus.org/browse/MASSEMBLY-476
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-4
> Environment: Operating System : Ubuntu 8.04
>Reporter: Leandro Aispuru
>
> We want to do assemblies of our projects using shared assembly descriptors
> (http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html).
> Also, we want to include some directories and files in the assemblies, but
> we want to store that particular directories and/or files inside the shared
> descriptor artifact JAR.
> For example in our shared descriptor jar is included a file
> src/main/assembly/files/startup/startup.sh and we want to have the assembly
> generated containing that file.
> Now when we execute the assembly plugin on a project using the shared
> descriptor, files contained inside sharedDescriptor.jar aren't copied into
> the assembly.
> The shared assembly descriptor has a fileSet defined like this:
> {code:xml}
>
> files
>
> true
>
> **/*.sh
> **/*.csh
>
> 0755
>
> {code}
> And the *.sh and *.csh files are stored inside sharedDescriptors.jar.
> We have a project "A" and "B" that use the shared descriptor. We want to
> include sh and csh files on the assembly of A and B but the only way to do
> this is that the sh and csh files are duplicated in the file structure of
> both projects in /files directory instead of instead of have them only one
> place ( at /files directory in sharedDescriptors project)
> Is it possible to provide these files (*.csh, *.sh) within the shared
> descriptor jar?
> If not, we propose extending the assembly plugin so it can have defined a
> FileSet in the form:
> {code:xml}
>
> classpath:/assembly/files
> ...
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-476) Use classpath resources as fileSets
[
https://jira.codehaus.org/browse/MASSEMBLY-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312803#comment-312803
]
Dennis Lundberg commented on MASSEMBLY-476:
---
For this to work you need to do two things:
1. Add sharedDescriptors.jar as a dependency for maven-assembly-plugin. This is
so the Assembly plugin can use the shared assembly descriptors.
2. Add sharedDescriptors.jar as a dependency to projects A and B. This is so
that the .sh files in the jar are available as resources that can then be
assembled by the Assembly plugin.
> Use classpath resources as fileSets
> ---
>
> Key: MASSEMBLY-476
> URL: https://jira.codehaus.org/browse/MASSEMBLY-476
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-4
> Environment: Operating System : Ubuntu 8.04
>Reporter: Leandro Aispuru
>
> We want to do assemblies of our projects using shared assembly descriptors
> (http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html).
> Also, we want to include some directories and files in the assemblies, but
> we want to store that particular directories and/or files inside the shared
> descriptor artifact JAR.
> For example in our shared descriptor jar is included a file
> src/main/assembly/files/startup/startup.sh and we want to have the assembly
> generated containing that file.
> Now when we execute the assembly plugin on a project using the shared
> descriptor, files contained inside sharedDescriptor.jar aren't copied into
> the assembly.
> The shared assembly descriptor has a fileSet defined like this:
> {code:xml}
>
> files
>
> true
>
> **/*.sh
> **/*.csh
>
> 0755
>
> {code}
> And the *.sh and *.csh files are stored inside sharedDescriptors.jar.
> We have a project "A" and "B" that use the shared descriptor. We want to
> include sh and csh files on the assembly of A and B but the only way to do
> this is that the sh and csh files are duplicated in the file structure of
> both projects in /files directory instead of instead of have them only one
> place ( at /files directory in sharedDescriptors project)
> Is it possible to provide these files (*.csh, *.sh) within the shared
> descriptor jar?
> If not, we propose extending the assembly plugin so it can have defined a
> FileSet in the form:
> {code:xml}
>
> classpath:/assembly/files
> ...
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-476) Use classpath resources as fileSets
[
https://jira.codehaus.org/browse/MASSEMBLY-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-476:
--
Description:
We want to do assemblies of our projects using shared assembly descriptors
(http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html).
Also, we want to include some directories and files in the assemblies, but we
want to store that particular directories and/or files inside the shared
descriptor artifact JAR.
For example in our shared descriptor jar is included a file
src/main/assembly/files/startup/startup.sh and we want to have the assembly
generated containing that file.
Now when we execute the assembly plugin on a project using the shared
descriptor, files contained inside sharedDescriptor.jar aren't copied into the
assembly.
The shared assembly descriptor has a fileSet defined like this:
{code:xml}
files
true
**/*.sh
**/*.csh
0755
{code}
And the *.sh and *.csh files are stored inside sharedDescriptors.jar.
We have a project "A" and "B" that use the shared descriptor. We want to
include sh and csh files on the assembly of A and B but the only way to do this
is that the sh and csh files are duplicated in the file structure of both
projects in /files directory instead of instead of have them only one place (
at /files directory in sharedDescriptors project)
Is it possible to provide these files (*.csh, *.sh) within the shared
descriptor jar?
If not, we propose extending the assembly plugin so it can have defined a
FileSet in the form:
{code:xml}
classpath:/assembly/files
...
{code}
was:
We want to do assemblies of our projects using shared assembly descriptors
(http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html).
Also, we want to include some directories and files in the assemblies, but we
want to store that particular directories and/or files inside the shared
descriptor artifact JAR.
For example in our shared descriptor jar is included a file
src/main/assembly/files/startup/startup.sh and we want to have the assembly
generated containing that file.
Now when we execute the assembly plugin on a project using the shared
descriptor, files contained inside sharedDescriptor.jar aren't copied into the
assembly.
The shared assembly descriptor has a fileSet defined like this:
files
true
**/*.sh
**/*.csh
0755
And the *.sh and *.csh files are stored inside sharedDescriptors.jar.
We have a project "A" and "B" that use the shared descriptor. We want to
include sh and csh files on the assembly of A and B but the only way to do this
is that the sh and csh files are duplicated in the file structure of both
projects in /files directory instead of instead of have them only one place (
at /files directory in sharedDescriptors project)
Is it possible to provide these files (*.csh, *.sh) within the shared
descriptor jar?
If not, we propose extending the assembly plugin so it can have defined a
FileSet in the form:
classpath:/assembly/files
...
> Use classpath resources as fileSets
> ---
>
> Key: MASSEMBLY-476
> URL: https://jira.codehaus.org/browse/MASSEMBLY-476
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-4
> Environment: Operating System : Ubuntu 8.04
>Reporter: Leandro Aispuru
>
> We want to do assemblies of our projects using shared assembly descriptors
> (http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html).
> Also, we want to include some directories and files in the assemblies, but
> we want to store that particular directories and/or files inside the shared
> descriptor artifact JAR.
> For example in our shared descriptor jar is included a file
> src/main/assembly/files/startup/startup.sh and we want to have the assembly
> generated containing that file.
> Now when we execute the assembly plugin on a project using the shared
> descriptor, files contained inside sharedDescriptor.jar aren't copied into
> the assembly.
> The shared assembly descriptor has a fileSet defined like this:
> {code:xml}
>
> files
>
> true
>
> **/*.sh
> **/*.csh
>
> 0755
>
> {code}
> And the *.sh and *.csh files are stored inside sharedDescriptors.ja
[jira] (MASSEMBLY-474) Assembly is duplicating dependecies in the output
[
https://jira.codehaus.org/browse/MASSEMBLY-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-474:
--
Component/s: moduleSet
Description:
When I have an assembly descriptor that contains 2 modules that both have the
same dependencies, those dependencies are duplicated instead of
skipped/overwritten in the target zip file. This is very similiar to
MASSEMBLY-285, but is a problem on the dependencies and not the modules
themselves. This is only a problem when
{code:xml}
aaa:
aaa:
true
false
lib
{code}
was:
When I have an assembly descriptor that contains 2 modules that both have the
same dependencies, those dependencies are duplicated instead of
skipped/overwritten in the target zip file. This is very similiar to
MASSEMBLY-285, but is a problem on the dependencies and not the modules
themselves. This is only a problem when
aaa:
aaa:
true
false
lib
> Assembly is duplicating dependecies in the output
> --
>
> Key: MASSEMBLY-474
> URL: https://jira.codehaus.org/browse/MASSEMBLY-474
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: moduleSet
>Affects Versions: 2.2
>Reporter: Andrew Rampulla
> Attachments: assembly-test-mulit-project.zip
>
>
> When I have an assembly descriptor that contains 2 modules that both have the
> same dependencies, those dependencies are duplicated instead of
> skipped/overwritten in the target zip file. This is very similiar to
> MASSEMBLY-285, but is a problem on the dependencies and not the modules
> themselves. This is only a problem when
> {code:xml}
>
>
> aaa:
> aaa:
>
>
> true
> false
> lib
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-466) Multi Module Projects, assembly goal causes unpredictable build order
[ https://jira.codehaus.org/browse/MASSEMBLY-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-466: -- Summary: Multi Module Projects, assembly goal causes unpredictable build order (was: MultiModule Projects, Assembly target causes unpredictable build order) > Multi Module Projects, assembly goal causes unpredictable build order > - > > Key: MASSEMBLY-466 > URL: https://jira.codehaus.org/browse/MASSEMBLY-466 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Environment: Windows >Reporter: Bill Smith > Attachments: log.txt, mvn.zip > > > I have a multi module project. One of the projects uses an ant task to > generate source code. When runnning the command > mvn package assembly:assembly I am seeing the ant task run more then once. > If I simply run mvn package all builds fine, but I obviously don't have my > assembly. > Attached is a sample maven project. Inside there is also a log of out the > output from my build. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-460) default file mode of 7777 leads to trouble
[
https://jira.codehaus.org/browse/MASSEMBLY-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-460:
--
Component/s: permissions
Description:
We are getting build failures as follows. 1: why and not 0777? Why a
WARNING if the build is going to quit? Why quit?
{noformat}
[WARNING] Standard output:
[WARNING] ---
[WARNING] chmod: changing permissions of
`/basis/users/skearns/svn/trunk_mirror/greenhouse/jester/distribution/target/jester-all.dir/jester/release_package'
(requested: , actual: 6777): Operation not permitted
[WARNING] ---
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to create assembly: Error creating assembly archive all: chmod
exit code was: 1
{noformat}
was:
We are getting build failures as follows. 1: why and not 0777? Why a
WARNING if the build is going to quit? Why quit?
[WARNING] Standard output:
[WARNING] ---
[WARNING] chmod: changing permissions of `/basis/users/skearns/svn/trunk_mirror/
greenhouse/jester/distribution/target/jester-all.dir/jester/release_package' (re
quested: , actual: 6777): Operation not permitted
[WARNING] ---
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to create assembly: Error creating assembly archive all: chmod exi
t code was: 1
> default file mode of leads to trouble
> ---
>
> Key: MASSEMBLY-460
> URL: https://jira.codehaus.org/browse/MASSEMBLY-460
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.2-beta-4
>Reporter: Benson Margulies
>
> We are getting build failures as follows. 1: why and not 0777? Why a
> WARNING if the build is going to quit? Why quit?
> {noformat}
> [WARNING] Standard output:
> [WARNING] ---
> [WARNING] chmod: changing permissions of
> `/basis/users/skearns/svn/trunk_mirror/greenhouse/jester/distribution/target/jester-all.dir/jester/release_package'
> (requested: , actual: 6777): Operation not permitted
> [WARNING] ---
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to create assembly: Error creating assembly archive all: chmod
> exit code was: 1
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-453) Maven assembly plugin throws build error when a pom dependency has a version that contains the brackets for tight tolerance
[
https://jira.codehaus.org/browse/MASSEMBLY-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-453:
--
Summary: Maven assembly plugin throws build error when a pom dependency has
a version that contains the brackets for tight tolerance (was: Maven assembly
plugin doesn't throws error when dependency version contains the brackets for
tight tolerance)
> Maven assembly plugin throws build error when a pom dependency has a version
> that contains the brackets for tight tolerance
> ---
>
> Key: MASSEMBLY-453
> URL: https://jira.codehaus.org/browse/MASSEMBLY-453
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
> Environment: Any
>Reporter: BJ Allmon
>Priority: Minor
>
> Current behavior:
> A module that executes an assembly will fail with a build error indicating
> that the dependency artifact version is null for any dependency that includes
> brackets.
> The brackets are used indirectly through a property. For example:
> ${myApplication.currentVersion} =
> [1.0-SNAPSHOT]
> The work around(s):
> 1. Manage static dependency versions in the POM files that include the
> assembly
> 2. Maintain two different properties. One for build dependencies with
> brackets and one for assemblies without brackets.
> FIX:
> The assembly plugin should simply ignore possible dependency ranges and other
> things that are used. Larger projects use properties for version when there
> are several modules to manage.
> Plugin details: http://maven.apache.org/plugins/maven-assembly-plugin/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-450) manifestEntries ignored when manfestFile is specified
[
https://jira.codehaus.org/browse/MASSEMBLY-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-450:
--
Component/s: manifest
Description:
The maven jar plugin supports the behavior of manifestEntries overriding the
manifestFile as indicated here:
http://maven.apache.org/guides/mini/guide-manifest.html
However, within the maven assembly plugin, if manifestFile is specified,
manifestEntries is ignored.
Reproduction
{noformat}
> unzip example.zip
> cd example
> mvn package
> cd target
> unzip example-4.2-plugin.jar
> cat META-INF/MANFEST
{noformat}
Results:
{noformat}
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: example
Bundle-SymbolicName: example; singleton:=true
Bundle-Version: 1.0
{noformat}
Expected:
{noformat}
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: example
Bundle-SymbolicName: example; singleton:=true
Bundle-Version: 4.2
{noformat}
The problem appears to be in the class ManifestConfigurationFinalizer:
{code:java}
if ( manifestFile != null )
{
...
manifest = new Manifest( manifestFileReader );
...
}
else
{
manifest = mavenArchiver.getManifest( project,
archiveConfiguration.getManifest() );
}
{code}
I believe the fix is to change to the following (this already handles merging
the manifest file with the configured manifestEntries)
{code:java}
manifest = mavenArchiver.getManifest( project, archiveConfiguration );
{code}
was:
The maven jar plugin supports the behavior of manifestEntries overriding the
manifestFile as indicated here:
http://maven.apache.org/guides/mini/guide-manifest.html
However, within the maven assembly plugin, if manifestFile is specified,
manifestEntries is ignored.
Reproduction
> unzip example.zip
> cd example
> mvn package
> cd target
> unzip example-4.2-plugin.jar
> cat META-INF/MANFEST
Results:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: example
Bundle-SymbolicName: example; singleton:=true
Bundle-Version: 1.0
Expected:
Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 14.0-b16 (Sun Microsystems Inc.)
Bundle-ManifestVersion: 2
Bundle-Name: example
Bundle-SymbolicName: example; singleton:=true
Bundle-Version: 4.2
The problem appears to be in the class ManifestConfigurationFinalizer:
if ( manifestFile != null )
{
...
manifest = new Manifest( manifestFileReader );
...
}
else
{
manifest = mavenArchiver.getManifest( project,
archiveConfiguration.getManifest() );
}
I believe the fix is to change to the following (this already handles merging
the manifest file with the configured manifestEntries)
manifest = mavenArchiver.getManifest( project, archiveConfiguration );
> manifestEntries ignored when manfestFile is specified
> -
>
> Key: MASSEMBLY-450
> URL: https://jira.codehaus.org/browse/MASSEMBLY-450
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: manifest
>Affects Versions: 2.2-beta-4
>Reporter: Robert Cauble
> Attachments: example.zip
>
>
> The maven jar plugin supports the behavior of manifestEntries overriding the
> manifestFile as indicated here:
> http://maven.apache.org/guides/mini/guide-manifest.html
> However, within the maven assembly plugin, if manifestFile is specified,
> manifestEntries is ignored.
> Reproduction
>
> {noformat}
> > unzip example.zip
> > cd example
> > mvn package
> > cd target
> > unzip example-4.2-plugin.jar
> > cat META-INF/MANFEST
> {noformat}
> Results:
> {noformat}
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: 14.0-b16 (Sun Microsystems Inc.)
> Bundle-ManifestVersion: 2
> Bundle-Name: example
> Bundle-SymbolicName: example; singleton:=true
> Bundle-Version: 1.0
> {noformat}
> Expected:
> {noformat}
> Manifest-Version: 1.0
> Archiver-Version: Plexus Archiver
> Created-By: 14.0-b16 (Sun Microsystems Inc.)
> Bundle-ManifestVersion: 2
> Bundle-Name: example
> Bundle-SymbolicName: example; singleton:=true
> Bundle-Version: 4.2
> {noformat}
> The problem appears to be in the class ManifestConfigurationFinalizer:
> {code:java}
> if ( manifestFile != null )
> {
>...
>manifest = new Manifest( manifestFileReader );
>...
> }
> else
> {
>manifest = mavenArchiver.getManifest( project,
> archiveConfiguration.getManifest() );
> }
> {code}
> I believe the fix is to change to the following (this already handles merging
> the manifest file with the configured manifestEntries)
> {code:java}
> manifest = mavenArchiver.getManifest( project, archiveConfiguration
[jira] (MASSEMBLY-445) Support parametrization of component descriptors
[
https://jira.codehaus.org/browse/MASSEMBLY-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-445:
--
Component/s: component descriptor
Description:
Please support parametrization of component descriptors. One should be able to
specify parameter placeholders in component descriptors, and when referencing
component descriptor from an assembly descriptor provide actual parameter
value(s) which would then be applied to the parameter placeholders. One should
be able to set global parameters (for all component descriptors), and component
descriptor specific parameters, with component descriptor specific parameters
overriding global ones if their names overlap.
This would be useful if e.g. one uses assembly descriptors to specify
assemblies for different deployment environments, and if these assemblies
differ (see example [1]) only in which environment specific configuration file
should be included in the assembly where this distinction is based on
configuration file name suffix - this suffix could be passed to shared
component descriptor as parameter, like in example [2].
[1] assembly descriptor example without parameters
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1
http://maven.apache.org/xsd/assembly-1.1.1.xsd";>
prod
war
false
${project.build.directory}/${project.build.finalName}
/
**/jdbc.properties
**/jdbc-*.properties
**/log4j.xml
**/log4j-*.xml
${project.build.outputDirectory}/com/foo/bar/cfg/jdbc-${environment}.properties
WEB-INF/classes/com/foo/bar/cfg/
jdbc.properties
${project.build.outputDirectory}/com/foo/bar/cfg/log4j-${environment}.xml
WEB-INF/classes/
log4j.xml
{code}
[2] parametrized component descriptor and usage example
src/main/assembly/component.xml
{code:xml}
${project.build.directory}/${project.build.finalName}
/
**/jdbc.properties
**/jdbc-*.properties
**/log4j.xml
**/log4j-*.xml
${project.build.outputDirectory}/com/foo/bar/cfg/jdbc-${environment}.properties
WEB-INF/classes/com/foo/bar/cfg/
jdbc.properties
${project.build.outputDirectory}/com/foo/bar/cfg/log4j-${environment}.xml
WEB-INF/classes/
log4j.xml
{code}
src/main/assembly/packaging-prod.xml
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1
http://maven.apache.org/xsd/assembly-1.1.1.xsd";>
prod
war
false
src/main/assembly/component.xml
environment
prod
{code}
src/main/assembly/packaging-stag.xml
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.1
http://maven.apache.org/xsd/assembly-1.1.1.xsd";>
stag
war
false
[jira] (MASSEMBLY-449) Permissions on directories in a zipped archive incorrect
[
https://jira.codehaus.org/browse/MASSEMBLY-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-449:
--
Component/s: permissions
> Permissions on directories in a zipped archive incorrect
>
>
> Key: MASSEMBLY-449
> URL: https://jira.codehaus.org/browse/MASSEMBLY-449
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: permissions
>Affects Versions: 2.2-beta-4
>Reporter: James Kavanagh
>
> Using the following assembly plugin:
> {code:xml}
>
> target-packaged
>
> zip
>
> false
>
>
>
> *:core-env
>
>
> env
> false
> true
>
>
>
>
> *:data-bridge
>
>
> target
> false
> true
>
>
>
>
> *:web
>
>
> web
> false
> true
>
>
>
>
> {code}
> When unzipping the result on a Linux host all the directory permissions have
> been set to 777.
> If I revert the plugin version to 2.2-beta-3 the issue goes away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-422) Generated directories have wrong file attributes
[ https://jira.codehaus.org/browse/MASSEMBLY-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-422: -- Component/s: permissions > Generated directories have wrong file attributes > > > Key: MASSEMBLY-422 > URL: https://jira.codehaus.org/browse/MASSEMBLY-422 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: permissions >Affects Versions: 2.2-beta-4 >Reporter: Sergiu Dumitriu >Priority: Minor > > When the assembly creates directories not already found in the resources (for > example when using true or > some/new/folder), the directory has the > wrong file attributes (17 octal, ?rwsrwsrwt). This causes the archive to > be somewhat broken, since the directory doesn't appear to be a directory > according to the file attributes. > This causes problems with the Midnight Commander virtual file system, for > example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-411) Error on copy dependencies using Assembler Plugin (m2e Eclipse Plugin Workspace Resolution)
[
https://jira.codehaus.org/browse/MASSEMBLY-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-411:
--
Component/s: dependencySet
Description:
If you have two projects, with one (B) depending on another (A), and in your
assembly.xml file you define the following dependencySet:
{code:xml}
lib/
runtime
false
true
{code}
And the workspace resolution been activated, during the package phase an error
will occur showing that is not possible to copy the "target/classes" file from
project A. Because "target/classes" isn't a file. This error only occurs if the
workspace resolution is enabled.
was:
If you have two projects, with one (B) depending on another (A), and in your
assembly.xml file you define the following dependencySet:
lib/
runtime
false
true
And the workspace resolution been activated, during the package phase an error
will occur showing that is not possible to copy the "target/classes" file from
project A. Because "target/classes" isn't a file. This error only occurs if the
workspace resolution is enabled.
> Error on copy dependencies using Assembler Plugin (m2e Eclipse Plugin
> Workspace Resolution)
> ---
>
> Key: MASSEMBLY-411
> URL: https://jira.codehaus.org/browse/MASSEMBLY-411
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2-beta-3
> Environment: Maven 2.1.0, Eclipse 3.4 Sr2, m2Eclipse 0.9.8
>Reporter: Felipe Desiderati
>
> If you have two projects, with one (B) depending on another (A), and in your
> assembly.xml file you define the following dependencySet:
> {code:xml}
>
> lib/
> runtime
> false
> true
>
> {code}
> And the workspace resolution been activated, during the package phase an
> error will occur showing that is not possible to copy the "target/classes"
> file from project A. Because "target/classes" isn't a file. This error only
> occurs if the workspace resolution is enabled.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-405) "project" predefined dependencyRef really doesn't work in 2.2-beta-3
[ https://jira.codehaus.org/browse/MASSEMBLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-405. - Resolution: Fixed Fix Version/s: 2.2-beta-4 > "project" predefined dependencyRef really doesn't work in 2.2-beta-3 > > > Key: MASSEMBLY-405 > URL: https://jira.codehaus.org/browse/MASSEMBLY-405 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-3 >Reporter: David Jencks > Fix For: 2.2-beta-4 > > Attachments: massembly-405-sample.jar > > > "project" dependencyRef uses bizarre paths in the zip etc archives, e.g. > portlet-api_1.0_spec-1.0-SNAPSHOT/Users/david/projects/jetspeed/portlet-spec/trunk/portlet-api-1.0/target/classes/javax/portlet/UnavailableException.class > 2.2-beta-2 seems to work OK. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5237) Cannot download maven dependencies through NTLM proxy
[
https://jira.codehaus.org/browse/MNG-5237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MNG-5237:
---
Description:
Using proxy in settings.xml, I was able to download maven dependencies in
3.0.3, but this seems to be broken with 3.0.4:
Proxy definition in settings.xml (hidden ip adress below, but correct proxy ip
on my system):
{code:xml}
optional
true
http
xxx.xx.xx.xx
8080
localhost|127.0.0.1
{code}
Output from 3.0.3:
{noformat}$ mvn -V clean
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files\apache-maven-3.0.3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
(5 KB at 4.9 KB/sec)
. and so on...
Output from 3.0.4:
$ mvn -V clean
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: C:\Program Files\apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building
[INFO]
Downloading:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.390s
[INFO] Finished at: Fri Feb 03 13:14:35 CET 2012
[INFO] Final Memory: 5M/490M
[INFO]
[ERROR] Plugin org.apache.maven.plugins:maven-clean-plugin:2.4.1 or one of its
dependencies could not be resolved: Failed to read artifact descriptor for
org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1: Could not transfer
artifact org.apache.maven.plugins:maven-clean-plugin:pom:2.4.1 from/to central
(http://repo.maven.apache.org/maven2): Access denied to:
http://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom,
ReasonPhrase:Forbidden. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
{noformat}
was:
Using proxy in settings.xml, I was able to download maven dependencies in
3.0.3, but this seems to be broken with 3.0.4:
Proxy definition in settings.xml (hidden ip adress below, but correct proxy ip
on my system):
optional
true
http
xxx.xx.xx.xx
8080
localhost|127.0.0.1
Output from 3.0.3:
$ mvn -V clean
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: C:\Program Files\apache-maven-3.0.3
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
Downloaded:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/2.4.1/maven-clean-plugin-2.4.1.pom
(5 KB at 4.9 KB/sec)
. and so on...
Output from 3.0.4:
$ mvn -V clean
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: C:\Program Files\apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_24\jre
Default locale: no_NO, platform encoding: Cp1252
OS name: "windows xp", version: "5.2", arch: "amd64", family: "windows"
[INFO] Sc
[jira] (SUREFIRE-910) Surefire 2.12.1 fails with "The forked VM terminated without saying properly goodbye"
[
https://jira.codehaus.org/browse/SUREFIRE-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312793#comment-312793
]
Kristian Rosenvold commented on SUREFIRE-910:
-
2.12.4 is the latest released version. Please test with that.
And yes, if your tests or harnesses calls System.exit() you will get this
message no matter what, I will consider improving messagt to indicate this.
> Surefire 2.12.1 fails with "The forked VM terminated without saying properly
> goodbye"
> -
>
> Key: SUREFIRE-910
> URL: https://jira.codehaus.org/browse/SUREFIRE-910
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Ilya Katsov
>
> Build fails with "The forked VM terminated without saying properly goodbye"
> message with no information about the source of the problem:
> {code}
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.125 sec
> Running org.apache.hadoop.fs.viewfs.TestViewFsHdfs
> Tests run: 42, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.149 sec
> Running org.apache.hadoop.fs.TestFcHdfsSymlink
> Tests run: 67, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 20.792 sec
> Results :
> Tests run: 1033, Failures: 0, Errors: 0, Skipped: 1
> [INFO]
>
> [INFO]
>
> [INFO] Skipping Apache Hadoop HDFS Project
> [INFO] This project has been banned from the build due to previous failures.
> [INFO]
>
> [INFO]
>
> [INFO]
>
> [INFO] Skipping Apache Hadoop HDFS
> [INFO] This project has been banned from the build due to previous failures.
> [INFO]
>
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Hadoop HDFS FAILURE
> [1:06:10.415s]
> [INFO] Apache Hadoop HttpFS .. SKIPPED
> [INFO] Apache Hadoop HDFS Project SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1:06:11.188s
> [INFO] Finished at: Wed Sep 05 12:01:46 MSK 2012
> [INFO] Final Memory: 24M/394M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.12.1:test (default-test) on
> project hadoop-hdfs: ExecutionException; nested exception is
> java.util.concurrent.ExecutionException: java.lang.RuntimeException: The
> forked VM terminated without saying properly goodbye. VM crash or System.exit
> called ? -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-surefire-plugin:2.12.1:test
> (default-test) on project hadoop-hdfs: ExecutionException; nested exception
> is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The
> forked VM terminated without saying properly goodbye. VM crash or System.exit
> called ?
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.Delegating
[jira] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient
[ https://jira.codehaus.org/browse/MPLUGIN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MPLUGIN-229: --- Fix Version/s: (was: 2.10) 3.1.1 > don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in > JDK is sufficient > --- > > Key: MPLUGIN-229 > URL: https://jira.codehaus.org/browse/MPLUGIN-229 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.1 >Reporter: Herve Boutemy >Assignee: Kristian Rosenvold > Fix For: 3.1.1 > > > replacing a dependency on plexus-utils with JDK is a Good Thing (TM) > part of MNG-2255, easy to do -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-229) don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient
[ https://jira.codehaus.org/browse/MPLUGIN-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MPLUGIN-229. -- Resolution: Fixed Fix Version/s: 2.10 Fixed in r1405040 > don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in > JDK is sufficient > --- > > Key: MPLUGIN-229 > URL: https://jira.codehaus.org/browse/MPLUGIN-229 > Project: Maven 2.x Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Affects Versions: 3.1 >Reporter: Herve Boutemy >Assignee: Kristian Rosenvold > Fix For: 2.10 > > > replacing a dependency on plexus-utils with JDK is a Good Thing (TM) > part of MNG-2255, easy to do -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-920) -Dmaven.test.failure.ignore=true isn't honored
[ https://jira.codehaus.org/browse/SUREFIRE-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312789#comment-312789 ] Hung Huynh commented on SUREFIRE-920: - More specifics: -Dmaven.test.failure.ignore=true isn't checked when a test fails by timing out. If a test fails normally by exception then things work correctly. > -Dmaven.test.failure.ignore=true isn't honored > -- > > Key: SUREFIRE-920 > URL: https://jira.codehaus.org/browse/SUREFIRE-920 > Project: Maven Surefire > Issue Type: Bug >Reporter: Hung Huynh > > I have a multi module project and running the build in jenkins with > -Dmaven.test.failure.ignore=true > When one of the module has a failed test, the build fails right at that point > instead of ignoring the failure and moving on to run tests in the next module. > I took a look at SurefirePlugin.handleSummary() method it's not checking for > isTestFailureIgnore() value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-259) Add french localization for dependency-info
Guillaume Husta created MPIR-259:
Summary: Add french localization for dependency-info
Key: MPIR-259
URL: https://jira.codehaus.org/browse/MPIR-259
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Improvement
Components: dependency-info
Affects Versions: 2.6
Reporter: Guillaume Husta
Priority: Minor
Please add the french localization for these properties in
*project-info-report_fr.properties* :
{code}
report.dependency-info.name = Informations de d\u00e9pendance
report.dependency-info.title = Informations de d\u00e9pendance
report.dependency-info.description = Ce document fournit des informations sur
la mani\u00e8re d'ajouter cette d\u00e9pendance avec diff\u00e9rents outils de
gestion des d\u00e9pendances.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-258) Missing english localization property for dependency-info (i18n)
Guillaume Husta created MPIR-258:
Summary: Missing english localization property for dependency-info
(i18n)
Key: MPIR-258
URL: https://jira.codehaus.org/browse/MPIR-258
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Improvement
Components: dependency-info
Affects Versions: 2.6
Reporter: Guillaume Husta
Priority: Minor
This property is missing :
{code}
report.dependency-info.description = This document provides information about
how to add this dependency with different dependency management tools.
{code}
and should be provided in the file *project-info-report.properties*.
It is evaluated when the file *target/site/project-info.html* is generated.
Warning, the description I wrote may need to be reviewed !
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-257) English localization properties misplaced (i18n)
Guillaume Husta created MPIR-257:
Summary: English localization properties misplaced (i18n)
Key: MPIR-257
URL: https://jira.codehaus.org/browse/MPIR-257
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Components: dependency-info
Affects Versions: 2.6
Reporter: Guillaume Husta
Priority: Minor
These properties :
{code}
report.dependency-info.name = Dependency Information
report.dependency-info.title = Dependency Information
{code}
should be placed in *project-info-report.properties* rather than in
*project-info-report_en.properties*.
As mentioned in project-info-report_en.properties, "_This bundle is
intentionally empty because English strings are provided by the base bundle via
the parent chain._"
The problem is that when I generate the site with a french locale, it outputs
"_report.dependency-info.name_" or "_report.dependency-info.title_" rather than
"_Dependency Information_" (no french localization yet).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-910) Surefire 2.12.1 fails with "The forked VM terminated without saying properly goodbye"
[ https://jira.codehaus.org/browse/SUREFIRE-910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312782#comment-312782 ] Lesserteur Damien commented on SUREFIRE-910: Hello, I have the same error with surefire 2.12.2 You can see my logs bellow. Tests run: 854, Failures: 10, Errors: 149, Skipped: 90 [JENKINS] Recording test results [JENKINS] Archiving xxx to yyy [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 41:18.826s [INFO] Finished at: Fri Nov 02 13:05:02 CET 2012 [INFO] Final Memory: 21M/247M [INFO] Waiting for Jenkins to finish collecting data mavenExecutionResult exceptions not empty message : Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project eds-test-server: ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? cause : ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? Stack trace : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.12.2:test (default-test) on project eds-test-server: ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:112) at hudson.maven.Maven3Builder.call(Maven3Builder.java:70) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.maven.plugin.MojoExecutionException: ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? at org.apache.maven.plugin.surefire.SurefirePlugin.assertNoException(SurefirePlugin.java:168) at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:157) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:626) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:587) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager
[jira] (MASSEMBLY-404) Different behavior on Linux and Windows
[ https://jira.codehaus.org/browse/MASSEMBLY-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-404. - Resolution: Fixed Fix Version/s: 2.2-beta-3 This has nothing to do with what OS your are running on IIUC. But rather that you have not defined which version of maven-assembly-plugin you want to use. Your two installations probably have different opinions of what version to use. The bug about duplicate entries in the archive was fixed in 2.2-beta-3. > Different behavior on Linux and Windows > --- > > Key: MASSEMBLY-404 > URL: https://jira.codehaus.org/browse/MASSEMBLY-404 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2 >Reporter: Julien HENRY >Priority: Minor > Fix For: 2.2-beta-3 > > Attachments: test.zip > > > Hi, > The assembly created with the given test project produces different results > depending on the OS. > On Linux, the main JAR is present only once: htmlunit-XX.jar > On Windows, this JAR is present 2 times in the ZIP: > htmlunit-XX.jar > htmlunit-XX.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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
]
Dennis Lundberg closed MASSEMBLY-399.
-
Resolution: Fixed
Fix Version/s: 2.2-beta-5
> 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
> Fix For: 2.2-beta-5
>
>
> 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:
> {code:xml}
>
> maven-assembly-plugin
> 2.2-beta-3
>
>
> jar-with-dependencies
>
>
>
>
> src/main/resources/META-INF/MANIFEST.MF
>
>
>
>
> package
>
> attached
>
>
>
>
> {code}
> The generated jar is:
> {noformat}
> + the-jar
> + com
> + ...
> + TheClass.class
>+ C:
> + workspace
> + ...
> + TheClass.class
> {noformat}
> 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:
> {noformat}
> + the-jar
> + com
> + TheClass.class
> + TheClass.class
> {noformat}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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
]
Dennis Lundberg updated MASSEMBLY-399:
--
Description:
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:
{code:xml}
maven-assembly-plugin
2.2-beta-3
jar-with-dependencies
src/main/resources/META-INF/MANIFEST.MF
package
attached
{code}
The generated jar is:
{noformat}
+ the-jar
+ com
+ ...
+ TheClass.class
+ C:
+ workspace
+ ...
+ TheClass.class
{noformat}
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:
{noformat}
+ the-jar
+ com
+ TheClass.class
+ TheClass.class
{noformat}
whereas, if using version is 2.2-beta-1 the file is being generated properly
(no duplicate files at all).
was:
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).
> 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:
> {code:xml}
>
> maven-assembly-plugin
> 2.2-beta-3
>
>
> jar-with-dependencies
>
>
>
>
> src/main/resources/META-INF/MANIFEST.MF
>
>
>
>
> package
>
> attached
>
>
>
>
> {code}
> The generated jar is:
> {noformat}
> + the-jar
> + com
> + ...
> + TheClass.class
>+ C:
> + workspace
> + ...
> + TheClass.class
> {noformat}
> 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:
> {noformat}
> + the-jar
> + com
> + TheClass.class
> + TheClass.class
> {noformat}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassi
[jira] (MASSEMBLY-395) Module dependencies not included
[ https://jira.codehaus.org/browse/MASSEMBLY-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-395: -- Component/s: moduleSet > Module dependencies not included > - > > Key: MASSEMBLY-395 > URL: https://jira.codehaus.org/browse/MASSEMBLY-395 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: moduleSet >Affects Versions: 2.2-beta-3 > Environment: Maven version: 2.0.9 > Java version: 1.5.0_09 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Jaan Vajakas > Attachments: my-app.assembly-plugin-2.2.zip, my-app.zip > > > Maven assebly plugin 2.2-beta-3 does not include module dependencies, even > when the explicit true is used in > assembly descriptor. Maven assebly plugin 2.2-beta-2 did not have this issue. > See the attached project: running mvn package for the parent project my-app > creates a ZIP that contains only my-app-module1-1.0-SNAPSHOT.jar. If assembly > plugin 2.2-beta-2 is used (i.e. if one replaces 2.2-beta-3 with 2.2-beta-2 in > pom.xml of my-app) then the ZIP also contains my-app-module2-1.0-SNAPSHOT.jar > and junit-3.8.1.jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-384) using goal assembly:single with descriptorRef jar-with-dependencies packages wrong content
[
https://jira.codehaus.org/browse/MASSEMBLY-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MASSEMBLY-384.
-
Resolution: Fixed
Fix Version/s: 2.2-beta-4
> using goal assembly:single with descriptorRef jar-with-dependencies packages
> wrong content
> --
>
> Key: MASSEMBLY-384
> URL: https://jira.codehaus.org/browse/MASSEMBLY-384
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: Maven version: 2.0.9
> Java version: 1.5.0_12
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Radoslaw Czerniak
> Fix For: 2.2-beta-4
>
> Attachments: TestApplet.zip
>
>
> We attached the goal assembly:single to the package phase. The plugin
> execution is configured to use descriptorRef jar-with-dependencies
> The resulting jar-with-dependencies file also contains content that shouldn't
> be there.
> in the log you can see that the directory d: is added. this results in an
> extra directory D_ in the jar.
> mvn -X package:
> {noformat}
> ...
> [INFO] META-INF/ already added, skipping
> [INFO] META-INF/MANIFEST.MF already added, skipping
> [DEBUG] adding directory de/
> [DEBUG] adding directory de/spree/
> [DEBUG] adding directory de/spree/browsertest/
> [DEBUG] adding entry de/spree/browsertest/TestApplet$1.class
> [DEBUG] adding entry de/spree/browsertest/TestApplet$FileSizeListener.class
> [DEBUG] adding entry de/spree/browsertest/TestApplet.class
> [DEBUG] adding entry log4j.xml
> [DEBUG] adding directory META-INF/maven/
> [DEBUG] adding directory META-INF/maven/de.spree.browsertest/
> [DEBUG] adding directory META-INF/maven/de.spree.browsertest/TestApplet/
> [DEBUG] adding entry META-INF/maven/de.spree.browsertest/TestApplet/pom.xml
> [DEBUG] adding entry
> META-INF/maven/de.spree.browsertest/TestApplet/pom.properties
> [DEBUG] adding directory D:/
> [DEBUG] adding directory D:/maven_test/
> [DEBUG] adding directory D:/maven_test/TestApplet/
> [DEBUG] adding directory D:/maven_test/TestApplet/target/
> [DEBUG] adding directory D:/maven_test/TestApplet/target/classes/
> [DEBUG] adding directory D:/maven_test/TestApplet/target/classes/de/
> [DEBUG] adding directory D:/maven_test/TestApplet/target/classes/de/spree/
> [DEBUG] adding directory
> D:/maven_test/TestApplet/target/classes/de/spree/browsertest/
> [DEBUG] adding entry
> D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet$1.class
> [DEBUG] adding entry
> D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet$FileSizeListener.class
> [DEBUG] adding entry
> D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet.class
> [DEBUG] adding entry D:/maven_test/TestApplet/target/classes/log4j.xml
> [INFO]
>
> {noformat}
> toplevel contents of the jar-with-dependencies:
> {noformat}
> 15.01.2009 12:54 .
> 15.01.2009 12:54 ..
> 15.01.2009 12:54 de
> 15.01.2009 12:54 D_
> 15.01.2009 12:52 1.017 log4j.xml
> 15.01.2009 12:54 META-INF
> 15.01.2009 12:54 org
> {noformat}
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-384) using goal assembly:single with descriptorRef jar-with-dependencies packages wrong content
[
https://jira.codehaus.org/browse/MASSEMBLY-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-384:
--
Description:
We attached the goal assembly:single to the package phase. The plugin execution
is configured to use descriptorRef jar-with-dependencies
The resulting jar-with-dependencies file also contains content that shouldn't
be there.
in the log you can see that the directory d: is added. this results in an extra
directory D_ in the jar.
mvn -X package:
{noformat}
...
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[DEBUG] adding directory de/
[DEBUG] adding directory de/spree/
[DEBUG] adding directory de/spree/browsertest/
[DEBUG] adding entry de/spree/browsertest/TestApplet$1.class
[DEBUG] adding entry de/spree/browsertest/TestApplet$FileSizeListener.class
[DEBUG] adding entry de/spree/browsertest/TestApplet.class
[DEBUG] adding entry log4j.xml
[DEBUG] adding directory META-INF/maven/
[DEBUG] adding directory META-INF/maven/de.spree.browsertest/
[DEBUG] adding directory META-INF/maven/de.spree.browsertest/TestApplet/
[DEBUG] adding entry META-INF/maven/de.spree.browsertest/TestApplet/pom.xml
[DEBUG] adding entry
META-INF/maven/de.spree.browsertest/TestApplet/pom.properties
[DEBUG] adding directory D:/
[DEBUG] adding directory D:/maven_test/
[DEBUG] adding directory D:/maven_test/TestApplet/
[DEBUG] adding directory D:/maven_test/TestApplet/target/
[DEBUG] adding directory D:/maven_test/TestApplet/target/classes/
[DEBUG] adding directory D:/maven_test/TestApplet/target/classes/de/
[DEBUG] adding directory D:/maven_test/TestApplet/target/classes/de/spree/
[DEBUG] adding directory
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/
[DEBUG] adding entry
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet$1.class
[DEBUG] adding entry
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet$FileSizeListener.class
[DEBUG] adding entry
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet.class
[DEBUG] adding entry D:/maven_test/TestApplet/target/classes/log4j.xml
[INFO]
{noformat}
toplevel contents of the jar-with-dependencies:
{noformat}
15.01.2009 12:54 .
15.01.2009 12:54 ..
15.01.2009 12:54 de
15.01.2009 12:54 D_
15.01.2009 12:52 1.017 log4j.xml
15.01.2009 12:54 META-INF
15.01.2009 12:54 org
{noformat}
was:
We attached the goal assembly:single to the package phase. The plugin execution
is configured to use descriptorRef jar-with-dependencies
The resulting jar-with-dependencies file also contains content that shouldn't
be there.
in the log you can see that the directory d: is added. this results in an extra
directory D_ in the jar.
mvn -X package:
...
[INFO] META-INF/ already added, skipping
[INFO] META-INF/MANIFEST.MF already added, skipping
[DEBUG] adding directory de/
[DEBUG] adding directory de/spree/
[DEBUG] adding directory de/spree/browsertest/
[DEBUG] adding entry de/spree/browsertest/TestApplet$1.class
[DEBUG] adding entry de/spree/browsertest/TestApplet$FileSizeListener.class
[DEBUG] adding entry de/spree/browsertest/TestApplet.class
[DEBUG] adding entry log4j.xml
[DEBUG] adding directory META-INF/maven/
[DEBUG] adding directory META-INF/maven/de.spree.browsertest/
[DEBUG] adding directory META-INF/maven/de.spree.browsertest/TestApplet/
[DEBUG] adding entry META-INF/maven/de.spree.browsertest/TestApplet/pom.xml
[DEBUG] adding entry
META-INF/maven/de.spree.browsertest/TestApplet/pom.properties
[DEBUG] adding directory D:/
[DEBUG] adding directory D:/maven_test/
[DEBUG] adding directory D:/maven_test/TestApplet/
[DEBUG] adding directory D:/maven_test/TestApplet/target/
[DEBUG] adding directory D:/maven_test/TestApplet/target/classes/
[DEBUG] adding directory D:/maven_test/TestApplet/target/classes/de/
[DEBUG] adding directory D:/maven_test/TestApplet/target/classes/de/spree/
[DEBUG] adding directory
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/
[DEBUG] adding entry
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet$1.class
[DEBUG] adding entry
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet$FileSizeListener.class
[DEBUG] adding entry
D:/maven_test/TestApplet/target/classes/de/spree/browsertest/TestApplet.class
[DEBUG] adding entry D:/maven_test/TestApplet/target/classes/log4j.xml
[INFO]
toplevel contents of the jar-with-dependencies:
15.01.2009 12:54 .
15.01.2009 12:54 ..
15.01.2009 12:54 de
15.01.2009 12:54 D_
15.01.2009 12:52 1.017 log4j.xml
15.01.2009 12:54
[jira] (SUREFIRE-921) post-integration-test phase should be executed when pre-integration-test phase fails
Davy De Waele created SUREFIRE-921: -- Summary: post-integration-test phase should be executed when pre-integration-test phase fails Key: SUREFIRE-921 URL: https://jira.codehaus.org/browse/SUREFIRE-921 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 2.12.4 Reporter: Davy De Waele When exceptions occur in the pre-integration-test phase no cleanup is being done (post-integration-test is not executed when pre-integration-test fails). Typically in the pre-integration-test phase servers are started or applications are deployed that can potentially be error-prone and might leave the system in a dirty state. Could this be an enhancement of the failsafe plugin or is there another way to handle this scenario ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-383) Different behaviour between linux and windows regarding SNASPHOT dependencies packaging
[
https://jira.codehaus.org/browse/MASSEMBLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-383:
--
Description:
I've used the following descriptor to pack all the transitive dependencies of a
project in a single tar.gz:
{code:xml}
bin
tar.gz
lib
*:*
false
runtime
{code}
I've got different results if running mvn assembly:assembly in linux or in
windows, regarding the SNASPSHOT dependencies.
In linux the SNAPSHOT dependencies jars are of the form:
depName-1.4-beta-6-SNAPSHOT.jar
In windows the same SNAPSHOT dependencies jars are of the form:
depName-1.4-beta-6-20090114.094414-1.jar
Best regards,
Enrico
was:
I've used the following descriptor to pack all the transitive dependencies of a
project in a single tar.gz:
bin
tar.gz
lib
*:*
false
runtime
I've got different results if running mvn assembly:assembly in linux or in
windows, regarding the SNASPSHOT dependencies.
In linux the SNAPSHOT dependencies jars are of the form:
depName-1.4-beta-6-SNAPSHOT.jar
In windows the same SNAPSHOT dependencies jars are of the form:
depName-1.4-beta-6-20090114.094414-1.jar
Best regards,
Enrico
> Different behaviour between linux and windows regarding SNASPHOT dependencies
> packaging
> ---
>
> Key: MASSEMBLY-383
> URL: https://jira.codehaus.org/browse/MASSEMBLY-383
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: windows, linux
>Reporter: Enrico Boldrini
>
> I've used the following descriptor to pack all the transitive dependencies of
> a project in a single tar.gz:
> {code:xml}
>
>
> bin
>
> tar.gz
>
>
>
> lib
>
> *:*
>
> false
> runtime
>
>
>
> {code}
> I've got different results if running mvn assembly:assembly in linux or in
> windows, regarding the SNASPSHOT dependencies.
> In linux the SNAPSHOT dependencies jars are of the form:
> depName-1.4-beta-6-SNAPSHOT.jar
> In windows the same SNAPSHOT dependencies jars are of the form:
> depName-1.4-beta-6-20090114.094414-1.jar
> Best regards,
> Enrico
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-369) Assembly plugin process it's commands from it's pom (in addition to an external file)
[
https://jira.codehaus.org/browse/MASSEMBLY-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-369:
--
Description:
Currently the plugin requires an external file to get it's configuration from.
Can we simply not have this expressed inside the pom itself?
What we currently have:
{code:xml}
maven-assembly-plugin
assembly.xml
make-assembly
package
attached
{code}
and assembly.xml:
{code:xml}
zip
false
true
*.jar
runtime
{code}
What I'd like:
{code:xml}
maven-assembly-plugin
zip
false
true
*.jar
runtime
make-assembly
package
attached
{code}
I do find it strange that it is a plugin that does *not* take it's input from a
pom.
Even a managed artifact would be fine (put assembly.xml in a resource jar and
list it as a dependency - that would also work for me).
-Chris
was:
Currently the plugin requires an external file to get it's configuration from.
Can we simply not have this expressed inside the pom itself?
What we currently have:
maven-assembly-plugin
assembly.xml
make-assembly
package
attached
and assembly.xml:
zip
false
true
*.jar
runtime
What I'd like:
maven-assembly-plugin
zip
false
true
*.jar
runtime
make-assembly
package
attached
I do find it strange that it is a plugin that does *not* take it's input from a
pom.
Even a managed artifact would be fine (put assembly.xml in a resource jar and
list it as a dependency - that would also work for me).
-Chris
> Assembly plugin process it's commands from it's pom (in addition to an
> external file)
> -
>
> Key: MASSEMBLY-369
> URL: https://jira.codehaus.org/browse/MASSEMBLY-369
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
> Environment: N/A
>Reporter: Chris Graham
>
> Currently the plugin requires an external file to get it's configuration from.
> Can we simply not have this expressed inside the pom itself?
> What we currently have:
> {code:xml}
>
> maven-assembly-plugin
>
[jira] (MASSEMBLY-317) useStrictFiltering requires dependency in all included modules
[
https://jira.codehaus.org/browse/MASSEMBLY-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-317:
--
Component/s: moduleSet
> useStrictFiltering requires dependency in all included modules
> --
>
> Key: MASSEMBLY-317
> URL: https://jira.codehaus.org/browse/MASSEMBLY-317
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: moduleSet
>Affects Versions: 2.2-beta-2
>Reporter: Thomas Diesler
>
> With this moduleSet all dependency artifacts must be defined in all included
> modules
> {code:xml}
>
>
> org.jboss.ws:jbossws-cxf-server
> org.jboss.ws:jbossws-cxf-client
>
>
> server/default/deploy/jbossws.sar
>
> ${module.artifactId}.${module.extension}
> false
>
>
>
> ${module.artifactId}.${module.extension}
> true
>
> *:cxf-*
> *:geronimo-javamail*
> *:geronimo-ws-metadata*
> *:jaxrpc-api*
> *:jaxws-api*
> *:neethi*
> *:saaj-api*
> *:saaj-impl*
> *:spring-beans*
> *:spring-context*
> *:spring-core*
> *:wsdl4j*
> *:xml-resolver*
> *:XmlSchema*
>
>
>
>
>
> {code}
> I believe this should be changed such that the dependency is satisfied by at
> least one module.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-268) Descriptor bundling dependency sets should contain tag
[
https://jira.codehaus.org/browse/MASSEMBLY-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-268:
--
Component/s: dependencySet
> Descriptor bundling dependency sets should contain tag
> -
>
> Key: MASSEMBLY-268
> URL: https://jira.codehaus.org/browse/MASSEMBLY-268
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Components: dependencySet
>Affects Versions: 2.2-beta-1
>Reporter: Michael Osipov
>
> I am bundling bin distros and include in folders my dependency sets:
> say I have this:
> {code:xml}
>
>
> lib
> complile
>
>
> {code}
> It bundles al libs which are necessary to compile, means compile, provided
> which makes sense. Hence, I want to be able to include libs exclusively from
> a scope.
> Like
> {code:xml}
>
>
> lib
> compile
> true
>
>
> {code}
> which basically mean it will include only those libs which have been declared
> compile and no provided. Tag should default to false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-324) DependencySet scope runtime includes jars that are scope provided
[
https://jira.codehaus.org/browse/MASSEMBLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-324:
--
Component/s: dependencySet
> DependencySet scope runtime includes jars that are scope provided
> -
>
> Key: MASSEMBLY-324
> URL: https://jira.codehaus.org/browse/MASSEMBLY-324
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2-beta-2
>Reporter: Michael Mattox
>
> I use some jars in provided scope:
> {code:xml}
>
> javax.servlet
> servlet-api
> 2.5
> provided
>
> {code}
> in my assembly, I specify scope as runtime:
> {code:xml}
>
> WEB-INF/lib
> false
> runtime
>
> {code}
> Yet I still find the servlet-api-2.5.jar in my WAR. SInce the servlet-api is
> scope provided, it should be provided by the container and not included in
> the WAR.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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
]
Dennis Lundberg updated MASSEMBLY-357:
--
Component/s: dependencySet
> 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
> Components: dependencySet
>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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-286) Index.list support with Assembly Plugin
[
https://jira.codehaus.org/browse/MASSEMBLY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-286:
--
Component/s: maven-archiver
> Index.list support with Assembly Plugin
> ---
>
> Key: MASSEMBLY-286
> URL: https://jira.codehaus.org/browse/MASSEMBLY-286
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: 2.1
>Reporter: darren hartford
>
> Enable or show how to create index.list (see maven archiver) when using
> assembly with jar-with-dependencies for 'uberjar'/'fatjar' approach.
> Expected:
> {code:xml}
>
>
>true
>
> ...
>
> {code}
> to create META-INF/INDEX.LIST with all class files (including the dependency
> class files).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-356) Improve predefined project descriptor
[
https://jira.codehaus.org/browse/MASSEMBLY-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-356:
--
Component/s: predefined descriptors
> Improve predefined project descriptor
> -
>
> Key: MASSEMBLY-356
> URL: https://jira.codehaus.org/browse/MASSEMBLY-356
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
> Components: predefined descriptors
>Affects Versions: 2.2-beta-2
>Reporter: Michael Osipov
>
> The predefined project descriptor is great but I could be better:
> {code:xml}
>
> project
>
> zip
> tar.gz
>
>
>
>
> **/target/
> **/.settings/
> **/.*
>
>
>
>
> {code}
> This code does the same but has less lines and excludes eclipse (and maybe)
> other IDE's project settings.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-353) Variable interpolation doesn't work with nested component descriptors
[
https://jira.codehaus.org/browse/MASSEMBLY-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-353:
--
Component/s: component descriptor
Description:
When I nest another component descriptor file like so
{code:xml}
src/main/descriptors/common-bin.xml
{code}
any variable refs such as ${pom.artifactId} or ${pom.version} do not get
resolved in the nested descriptor.
was:
When I nest another component descriptor file like so
src/main/descriptors/common-bin.xml
any variable refs such as ${pom.artifactId} or ${pom.version} do not get
resolved in the nested descriptor.
> Variable interpolation doesn't work with nested component descriptors
> -
>
> Key: MASSEMBLY-353
> URL: https://jira.codehaus.org/browse/MASSEMBLY-353
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.1, 2.2-beta-2
>Reporter: Jonathan Anstey
>Priority: Minor
>
> When I nest another component descriptor file like so
> {code:xml}
>
>
> src/main/descriptors/common-bin.xml
>
> {code}
> any variable refs such as ${pom.artifactId} or ${pom.version} do not get
> resolved in the nested descriptor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-349) Can't download component descriptor from repository
[ https://jira.codehaus.org/browse/MASSEMBLY-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-349: -- Component/s: component descriptor > Can't download component descriptor from repository > --- > > Key: MASSEMBLY-349 > URL: https://jira.codehaus.org/browse/MASSEMBLY-349 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.2-beta-2 >Reporter: Anders Blaagaard > > When deploying a component descriptor with packaging "assembly-component", > the file ends with "assembly-component.xml" in the repository. > When attempting to use this in an assembly descriptor, it seems to be looking > for a file ending with ".assembly-component" in the repository and fails to > find it. > Looking at the code my guess is that the ArtifactLocatorStrategy constructor > call in DefaultAssemblyReader.mergeComponentsWithMainAssembly is missing an > "xml" argument before the "assembly-component" argument? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-343) add symbolic links managment
[ https://jira.codehaus.org/browse/MASSEMBLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-343: -- Description: i need to buid archives ( tar for example ) with symbolic links the plugin build an archive with a file containing the destination of the link, not the link itself => the plugin need an option to know if deferencement of links is needed this is just like -h option of tar -h, --dereference don't dump symlinks; dump the files they point to actually, if you do an archive of /lib, for example, many file will be in double with différent names. extract of archive will not be the exactly the same as the source of the archive. => this is a test ! was: i need to buid archives ( tar for example ) with symbolic links the plugin build an archive with a file containing the destination of the link, not the link itself => the plugin need an option to know if deferencement of links is needed this is just like -h option of tar -h, --dereference don't dump symlinks; dump the files they point to actually, if you do an archive of /lib, for example, many file will be in double with différent names. extract of archive will not be the exactly the same as the source of the archive. => this is a test ! Patch Submitted: Yes > add symbolic links managment > > > Key: MASSEMBLY-343 > URL: https://jira.codehaus.org/browse/MASSEMBLY-343 > Project: Maven 2.x Assembly Plugin > Issue Type: Wish >Affects Versions: 2.2-beta-2 > Environment: linux, ubuntu >Reporter: Godet Gilles > Attachments: MASSEMBLY-343_maven-assembly-plugin_fixed.patch, > MASSEMBLY-343_maven-assembly-plugin.patch > > > i need to buid archives ( tar for example ) with symbolic links > the plugin build an archive with a file containing the destination of the > link, not the link itself > => the plugin need an option to know if deferencement of links is needed > this is just like -h option of tar > -h, --dereference > don't dump symlinks; dump the files they point to > actually, if you do an archive of /lib, for example, many file will be in > double with différent names. extract of archive will not be the exactly the > same as the source of the archive. => this is a test ! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-334) Can not generate class-path from Manifest
[
https://jira.codehaus.org/browse/MASSEMBLY-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-334:
--
Component/s: manifest
Description:
I have a maven's projet multi-module.
I have a problem when i launch mvn package assembly:assembly
In the Manifest file, the class path does not generated.
Pom project
{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/maven-v4_0_0.xsd";>
4.0.0
com.ipsis.pacha
Pacha
pom
1.0-SNAPSHOT
PACHA
maven-antrun-plugin
print-maven-runtime-classpath
compile
run
print-maven-test-classpath
test-compile
run
maven-compiler-plugin
1.6
1.6
512m
1024m
true
true
true
${JAVA_HOME}\bin\javac.exe
1.6
true
maven-deploy-plugin
true
org.apache.maven.plugins
maven-release-plugin
deploy
maven-surefire-plugin
maven-eclipse-plugin
2.0
/classes
false
org.eclipse.jdt.launching.JRE_CONTAINER
maven-site-plugin
fr
ISO-8859-1
ISO-8859-1
[jira] (MASSEMBLY-317) useStrictFiltering requires dependency in all included modules
[
https://jira.codehaus.org/browse/MASSEMBLY-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-317:
--
Description:
With this moduleSet all dependency artifacts must be defined in all included
modules
{code:xml}
org.jboss.ws:jbossws-cxf-server
org.jboss.ws:jbossws-cxf-client
server/default/deploy/jbossws.sar
${module.artifactId}.${module.extension}
false
${module.artifactId}.${module.extension}
true
*:cxf-*
*:geronimo-javamail*
*:geronimo-ws-metadata*
*:jaxrpc-api*
*:jaxws-api*
*:neethi*
*:saaj-api*
*:saaj-impl*
*:spring-beans*
*:spring-context*
*:spring-core*
*:wsdl4j*
*:xml-resolver*
*:XmlSchema*
{code}
I believe this should be changed such that the dependency is satisfied by at
least one module.
was:
With this moduleSet all dependency artifacts must be defined in all included
modules
org.jboss.ws:jbossws-cxf-server
org.jboss.ws:jbossws-cxf-client
server/default/deploy/jbossws.sar
${module.artifactId}.${module.extension}
false
${module.artifactId}.${module.extension}
true
*:cxf-*
*:geronimo-javamail*
*:geronimo-ws-metadata*
*:jaxrpc-api*
*:jaxws-api*
*:neethi*
*:saaj-api*
*:saaj-impl*
*:spring-beans*
*:spring-context*
*:spring-core*
*:wsdl4j*
*:xml-resolver*
*:XmlSchema*
I believe this should be changed such that the dependency is satisfied by at
least one module.
> useStrictFiltering requires dependency in all included modules
> --
>
> Key: MASSEMBLY-317
> URL: https://jira.codehaus.org/browse/MASSEMBLY-317
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Thomas Diesler
>
> With this moduleSet all dependency artifacts must be defined in all included
> modules
> {code:xml}
>
>
> org.jboss.ws:jbossws-cxf-server
> org.jboss.ws:jbossws-cxf-client
>
>
> server/default/deploy/jbossws.sar
>
> ${module.artifactId}.${module.extension}
> false
>
>
>
> ${module.artifactId}.${module.extension}
> true
>
> *:cxf-*
> *:geronimo-javamail*
> *:geronimo-ws-metadata*
> *:jaxrpc-api*
> *:jaxws-api*
> *:neethi*
> *:saaj-api*
> *:saaj-impl*
> *:spring-beans*
> *:spring-context*
> *:spring-core*
> *:wsdl4j*
> *:xml-resolver*
> *:XmlSchema*
>
>
>
>
>
> {code}
> I believe this should be changed such that the dependency is satisfied by at
> least one module.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-310) improve site inclusion handling in assemblies
[
https://jira.codehaus.org/browse/MASSEMBLY-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-310:
--
Component/s: site
Description:
The current state of including the site into an assembly is extremely bad.
There is but this suits only for a single module project.
if you do have a multimodule project, try so assemble all subsites into the
parent sie module, you have to struggle with fileset or modulesets or both.
I was able to solve this for me with:
{code:xml}
false
site/${artifactId}
target/site
{code}
This is a better way than using the regular fiesets but still an ugly solution
since I needed several hours to accomplish that the way I wanted.
I am asking for a more profound and easier solution for this. It could be
solved maybe with site:jar and usage of binaries and attachmentClassifer = site
but this still seems quite inferior.
I propose something like this:
{code:xml}
true
{code}
The in- and excludes would make it quite flexible. An much more easier approach
without any flexibility would just be introduce a
.
was:
The current state of including the site into an assembly is extremely bad.
There is but this suits only for a single module project.
if you do have a multimodule project, try so assemble all subsites into the
parent sie module, you have to struggle with fileset or modulesets or both.
I was able to solve this for me with:
{code}
false
site/${artifactId}
target/site
{code}
This is a better way than using the regular fiesets but still an ugly solution
since I needed several hours to accomplish that the way I wanted.
I am asking for a more profound and easier solution for this. It could be
solved maybe with site:jar and usage of binaries and attachmentClassifer = site
but this still seems quite inferior.
I propose something like this:
{code}
true
{code}
The in- and excludes would make it quite flexible. An much more easier approach
without any flexibility would just be introduce a
.
> improve site inclusion handling in assemblies
> -
>
> Key: MASSEMBLY-310
> URL: https://jira.codehaus.org/browse/MASSEMBLY-310
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
> Components: site
>Affects Versions: 2.2-beta-2
> Environment: Maven 2.0.9, Win XP SP2
>Reporter: Michael Osipov
>
> The current state of including the site into an assembly is extremely bad.
> There is but this suits only for a single module
> project.
> if you do have a multimodule project, try so assemble all subsites into the
> parent sie module, you have to struggle with fileset or modulesets or both.
> I was able to solve this for me with:
> {code:xml}
>
>
> false
>
>
> site/${artifactId}
> target/site
>
>
>
>
> {code}
> This is a better way than using the regular fiesets but still an ugly
> solution since I needed several hours to accomplish that the way I wanted.
> I am asking for a more profound and easier solution for this. It could be
> solved maybe with site:jar and usage of binaries and attachmentClassifer =
> site but this still seems quite inferior.
> I propose something like this:
> {code:xml}
>
>
> true
>
> {code}
> The in- and excludes would make it quite flexible. An much more easier
> approach without any flexibility would just be introduce a
> .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-295) Repository assembly contains local metadata
[ https://jira.codehaus.org/browse/MASSEMBLY-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-295: -- Patch Submitted: Yes > Repository assembly contains local metadata > --- > > Key: MASSEMBLY-295 > URL: https://jira.codehaus.org/browse/MASSEMBLY-295 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Wendy Smoak > Attachments: massembly-295-assembly-plugin.diff, > massembly-295-repo-builder.diff > > > When using the assembly plugin to construct a remote repository as described > on > http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-repositories.html, > the repository contains "local" metadata files such as > maven-metadata-central.xml. > The remote repository format should only contain maven-metadata.xml files. > Need to re-test with 2.2-beta-2 to confirm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-286) Index.list support with Assembly Plugin
[
https://jira.codehaus.org/browse/MASSEMBLY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-286:
--
Description:
Enable or show how to create index.list (see maven archiver) when using
assembly with jar-with-dependencies for 'uberjar'/'fatjar' approach.
Expected:
{code:xml}
true
...
{code}
to create META-INF/INDEX.LIST with all class files (including the dependency
class files).
was:
Enable or show how to create index.list (see maven archiver) when using
assembly with jar-with-dependencies for 'uberjar'/'fatjar' approach.
Expected:
true
...
to create META-INF/INDEX.LIST with all class files (including the dependency
class files).
> Index.list support with Assembly Plugin
> ---
>
> Key: MASSEMBLY-286
> URL: https://jira.codehaus.org/browse/MASSEMBLY-286
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: darren hartford
>
> Enable or show how to create index.list (see maven archiver) when using
> assembly with jar-with-dependencies for 'uberjar'/'fatjar' approach.
> Expected:
> {code:xml}
>
>
>true
>
> ...
>
> {code}
> to create META-INF/INDEX.LIST with all class files (including the dependency
> class files).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-276) pom.properties and pom.xml missing from jar generated by jar-with-dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MASSEMBLY-276.
-
Resolution: Fixed
Fix Version/s: 2.2-beta-2
> pom.properties and pom.xml missing from jar generated by jar-with-dependencies
> --
>
> Key: MASSEMBLY-276
> URL: https://jira.codehaus.org/browse/MASSEMBLY-276
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Jaan Vajakas
> Fix For: 2.2-beta-2
>
>
> How to reproduce:
> * create a new project with
> mvn archetype:create -DgroupId=org.sample -DartifactId=sample2
> * modify the pom.xml, adding maven-assembly-plugin configuration (see below)
> * run mvn assembly:directory or mvn assemby:assembly
> Expected result: the created directory
> target/sample2-1.0-SNAPSHOT-jar-with-dependencies.dir or JAR
> target/sample2-1.0-SNAPSHOT-jar-with-dependencies.jar should contain files
> META-INF/maven/org.sample/sample2/pom.properties and
> META-INF/maven/org.sample/sample2/pom.xml,
> as in the example in
> http://maven.apache.org/plugins/maven-assembly-plugin/usage.html.
> Actual result: no pom.xml and pom.properties in the created directory or JAR.
> This is the pom.xml:
> {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/maven-v4_0_0.xsd";>
> 4.0.0
> org.sample
> sample2
> jar
> 1.0-SNAPSHOT
> sample2
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
>
>
> maven-assembly-plugin
> 2.2-beta-1
>
>
> jar-with-dependencies
>
>
>
>
>
>
>
> pluginrepo
> http://repo1.maven.org/maven2
>
> true
>
>
> true
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-271) For repository assembly, include pom.xml project plugins, as an option
[
https://jira.codehaus.org/browse/MASSEMBLY-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-271:
--
Description:
One use case for creating a repository archive, like so:
{code:xml}
repository
true
{code}
Is to allow the project pom to be runnable at a customer or remote site, which
does not have access to the central repository. Runnable, in the sense that
targets such as "exec:java" or the like can be called.
However, the repository archive does not include any plugins, especially custom
ones, that may be required to use a remotely deployed pom.xml.
I classified this as a "bug" since I feel without project plugins included, the
repository is not complete, but may be considered more of a "feature request"
instead.
A work-around is indicate custom plugins using
was:
One use case for creating a repository archive, like so:
repository
true
Is to allow the project pom to be runnable at a customer or remote site, which
does not have access to the central repository. Runnable, in the sense that
targets such as "exec:java" or the like can be called.
However, the repository archive does not include any plugins, especially custom
ones, that may be required to use a remotely deployed pom.xml.
I classified this as a "bug" since I feel without project plugins included, the
repository is not complete, but may be considered more of a "feature request"
instead.
A work-around is indicate custom plugins using
Issue Type: New Feature (was: Bug)
> For repository assembly, include pom.xml project plugins, as an option
> --
>
> Key: MASSEMBLY-271
> URL: https://jira.codehaus.org/browse/MASSEMBLY-271
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.2-beta-1
>Reporter: Elias Ross
>
> One use case for creating a repository archive, like so:
> {code:xml}
>
>
>
> repository
> true
>
>
>
> {code}
> Is to allow the project pom to be runnable at a customer or remote site,
> which does not have access to the central repository. Runnable, in the sense
> that targets such as "exec:java" or the like can be called.
> However, the repository archive does not include any plugins, especially
> custom ones, that may be required to use a remotely deployed pom.xml.
> I classified this as a "bug" since I feel without project plugins included,
> the repository is not complete, but may be considered more of a "feature
> request" instead.
> A work-around is indicate custom plugins using
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-269) Add distribution format 7-Zip
[
https://jira.codehaus.org/browse/MASSEMBLY-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-269:
--
Description:
Basically I want to have a
{code:xml}
7z
{code}
7-Zip is a highly efficient format. http://www.7-zip.org/
was:
Basically I want to have a
7z
7-Zip ist ja highly efficient format. http://www.7-zip.org/
> Add distribution format 7-Zip
> -
>
> Key: MASSEMBLY-269
> URL: https://jira.codehaus.org/browse/MASSEMBLY-269
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-1
>Reporter: Michael Osipov
>
> Basically I want to have a
> {code:xml}
>
> 7z
>
> {code}
> 7-Zip is a highly efficient format. http://www.7-zip.org/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-268) Descriptor bundling dependency sets should contain tag
[
https://jira.codehaus.org/browse/MASSEMBLY-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-268:
--
Description:
I am bundling bin distros and include in folders my dependency sets:
say I have this:
{code:xml}
lib
complile
{code}
It bundles al libs which are necessary to compile, means compile, provided
which makes sense. Hence, I want to be able to include libs exclusively from a
scope.
Like
{code:xml}
lib
compile
true
{code}
which basically mean it will include only those libs which have been declared
compile and no provided. Tag should default to false.
was:
I am bundling bin distros and include in folders my dependency sets:
say I have this:
lib
complile
It bundles al libs which are necessary to compile, means compile, provided
which makes sense. Hence, I want to be able to include libs exclusively from a
scope.
Like
lib
complie
true
which basically mean it will include only those libs which have been declared
compile and no provided. Tag should default to false.
> Descriptor bundling dependency sets should contain tag
> -
>
> Key: MASSEMBLY-268
> URL: https://jira.codehaus.org/browse/MASSEMBLY-268
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.2-beta-1
>Reporter: Michael Osipov
>
> I am bundling bin distros and include in folders my dependency sets:
> say I have this:
> {code:xml}
>
>
> lib
> complile
>
>
> {code}
> It bundles al libs which are necessary to compile, means compile, provided
> which makes sense. Hence, I want to be able to include libs exclusively from
> a scope.
> Like
> {code:xml}
>
>
> lib
> compile
> true
>
>
> {code}
> which basically mean it will include only those libs which have been declared
> compile and no provided. Tag should default to false.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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 ] Dennis Lundberg updated MASSEMBLY-22: - Component/s: site > 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 > Components: site >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. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-265) Run site:site if includeSiteDirectory is set to true
[ https://jira.codehaus.org/browse/MASSEMBLY-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-265: -- Component/s: site > Run site:site if includeSiteDirectory is set to true > > > Key: MASSEMBLY-265 > URL: https://jira.codehaus.org/browse/MASSEMBLY-265 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature > Components: site >Reporter: Michael Osipov > > running a descriptor with the above attribute set to true causes an build > failure when site has not been geneated. > Call site:site when attribute is set to true. > same fuction as calling package since package is already called by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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
]
Dennis Lundberg updated MASSEMBLY-219:
--
Description:
I am creating a simple repository with SNAPSHOTs
{code:xml}
true
test
repo
{code}
The assembly plugins stores SNAPSHOTs in a wrong location (see the name of the
directory with the timestamp) 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 snapshot artifacts are stored properly
was:
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
> 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: Stéphane Nicoll
>
> I am creating a simple repository with SNAPSHOTs
> {code:xml}
>
>
> true
> test
> repo
>
>
> {code}
> The assembly plugins stores SNAPSHOTs in a wrong location (see the name of
> the directory with the timestamp) 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 snapshot artifacts are stored properly
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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
]
Dennis Lundberg updated MASSEMBLY-218:
--
Description:
I am creating a simple repository with a project that contains classified
dependencies (obfuscated jars):
{code:xml}
true
test
repo
{code}
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.
was:
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.
> 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: Stéphane Nicoll
>
> I am creating a simple repository with a project that contains classified
> dependencies (obfuscated jars):
> {code:xml}
>
>
> true
> test
> repo
>
>
> {code}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-177) There should be a manifest section in an assembly [external] descriptor
[ https://jira.codehaus.org/browse/MASSEMBLY-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MASSEMBLY-177: -- Component/s: manifest > There should be a manifest section in an assembly [external] descriptor > --- > > Key: MASSEMBLY-177 > URL: https://jira.codehaus.org/browse/MASSEMBLY-177 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature > Components: manifest >Affects Versions: 2.1 >Reporter: Bernd > > Manifest modifications should be possible on a per assembly basis, e.g. > different main classes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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 ] Dennis Lundberg closed MASSEMBLY-176. - Resolution: Incomplete Closing because of lack of response. > 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-45) Support for mappers in assembly desriptors
[
https://jira.codehaus.org/browse/MASSEMBLY-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-45:
-
Patch Submitted: Yes
> 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:
> {noformat}
> Root
>|-Module1
>|-Module2
>|-Container
>| |-Module3
>| |-Module4
>|-Module5
>|- pom.xml
> {noformat}
> and an assembly desriptor entry for the contained modules like this
> {code:xml}
>
>
> Container
>
>
> **/target/*.jar
>
>
>
> {code}
> 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:
> {code:xml}
>
>
> Container
>
>
> **/target/*.jar
>
>
>
>
> {code}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (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
]
Dennis Lundberg updated MASSEMBLY-75:
-
Description:
"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:
{code:xml}
foo
bar
tar
compile
{code}
and our assembly.xml has the following:
{code:xml}
tar.gz
compile
foo:bar
true
{code}
then the generated assembly will contain "baz", but it will no longer be
executable.
was:
"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.
> 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:
> {code:xml}
>
> foo
> bar
> tar
> compile
>
> {code}
> and our assembly.xml has the following:
> {code:xml}
>
>
>
> tar.gz
>
>
>
>
> compile
>
>
> foo:bar
>
> true
>
> {code}
> then the generated assembly will contain "baz", but it will no longer be
> executable.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-45) Support for mappers in assembly desriptors
[
https://jira.codehaus.org/browse/MASSEMBLY-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-45:
-
Description:
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:
{noformat}
Root
|-Module1
|-Module2
|-Container
| |-Module3
| |-Module4
|-Module5
|- pom.xml
{noformat}
and an assembly desriptor entry for the contained modules like this
{code:xml}
Container
**/target/*.jar
{code}
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:
{code:xml}
Container
**/target/*.jar
{code}
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
was:
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
> 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:
> {noformat}
> Root
>|-Module1
>|-Module2
>|-Container
>| |-Module3
>| |-Module4
>|-Module5
>|- pom.xml
> {noformat}
> and an assembly desriptor entry for the contained modules like this
> {code:xml}
>
>
> Container
>
>
> **/target/*.jar
>
>
>
> {code}
> 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:
> {code:xml}
>
>
> Container
>
>
> **/target/*.jar
>
>
>
>
> {code}
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312774#comment-312774
]
Christoph Kutzinski commented on MNG-5315:
--
We're seeing similar errors in our CI environment (Jenkins) quite frequently -
i.e. several times a day.
This causes major manual effort to determine the cause of the failure, restart
the build and wait
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Priority: Minor
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused
