[
http://jira.codehaus.org/browse/MANTRUN-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MANTRUN-152.
-----------------------------
Resolution: Fixed
Fix Version/s: 1.6
Assignee: Paul Gier
Patch applied in
[r1003618|http://svn.apache.org/viewvc?view=revision&revision=1003618]. Thanks!
> Embedded task "attachartifact" does not work without classifier
> ---------------------------------------------------------------
>
> Key: MANTRUN-152
> URL: http://jira.codehaus.org/browse/MANTRUN-152
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
> Affects Versions: 1.3, 1.4, 1.5
> Environment: Java 5, Maven 2.2.1
> Reporter: Petr Kozelka
> Assignee: Paul Gier
> Fix For: 1.6
>
> Attachments: MANTRUN-attachartifact-unclassified.patch
>
>
> cause: use this task without specifying classifier attribute
> symptom: your file will not be copied to local repo during install phase
> h4. the bug
> The reason apparently is that this case has special handling in
> AttachArtifactTask.java, and this handling has following problems:
> - uses {{mavenProject.getArtifact().setFile( file );}} which apparently does
> not result in the artifact being considered the project artifact, neither
> being attached
> - even if it worked, this implementation would not work for multiple
> unclassified artifacts (the latest would always win)
> - the name "attachartifact" implies attaching, not declaring project artifact
> h4. a workarround
> Before this gets fixed, the workarround is to use
> http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
> as a subsequent mojo execution
> h4. the fix, patch contents
> The attached patch includes:
> # fix in code that just removes the conditionality for {{classifier==null}}
> -- _compatibility is IMHO not a problem, because this part was not working
> anyway_
> # integration test enhancement - to check the attachartifact functionality
> without classifier
> To see the incorrect behavior, just use the pom from integration test
> {{src/it/attach-artifact-test/pom.xml}} and remove the classifier artifact;
> the build log of that test will then show that the zip is really not copied
> by install mojo.
> h4. attached vs. Project artifact
> Concerning the (nonfunctional) attempt to declare the file as project
> artifact: IMHO it is not a good thing at all.
> Even if the abovementioned problem with overriding was solved, I would expect
> the task to do what its name indicates, and nothing else.
> Well, I am not aware of any important differences between having project
> artifact and having the same artifact as attached (I should read something
> about it...), but in any case, I would prefer to have some control over this
> different behavior.
> For instance, adding attribute {{projectArtifact="true"}} can indicate that
> setting project artifact is the desired action.
> Another approach, maybe even cleaner, would be to define a separate task (or
> better, configuration param) just for this purpose.
> h4. thoughts on merging build-helper approach
> What I really like about the embedded attachartifact task is, I don't need to
> *invoke separate mojo* (build-helper:attach-artifact).
> For me, creating something with ant piece and attaching it to project is the
> most common usecase of antrun plugin.
> Therefore I have the feeling that it should be treated specially - I mean,
> the way used in build-helper:attach-artifact mojo.
> Really, the "attaching" action is something different from normal tasks; it
> does not "do" anything visible to subsequent tasks, just enhances the
> internal declaration of the project... but we have POM for such things, right
> ?
> So, wouldn't it be better to *copy the functionality of
> build-helper:attach-artifact here ?* Perhaps the anttask attachartifact
> should still exist, for some rare cases like conditional/parameterized
> attachments; but the preferred way would be the (declarative) "maven" way -
> maybe this is worth separate issue.
--
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
