[
http://jira.codehaus.org/browse/MASSEMBLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-409:
--------------------------------------
Fix Version/s: (was: 2.2)
> Predefined project assembly needs fixes to use it for ASF based source
> releases
> ---------------------------------------------------------------------------------
>
> Key: MASSEMBLY-409
> URL: http://jira.codehaus.org/browse/MASSEMBLY-409
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
> Affects Versions: 2.2-beta-2, 2.2-beta-3
> Reporter: Ate Douma
> Assignee: John Casey
> Priority: Critical
>
> We've been using the 2.2-beta-2 plugin for recent Apache Portals releases
> (not 2.2-beta-3 because of MASSEMBLY-405) en encountered a few annoying
> issues.
> 1) Used together with "apache-release" profile of the Apache 6 pom, the
> maven-remote-resource-plugin is also executed by default (as it should) but
> that produces a velocity.log file in the project root which is then included
> by the "project" assembly. The main problem IMO is that predefined assemblies
> do not take *any* configuration overrides/extensions.
> As each (ASF) project is different, the likelihood some temporary build
> output is produced during the release and subsequently "assembled" should be
> expected, the velocity.log produced by the m-r-r-p just being an example.
> My preference therefore would be that predefined assemblies do accept
> additional configuration settings so we can include/exclude specific files as
> needed.
> If that is not doable (on short notice), the "project" assembly as a minimum
> should add an exclude for velocity.log as disabling creating that file on the
> m-r-r-p doesn't seem doable either.
> NB: see also http://issues.apache.org/jira/browse/PORTALS-16 as reference.
> 2) Related to the above is the fact that the "project" assembly uses
> classifier "project". This is by design of course, but as we are used to
> providing source distributions with a -src postfix, and end-users will look
> for that by default,
> it would be good if the classifier can be overridden/configurable (using the
> predefined "src" assembly instead clearly isn't possible for this purpose).
> However, even while the "classifier" is (still) specified as a *deprecated*
> optional parameter, it is completely ignored (now?).
> I strongly suggest to re-enable the "classifier" parameter again, or provide
> a new alternative parameter for this purpose.
--
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
