[
http://jira.codehaus.org/browse/MASSEMBLY-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=128579#action_128579
]
John Casey commented on MASSEMBLY-211:
--------------------------------------
artifact-path handling needs to be consolidated somehow between the assembly
plugin and the component used to generate manifest files. This includes
formatting of the file names (or, determining when to use the 'native' file
path vs. a formatted one that would result from the file being copied to the
formatted location), but it also includes support for mapping artifacts to
specific subpaths within a directory structure, such as would be needed if all
dependencies were archived in the /lib directory of a jar whose Class-Path
manifest attribute attempted to reference them.
The mappings and formats need to then be made available to all plugins that
generate manifests. In the case of an assembly that consists of the project's
main jar with its dependencies listed in the /lib subpath, the jar:jar mojo
needs to know about this subpath when it generates the manifest, so its actions
are coordinated with those of the assembly plugin.
I would therefore propose a new plugin that will generate jar manifest files.
The manifest files will then be available for use in any plugin that supports
the MavenArchiveConfiguration from maven-archiver. In order to take advantage
of existing configurations, the plugin should also support providers that can
generate a Class-Path or other attribute based on some other configuration in
the project - with the first example being the dependencySets section of an
assembly descriptor. With an assembly provider, the assembly descriptor can be
read in order to determine to which path each artifact included should be
mapped.
> 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-3
>
> 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
