[ http://jira.codehaus.org/browse/MNG-1251?page=comments#action_49178 ]
Jerome Lacoste commented on MNG-1251:
-------------------------------------
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.
> attachArtifact doesn't allow to attach an artifact with different type and no
> assembly
> --------------------------------------------------------------------------------------
>
> Key: MNG-1251
> URL: http://jira.codehaus.org/browse/MNG-1251
> Project: Maven 2
> Type: Bug
> Components: maven-project
> Versions: 2.0
> Reporter: Jerome Lacoste
> Assignee: John Casey
> Priority: Blocker
> Fix For: 2.0.1
> Attachments: MNG-1251_more_flexible_attach_artifact.diff
>
>
> Use case: a project triggers a plugin which generates several files. I want
> to put all these files in a zip file and install it when calling install.
> So I bind my plugin to the package phase, I keep the project packaging as
> pom, and then i tri to do soemthing like projectHelper.attachArtifact(
> project, "zip", null, toFile ); in my execute() method
> this fails in 2 places:
> - empty or null classifier is disallowed by AttachedArtifact
> - then AttachedArtifact inherits the parent's ArtifactHandler which then will
> return "pom" as extension instead of "zip" (the type) .
> Thus my artifact ends up being installed in finalName-forcedClassifier.pom
> instead of finalName.zip...
> Blocks my webstart plugin development,
> Note that project.attachArtifact() looks empty...
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
