[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255263#comment-17255263
]
Christofer Dutz commented on MPLUGIN-302:
-
I still think this would be super useful ... Ok ... admittedly Flex is now
dead, so it won't benefit from such a feature, but for the Apache Royale
project it would be great. And in the PLC4X project for example we built our
code-generator maven plugin we mis-use the "provided" scope to provide the
input to the code generation. Having such labeled dependencies would help make
our hack a real solution.
> 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
>Priority: Major
> Labels: Maven5
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999376#comment-16999376
]
Robert Scholte commented on MPLUGIN-302:
This is something that should be scheduled for Maven 5. I'm still convinced
that all dependency-resolution should be done by Maven, and not inside
configuration. However, the current architecture doesn't alow that, so it'll
require a rewrite for some parts of Maven core.
> 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
>Priority: Major
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16999143#comment-16999143
]
Elliotte Rusty Harold commented on MPLUGIN-302:
---
scheduled for autoclose. Does anyone want to work on this, or should we resolve
that we're not going to do this?
> 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
>Priority: Major
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15368095#comment-15368095
]
Robert Scholte commented on MPLUGIN-302:
Both plugin annotations and doclettags result in a plugin.xml during packaging
for speed at runtime. The
[desciptor|https://maven.apache.org/ref/3.3.9/maven-plugin-api/plugin.html]
shows how parameters are resolved as well as requirements (à la the @Inject),
but here we need some kind of mapping for the dependencies too. Next step is
for Maven to read this and decide how to fill those Dependencies annotated
fields.
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15366229#comment-15366229
]
Christofer Dutz commented on MPLUGIN-302:
-
Ok so now I got machen checked out ... all the other stuff too and all is
building nicely. So I'm setup to get started on this. I added your patch. So
you say the Plugin Descriptor needs to be adjusted. But why? I thought that
contains the information about parameters the user is supposed to use to
configure the mojo. It doesn't seem to handle the injection of stuff like
components or dependencies. Could you elaborate a little on what you had in
mind here?
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15365861#comment-15365861
]
Christofer Dutz commented on MPLUGIN-302:
-
Ok ... so I checked out the code for maven as well as the maven-plugin-tools.
But unfortunately I can't seem to be able to see the files your patch addresses?
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356803#comment-15356803
]
Christofer Dutz commented on MPLUGIN-302:
-
We are currently finishing a 0.0.0.0.1 of Maven support in Flex so that's
currently consuming all of my time ... hope that will be done by the end of
this week ... as soon as we have the RC1, I'll start working on this.
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15355626#comment-15355626
]
Robert Scholte commented on MPLUGIN-302:
Yes, that's correct. I hope you only have to specify the scopes of the direct
dependencies, and those dependencies should 'know' which scopes of the
transitive dependencies should be included. This is a very good case to keep in
mind.
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15354804#comment-15354804
]
Christofer Dutz commented on MPLUGIN-302:
-
Currently Maven for example ignores the test depenedencies of a compile
dependency ... just as an example. There is some logic that implements the
mapping described here:
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
In order to support other scopes, I would need to be able to adjust this
mapping, which has to be implemented somewhere.
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15349662#comment-15349662
]
Robert Scholte commented on MPLUGIN-302:
I think that the result should always contain the transitive dependencies as
well, I can't think of a realistic usecase where you only want the now the
direct dependencies.
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15348018#comment-15348018
]
Christofer Dutz commented on MPLUGIN-302:
-
Would be a great opportunity for me to contribute. Especially as it would help
implementing Maven support for other tools a lot easier ... but only if there
was an option to also plugin to the transitive dependency resolution. Do you
have an Idea how this would have to be implemented?
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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15346991#comment-15346991
]
Robert Scholte commented on MPLUGIN-302:
The Map is for rare occasions, in general the Collection will be good enough.
In case of the multirelease jar I cannot predict if a dependency is the Java7
implementation or the Java8 implementation. With the {{release:}}-scope I know
these are all specific implementations, with the value I am able to map it to
the correct folder.
This patch contains the annotation I had in mind. Next step would be to support
this in the plugin descriptor. Third step is to make Maven understand it and
inject the right dependencies. So the next project to adjust would be
'maven-plugin-tools-generators'. I can make a branch for it if you want.
thanks for the help!
> 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
[jira] [Commented] (MPLUGIN-302) Dependencies Annotation
[
https://issues.apache.org/jira/browse/MPLUGIN-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 HE
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 +1 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}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
> group-Taglet
> artifact-Taglet
> version-Taglet
>
>
>
> {code}
> This will become
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.10.3
>
> package.to.YourTagletClass
>
>
>
> group-Taglet
> artifact-Taglet
> version-Taglet
> taglet
>
>
>
> {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}
>
>
> GROUPID
>ARTIFACTID-7
>release:7
>
>
> GROUPID
>ARTIFACTID-8
>release:8
>
>
> {code}
> In the maven-jar-plugin one would have something like:
> {code}
> @Dependecies( label="release" )
> Map 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)
