[ 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