Support installation of

Here's something that makes it work. Depends on MNG-1251.

MNG-1251 was checked in, but my patch not taken in. In particular, the overloaded attachArtifact() method has not been made visible from the MavenProjectHelper interface, so the proposed patch for this issue is now broken.

I've had to readd it:

Index: src/main/java/org/apache/maven/project/MavenProjectHelper.java
===================================================================
— src/main/java/org/apache/maven/project/MavenProjectHelper.java (revision 331597)
+++ src/main/java/org/apache/maven/project/MavenProjectHelper.java (working copy)
@@ -23,6 +23,8 @@
{
String ROLE = MavenProjectHelper.class.getName();

+ void attachArtifact( MavenProject project, String artifactType, File artifactFile );
+
void attachArtifact( MavenProject project, String artifactType, String artifactClassifier, File artifactFile );

void addResource( MavenProject project, String resourceDirectory, List includes, List excludes );

This makes the attached patch build again. Please review both changes (and target 2.0.1?).

need to expose those methods in MavenProjectHelper, and see where we stand.

Just reading the attached patch...why do we want to stop using assembly.getId() as a classifier for the attached artifact?

I reran my build by disabling my patch to this issue and here's the results.

By keeping the assembly.getId(), the artifacts get deployed as

name-version-assemblyId.format

In my case I first reuse the assembly plugin to repackage a war file into a full war file (bundle some webstart applications in it). I then bundle this full war into a zip file with a J2EE container for easy deployment, once again using the assembly plugin in a different project. My second assembly configuration looks like the following:

(deploying the artifact as name-version.war and not name-version-main.war makes it easy to reference it like that)

<assembly>
<id>main</id>
<formats>
<format>zip</format>
</formats>
....
<dependencySets>
....
<dependencySet>
<outputDirectory>jakarta-tomcat-5.5.9/webapps/xxxx/</outputDirectory>
<includes>
<include>no.bbc.xxxx:full-webapp</include>
</includes>
<unpack>true</unpack>
<scope>runtime</scope>
</dependencySet>
</dependencySets>

As I am reusing this artifact inside another assembly, the fact that I am using the classifier makes it harder to reference it from within the other assembly plugin. I haven't foud a way yet to make the <include> work when there's a classifier in the dependency name.

Maybe that's just a limitation of the assembly plugin?

Comments appreciated.

It looks like this won't be necessary after all. If MNG-1274 and MNG-1462 are fixed, then I can reference the correct dependency using the <classifier> node in the <dependency> element.
Given that the IncludesArtifactFilter filter implementation only takes into account the groupId and artifactId, I don't need to update my include dependency in the assembly config.

public boolean include( Artifact artifact )
{
String id = artifact.getGroupId() + ":" + artifact.getArtifactId();

boolean matched = false;
for ( Iterator i = patterns.iterator(); i.hasNext() & !matched; )
{
// TODO: what about wildcards? Just specifying groups? versions?
if ( id.equals( i.next() ) )

}
return matched;
}

So we can close that issue.