maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Gier (JIRA)" <>
Subject [jira] Closed: (MANTRUN-152) Embedded task "attachartifact" does not work without classifier
Date Fri, 01 Oct 2010 19:04:33 GMT


Paul Gier closed MANTRUN-152.

       Resolution: Fixed
    Fix Version/s: 1.6
         Assignee: Paul Gier

Patch applied in [r1003618|].

> Embedded task "attachartifact" does not work without classifier
> ---------------------------------------------------------------
>                 Key: MANTRUN-152
>                 URL:
>             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,
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
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:
For more information on JIRA, see:


View raw message