[ http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104959 ]
Matthew McCullough edited comment on MASSEMBLY-211 at 8/15/07 5:59 PM: ----------------------------------------------------------------------- I'm seeing this problem on Maven 2.0.7 Because of MDEPLOY-57, I end up getting unique versions of JARs in my repository even when I have explicitly declared <uniqueVersion>false</uniqueVersion> Thus, this ripples and is made even worse by MASSEMBLY-211 because now my assembly:assembly pulls unique versioned jars into the assembly (ZIP), but the jar:jar command (when told to write a mainfest with a main class and classpath) points to all the non-unique-versioned jars. Thus, the classpath on the jar's manifest points to (for example) ccbs-config-common-server-1.0.M2.jar while the actual zip pulled down by assembly:assembly is ccbs-config-common-server-1.0.M2-20070814.152448-16.jar Thus, the application cannot be executed. was: Because of MDEPLOY-57, I end up getting unique versions of JARs in my repository even when I have explicitly declared <uniqueVersion>false</uniqueVersion> Thus, this ripples and is made even worse by MASSEMBLY-211 because now my assembly:assembly pulls unique versioned jars into the assembly (ZIP), but the jar:jar command (when told to write a mainfest with a main class and classpath) points to all the non-unique-versioned jars. Thus, the classpath on the jar's manifest points to (for example) ccbs-config-common-server-1.0.M2.jar while the actual zip pulled down by assembly:assembly is ccbs-config-common-server-1.0.M2-20070814.152448-16.jar Thus, the application cannot be executed. > assembly plugin and jar plugin disagree about whether to use uniqueVersion > snapshot names > ----------------------------------------------------------------------------------------- > > Key: MASSEMBLY-211 > URL: http://jira.codehaus.org/browse/MASSEMBLY-211 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Affects Versions: 2.2-beta-1 > Reporter: Max Bowsher > Priority: Blocker > Fix For: 2.2-beta-2 > > Attachments: CSMDirectoryListingOfJars.txt, CSMJarManifest.txt > > > Background: Consider the following setup: > jar-plugin configured with addClasspath=true, writing list of dependency jar > file names into manifest of project jar. > assembly-plugin configured with a dependencySet pulling all dependencies into > a single directory. > Result: application is runnable with with "java -jar mainartifact.jar" > There has long been a problem (i.e. with assembly-plugin 2.1) that when > deployed snapshot jars were in use, the jar and assembly plugins would > disagree in whether the uniqueVersion name was used, and this is MNG-2456. > However, assembly-plugin 2.2-beta-1 has introduced further complications to > the situation by not using the lifecycle's default set of resolved artifacts, > but by running a manual resolution of its own. This has made the two plugins > disagree in more scenarios than before, and broke the workaround patch that I > posted in MNG-2456. > At the root of these problems is some very peculiar handling of the 'file', > 'baseVersion' and 'version' fields of Artifact objects, two notable instances > of which are the DefaultArtifact.isSnapshot method, which despite being an > accessor, actually changes the state of the object, and the > DefaultArtifactResolver.resolve method, which contains some rather bizarre > manipulation of the 'file' field (more detail may comments in MNG-2456). > An interim fix to this issue might involve workarounds in both the jar and > assembly plugins to get them to agree. A true fix probably also involves > fixing Maven core classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira