Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Won't Fix
-
Affects Version/s: 2.2-beta-2, 2.2-beta-3
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
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.
There is a better way to approach this problem for specific communities like ASF: use a plugin-level dependency, as described by:
http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
This approach decouples the release cycle for this one assembly descriptor from that of the assembly plugin itself, to allow for quicker revision and progress.
For instance, for ASF projects, they can use the following plugin-level dependency:
Then, use the following descriptorRef property reference:
Finally, use the following (overridable) property, to allow your sub-projects to build using a customized version of the descriptor if they need to: