[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15346019#comment-15346019
]
Christofer Dutz commented on MPLUGIN-302:
-----------------------------------------
Sounds like this would be a huge improvement for not only supporting your
use-case, but also make supporting other scopes than the normal java ones for
other languages a lot easier.
I think one thing we would have to extend this by, is some mechanism to declare
how transitive dependencies are resolved for non-default scopes. Currently all
(compile) dependencies of non-default scopes are mapped to "runtime", making it
possible to extend the resolution strategy would be ha HUUUUUUUUGGGGEEEEE
improvement for supporting non-java applications (Flex, .Net, ...)
To me it wouldn't matter if I got a Map or a Collection. I guess the collection
would be enough and the Map would contain the dependency to ARTIFACTID-8 with a
key value of "8", am I correct? In that case I would vote for the Collection
solution, but make it match only the prefix before the ":" (If that's possible)
and for providing a utility method to convert that to a Map or to do some
filtering.
I would like to vote +10000 on this one ... just tell me how I can help make
this happen :-)
Chris
> Dependencies Annotation
> -----------------------
>
> Key: MPLUGIN-302
> URL: https://issues.apache.org/jira/browse/MPLUGIN-302
> Project: Maven Plugin Tools
> Issue Type: New Feature
> Components: API
> Reporter: Robert Scholte
> Attachments: dependencies-annotation.patch
>
>
> The goal of this Annotation is to remove all dependencies from the plugin
> configuration and to have custom scopes so they become part of the dependency
> resolution when Maven is creating a buildplan.
> {code:xml}
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.10.3</version>
> <configuration>
> <taglet>package.to.YourTagletClass</taglet>
> <tagletArtifact>
> <groupId>group-Taglet</groupId>
> <artifactId>artifact-Taglet</artifactId>
> <version>version-Taglet</version>
> </tagletArtifact>
> </configuration>
> </plugin>
> {code}
> This will become
> {code:xml}
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <version>2.10.3</version>
> <configuration>
> <taglet>package.to.YourTagletClass</taglet>
> </configuration>
> <dependencies>
> <dependeny>
> <groupId>group-Taglet</groupId>
> <artifactId>artifact-Taglet</artifactId>
> <version>version-Taglet</version>
> <scope>taglet</taglet>
> </dependency>
> </dependencies>
> </plugin>
> {code}
> Going further: there can be project dependencies which are not part of the
> classpath. One concrete example is the multirelease jar, where the newer
> implementation classes can be added to base jar. Current solution is to have
> a separate (distribution) Maven module which assembles the final jar, but
> with the solution above it is possible to embed them already when creating
> the base jar.
> This project would have the following dependencies:
> {code:xml}
> <dependencies>
> <dependency>
> <groupId>GROUPID</groupId>
> <artifactId>ARTIFACTID-7</artifactId>
> <scope>release:7</scope>
> </dependency>
> <dependency>
> <groupId>GROUPID</groupId>
> <artifactId>ARTIFACTID-8</artifactId>
> <scope>release:8</scope>
> </dependency>
> </dependencies>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map<String,Artifact> releaseArtifacts;
> // somewhere in the code
> foreach( Map.Entry releaseEntry : releaseArtifacts.entrySet() )
> {
> // copy content of release.value() to META-INF/versions/release.key()
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
