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.5, 1.4, 1.3
Environment: Java 5, Maven 2.2.1
Reporter: Petr Kozelka
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
