attachArtifact doesn't allow to attach an artifact with different type and no assembly

Need to make AttachedArtifact manage its own extension and allow empty classifier.

Also, need to introduce new variant of MavenProjectHelper.attachArtifact(..) to handle fuller specification of this information.

This fixes it for me. Not sure if that is the right thing to do, in particular with the API now potentially inconsistent:

projectHelper.attachArtifact( project, "zip", null, toFile ); fails

while

projectHelper.attachArtifact( project, "zip", toFile ); works

one may want to look into that.

Some comments:

• the updates to the poms are probably not needed. I just wanted to be sure to use 2.0.1-SNAPSHOT material. Feel free to apply separately.
• AttachedArtifact has a strange way of redirectign method calls to the parent instance. I came up with the fix in 5 minutes and it took me 30 min more to find out that the getArtifactHandler() was 'bypassing' my intended changes...
• and no, I don't have a test case... Except that this fixes what I've been trying to do.

[INFO] [install:install]
[INFO] Installing /home/jerome/Dev/m2/mojo-site/mojo/mojo-sandbox/webstart-maven-plugin/src/test/projects/project1/pom.xml to /home/jerome/.m2/repository-m2trunk/org/apache/maven/plugins/jar-mng-1130-0/1.0/jar-mng-1130-0-1.0.pom
[INFO] Installing /home/jerome/Dev/m2/mojo-site/mojo/mojo-sandbox/webstart-maven-plugin/src/test/projects/project1/target/jar-mng-1130-0-1.0.zip to /home/jerome/.m2/repository-m2trunk/org/apache/maven/plugins/jar-mng-1130-0/1.0/jar-mng-1130-0-1.0.zip

I have some concerns with this patch:

• it seems to break a public API, in particular creating a dependence on maven 2.0.1 for the install plugin (though I can't see why as the install plugin is not changed)
• I don't understand the comment about omitting getArtifactHandler yet

it requires a closer look

Brett, thanks for looking into this.

I will try to be a little bit more verbose, first describing the patch then maybe a better approach.

The patch

• with regard to the pom dependencies updates, I think I've had to make the change for the maven-project dependency. The 2 others are probably not required.
  If I didn't upgrade maven-project to be 2.0.1-SNAPSHOT, tHe install package would keep using the 2.0 maven-project. That was failing in my plugin. I could maybe try forcing a dependency of 2.0.1-SNAPSHOT in my plugin.
• with regard to commenting out the getArtifactHandler(). The original getArtifactHandler() assumed that the super.artifactHandler was initialized by the parent.artifactHandler, thus the getArtifactHandler() would always return the same as parent.getArtifactHandler(). As my new constructor introduces its own ArtifactHandler instead of passing the parent.getArtifactHandler() to the super() constructor.this assumption is broken. I need to let the super return the real ArtifactHandler, known only by super. As to why the AttachedArtifact was overriding all these calls, I don't know. I would let the super provide this information or use delegation instead of inheritance.

Better approach?

It looks like AttachedArtifact is not correctly implemented.
1- delegation instead of inheritance?
2- do not add a new constructor but change the default AttachedArtifact to deal with the 2 broken cases initially reported in this bug report, i.e.:
1- support empty or null classifier
2- when the classifier is empty/null and the type different from the parent's type, use a different ArtifactHandler() with the correct type.

getArtifactHandler() must not be delegated to main artifact instance, either...

In a multi-module project, the ArtifactHandler extension only appears to be read from the extensions' components.xml for the first module.

i.e.

<modules>
<module>modules/module1-ext1</module>
<module>modules/module2-ext2</module>
</modules>

results in the custom artifact handler for module1-ext1 being used but not module2-ext2

Reversing this order

<modules>
<module>modules/module2-ext2</module>
<module>modules/module1-ext1</module>
</modules>

results in the custom artifact handler for module2-ext2 being used but not module1-ext1

changed the MavenProjectHelper to lookup and pass the proper ArtifactHandler to the AttachedArtifact constructor. Then, I changed the AttachedArtifact to only delegate those methods that need to be kept up to date WRT the main artifact. Wherever a method delegates instead of using its own data, I've disabled the corresponding setter method by throwing UnsupportedOperationException that has a message explaining why it's disabled.

patch was reviewed but not applied. The better approach was to make the attached artifact more independent, only delegating the identity-related fields (groupId, artifactId, version stuff) to the main artifact. The only reason to do this is to keep metadata lookups working consistently based on this info.

Also, I added code to MavenProjectHelper to lookup and pass on the correct ArtifactHandler for the given artifact type used for the attachment.

Thanks for the help on running this one down, Jerome (and everyone else who helped).

Thanks for fixing that one.
THere are at least one issue depending on that one: CC-1310. I thought there was a second, but I can't find it right now.
Should I try to refresh the patch on this issue, or should you take care of it?