Re: Publishing to Maven Central and non-OSS plugin dependencies
The documentation for publishing to Central is very comprehensive. I suggest you take a closer look. Specifically https://central.sonatype.org/register/central-portal/ https://central.sonatype.org/publish/producer-terms/ https://repo1.maven.org/terms.html And maybe contact a lawyer and Sonatype if unclear. Manfred On 2/29/2024 8:44 PM, Stanimir Stamenkov wrote: Fri, 1 Mar 2024, /Olivier Lamy/: users will not be able to rebuild from sources. is it a requirement? No real idea as already said in this thread, you need to ask Sonatype. But it breaks the concept of opensource as you cannot build from the sources :) The sources uploaded to Maven Central are generally not sufficient for a rebuild. They are convenient for debugging and quick look up, however one almost always need to go to the project's website, and download full sources necessary for a complete build. The project's website could be just a source repository with a top-level README. I don't think Sonatype has or can have a requirement of "online project site available". There are older artifacts people still rely on, that may never be rebuilt because the original sites are long gone. Does it mean they should be removed from Maven Central, for example? I think it should be mainly up to the users to decide whether they want to use a particular artifact. As far as I'm aware there could be Free Open-source and Non-free Open-source. I don't know if complete build instructions are requirement for the latter, and Open-source in general? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Publishing to Maven Central and non-OSS plugin dependencies
Fri, 1 Mar 2024, /Olivier Lamy/: users will not be able to rebuild from sources. is it a requirement? No real idea as already said in this thread, you need to ask Sonatype. But it breaks the concept of opensource as you cannot build from the sources :) The sources uploaded to Maven Central are generally not sufficient for a rebuild. They are convenient for debugging and quick look up, however one almost always need to go to the project's website, and download full sources necessary for a complete build. The project's website could be just a source repository with a top-level README. I don't think Sonatype has or can have a requirement of "online project site available". There are older artifacts people still rely on, that may never be rebuilt because the original sites are long gone. Does it mean they should be removed from Maven Central, for example? I think it should be mainly up to the users to decide whether they want to use a particular artifact. As far as I'm aware there could be Free Open-source and Non-free Open-source. I don't know if complete build instructions are requirement for the latter, and Open-source in general? -- Stanimir - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Publishing to Maven Central and non-OSS plugin dependencies
users will not be able to rebuild from sources. is it a requirement? No real idea as already said in this thread, you need to ask Sonatype. But it breaks the concept of opensource as you cannot build from the sources :) On Fri, 1 Mar 2024 at 02:25, Florent Biville wrote: > > The real plugin is com.mycila:license-maven-plugin > <https://github.com/mathieucarbou/license-maven-plugin> and the non-OSS > dependency brings a bunch of extra resources (authorized licenses, > headers...). > > On Thu, Feb 29, 2024 at 2:14 PM Slawomir Jaranowski > wrote: > > > I can not fine mentioned plugin at all ... > > https://repo.maven.apache.org/maven2/com/acme/ > > > > What does it do ...? > > Is it needed for the build project? > > Can it be executed in profile? > > Can it be replaced by something else ...? > > > > I will think about publishing projects which can not be build by outer > > users, can not be a reproducible build check and so on ... > > > > So I would like to not publish something like this... > > > > > > > > czw., 29 lut 2024 o 13:41 Florent Biville > > napisał(a): > > > > > Yes, to clarify, our project has something like this: > > > > > > > > > com.acme.plugin > > > plugin > > > 4.2.42 > > > > > > > > > com.acme.plugin > > > plugin-dep > > > 42.4.2 > > > > > > > > > > > > > > > > > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák > > > wrote: > > > > > > > Howdy, > > > > > > > > You would need to ask Sonatype about that, and check here: > > > > https://central.sonatype.org/publish/requirements/ > > > > > > > > IMHO best to ask them about it: IIUC you want to deploy artifacts to > > > > central that has dependencies not available from Central > > > > (nor any other public repository?) > > > > > > > > Thanks > > > > T > > > > > > > > > > > > > > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville < > > > florent.bivi...@gmail.com > > > > > > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I'm working on an open-source project that we want to release to > > Maven > > > > > Central in the coming weeks. > > > > > > > > > > The project currently includes a plugin dependency that is NOT > > > > open-source > > > > > (nor in a public GitHub repository). Is that a blocker for releases > > to > > > > > Maven Central? I know it would be for regular dependencies and > > plugins, > > > > but > > > > > I'm not 100% sure about plugin dependencies in particular (although I > > > > would > > > > > guess it's the same). > > > > > > > > > > Any input would be appreciated, > > > > > > > > > > Best regards, > > > > > Florent > > > > > > > > > > > > > > > > > > -- > > Sławomir Jaranowski > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Publishing to Maven Central and non-OSS plugin dependencies
The real plugin is com.mycila:license-maven-plugin <https://github.com/mathieucarbou/license-maven-plugin> and the non-OSS dependency brings a bunch of extra resources (authorized licenses, headers...). On Thu, Feb 29, 2024 at 2:14 PM Slawomir Jaranowski wrote: > I can not fine mentioned plugin at all ... > https://repo.maven.apache.org/maven2/com/acme/ > > What does it do ...? > Is it needed for the build project? > Can it be executed in profile? > Can it be replaced by something else ...? > > I will think about publishing projects which can not be build by outer > users, can not be a reproducible build check and so on ... > > So I would like to not publish something like this... > > > > czw., 29 lut 2024 o 13:41 Florent Biville > napisał(a): > > > Yes, to clarify, our project has something like this: > > > > > > com.acme.plugin > > plugin > > 4.2.42 > > > > > > com.acme.plugin > > plugin-dep > > 42.4.2 > > > > > > > > > > > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > You would need to ask Sonatype about that, and check here: > > > https://central.sonatype.org/publish/requirements/ > > > > > > IMHO best to ask them about it: IIUC you want to deploy artifacts to > > > central that has dependencies not available from Central > > > (nor any other public repository?) > > > > > > Thanks > > > T > > > > > > > > > > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville < > > florent.bivi...@gmail.com > > > > > > > wrote: > > > > > > > Hello, > > > > > > > > I'm working on an open-source project that we want to release to > Maven > > > > Central in the coming weeks. > > > > > > > > The project currently includes a plugin dependency that is NOT > > > open-source > > > > (nor in a public GitHub repository). Is that a blocker for releases > to > > > > Maven Central? I know it would be for regular dependencies and > plugins, > > > but > > > > I'm not 100% sure about plugin dependencies in particular (although I > > > would > > > > guess it's the same). > > > > > > > > Any input would be appreciated, > > > > > > > > Best regards, > > > > Florent > > > > > > > > > > > > -- > Sławomir Jaranowski >
Re: Publishing to Maven Central and non-OSS plugin dependencies
I can not fine mentioned plugin at all ... https://repo.maven.apache.org/maven2/com/acme/ What does it do ...? Is it needed for the build project? Can it be executed in profile? Can it be replaced by something else ...? I will think about publishing projects which can not be build by outer users, can not be a reproducible build check and so on ... So I would like to not publish something like this... czw., 29 lut 2024 o 13:41 Florent Biville napisał(a): > Yes, to clarify, our project has something like this: > > > com.acme.plugin > plugin > 4.2.42 > > > com.acme.plugin > plugin-dep > 42.4.2 > > > > > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák > wrote: > > > Howdy, > > > > You would need to ask Sonatype about that, and check here: > > https://central.sonatype.org/publish/requirements/ > > > > IMHO best to ask them about it: IIUC you want to deploy artifacts to > > central that has dependencies not available from Central > > (nor any other public repository?) > > > > Thanks > > T > > > > > > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville < > florent.bivi...@gmail.com > > > > > wrote: > > > > > Hello, > > > > > > I'm working on an open-source project that we want to release to Maven > > > Central in the coming weeks. > > > > > > The project currently includes a plugin dependency that is NOT > > open-source > > > (nor in a public GitHub repository). Is that a blocker for releases to > > > Maven Central? I know it would be for regular dependencies and plugins, > > but > > > I'm not 100% sure about plugin dependencies in particular (although I > > would > > > guess it's the same). > > > > > > Any input would be appreciated, > > > > > > Best regards, > > > Florent > > > > > > -- Sławomir Jaranowski
Re: Publishing to Maven Central and non-OSS plugin dependencies
(I’m just a Maven user) It seems that, for consuming the artifact, the closed-source plugin seems not a dependency. I believe it just works fine. Your company’s support team might get questions like “I tried to build your library myself but the build failed.” Maven has a capability to replace pom.xml content when packaging a project. The flatten Maven plugin uses it https://www.mojohaus.org/flatten-maven-plugin/ . Regards, Tomo On Thu, Feb 29, 2024 at 07:40 Florent Biville wrote: > Yes, to clarify, our project has something like this: > > > com.acme.plugin > plugin > 4.2.42 > > > com.acme.plugin > plugin-dep > 42.4.2 > > > > > > On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák > wrote: > > > Howdy, > > > > You would need to ask Sonatype about that, and check here: > > https://central.sonatype.org/publish/requirements/ > > > > IMHO best to ask them about it: IIUC you want to deploy artifacts to > > central that has dependencies not available from Central > > (nor any other public repository?) > > > > Thanks > > T > > > > > > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville < > florent.bivi...@gmail.com > > > > > wrote: > > > > > Hello, > > > > > > I'm working on an open-source project that we want to release to Maven > > > Central in the coming weeks. > > > > > > The project currently includes a plugin dependency that is NOT > > open-source > > > (nor in a public GitHub repository). Is that a blocker for releases to > > > Maven Central? I know it would be for regular dependencies and plugins, > > but > > > I'm not 100% sure about plugin dependencies in particular (although I > > would > > > guess it's the same). > > > > > > Any input would be appreciated, > > > > > > Best regards, > > > Florent > > > > > >
Re: Publishing to Maven Central and non-OSS plugin dependencies
Yes, to clarify, our project has something like this: com.acme.plugin plugin 4.2.42 com.acme.plugin plugin-dep 42.4.2 On Thu, Feb 29, 2024 at 1:33 PM Tamás Cservenák wrote: > Howdy, > > You would need to ask Sonatype about that, and check here: > https://central.sonatype.org/publish/requirements/ > > IMHO best to ask them about it: IIUC you want to deploy artifacts to > central that has dependencies not available from Central > (nor any other public repository?) > > Thanks > T > > > > On Thu, Feb 29, 2024 at 1:31 PM Florent Biville > > wrote: > > > Hello, > > > > I'm working on an open-source project that we want to release to Maven > > Central in the coming weeks. > > > > The project currently includes a plugin dependency that is NOT > open-source > > (nor in a public GitHub repository). Is that a blocker for releases to > > Maven Central? I know it would be for regular dependencies and plugins, > but > > I'm not 100% sure about plugin dependencies in particular (although I > would > > guess it's the same). > > > > Any input would be appreciated, > > > > Best regards, > > Florent > > >
Re: Publishing to Maven Central and non-OSS plugin dependencies
Howdy, You would need to ask Sonatype about that, and check here: https://central.sonatype.org/publish/requirements/ IMHO best to ask them about it: IIUC you want to deploy artifacts to central that has dependencies not available from Central (nor any other public repository?) Thanks T On Thu, Feb 29, 2024 at 1:31 PM Florent Biville wrote: > Hello, > > I'm working on an open-source project that we want to release to Maven > Central in the coming weeks. > > The project currently includes a plugin dependency that is NOT open-source > (nor in a public GitHub repository). Is that a blocker for releases to > Maven Central? I know it would be for regular dependencies and plugins, but > I'm not 100% sure about plugin dependencies in particular (although I would > guess it's the same). > > Any input would be appreciated, > > Best regards, > Florent >
Publishing to Maven Central and non-OSS plugin dependencies
Hello, I'm working on an open-source project that we want to release to Maven Central in the coming weeks. The project currently includes a plugin dependency that is NOT open-source (nor in a public GitHub repository). Is that a blocker for releases to Maven Central? I know it would be for regular dependencies and plugins, but I'm not 100% sure about plugin dependencies in particular (although I would guess it's the same). Any input would be appreciated, Best regards, Florent
Re: Dependency plugin unpack plugin dependencies
Hi Alexander, this is an old thread, but no one has replied yet. While I think this is possible – what are you trying to achieve? Or in other words: WHY do you need the dependencies unpacked? What do you do with them? Regards, Ben On 2020/08/19 18:23:06, Alexander Broekhuis wrote: > Hi all, > > I currently have a setup in which I have some custom artifacts that I use > as dependencies and unpack using unpack-dependencies. > This all works great, but now I also have a custom plugin which needs one > of the custom artifacts as dependency. I don't see those dependencies being > unpacked. Is this correct, or am I doing something wrong? > > I know I can add the dependency as "regular" dependency as workaround, but > I'd like to be able to define the plugin in a parent's pluginManagement > with it's dependencies so that dependant project can enable the plugin when > needed without having to define the dependency, or always have it being > unpacked even if not needed. > > Basically my pom looks like this (meta): > > // Those are unpacked as expected > > > > > // Those dependencies are not unpacked > > > > > > > > > -- > Met vriendelijke groet, > > Alexander Broekhuis > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Dependency plugin unpack plugin dependencies
Hi all, I currently have a setup in which I have some custom artifacts that I use as dependencies and unpack using unpack-dependencies. This all works great, but now I also have a custom plugin which needs one of the custom artifacts as dependency. I don't see those dependencies being unpacked. Is this correct, or am I doing something wrong? I know I can add the dependency as "regular" dependency as workaround, but I'd like to be able to define the plugin in a parent's pluginManagement with it's dependencies so that dependant project can enable the plugin when needed without having to define the dependency, or always have it being unpacked even if not needed. Basically my pom looks like this (meta): // Those are unpacked as expected // Those dependencies are not unpacked -- Met vriendelijke groet, Alexander Broekhuis
Re: Project dependencies vs plugin dependencies for a mojo looking at the project
Karl Heinz Marbaise-3 wrote
>>I thought I could just enter it once as a plugin dependency in
>> the user project pom - assuming it would be the only one.
>
> You can give this via the plugin configuration and which means your
> plugin must resolve it's dependencies and make a required download for
> it...which can be easily done by using a maven-artifact-transfer[3].
>
> [3]:
> https://maven.apache.org/shared/maven-artifact-transfer/install-project.html
I wasn't able to get the maven-artifact-transfer to function in my mojo. I
resorted to Aether's RepositorySystem.resolveArtifact() method.
Karl Heinz Marbaise-3 wrote
Presumably I call something like
project.getPlugin(key).getDependencies()?
If the 'key' required for project.getPlugin(key) is of the form
myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2
can I get my mojo's own key programmatically in the mojo to avoid
hard-coding it?
This is the last issue I'm facing (famous last words.)
I currently hard-code my plugin's key so I can obtain it while the mojo is
in action:
Plugin plugin = project.getPlugin("com.megacorp.stuff:my-plugin");
plugin.getDependencies()..
but I'd like to avoid that in case my successor decides to rename it or
something similar.
How can I the key programmatically, by reaching deep into the mojo?
Regards
Adam
--
Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Project dependencies vs plugin dependencies for a mojo looking at the project
The users of my plugin define a dependency which the mojo unpacks and extracts certain files from. You know that such a plugin already exists? maven-dependency-plugin:unpack / unpack-dependencies ? https://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html I knew one must exist, but I hadn't looked at the docs - interesting. The reason why I wrote it myself was to try to avoid the duplication of configuration items, to try to keep it succinct. Otherwise the user would have to enter the desired file names twice (or more) - once to extract it, and again to feed it into the next mojo where the file contents are used. Furthermore the question is why do you need only certain files from it ? It's a shared configuration file archive used by several projects. Not the greatest idea, I know. You can give this via the plugin configuration and which means your plugin must resolve it's dependencies and make a required download for it...which can be easily done by using a maven-artifact-transfer[3]. [3]: https://maven.apache.org/shared/maven-artifact-transfer/install-project.html Yes, true, but to try to keep it all succinct and intuitive, I figured it is best to make it a real dependency from the XML point-of-view. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project dependencies vs plugin dependencies for a mojo looking at the project
Hi, On 13/09/17 23:29, Adam Hardy wrote: On 12/09/17 18:05, Adam Hardy wrote: when I'm coding a mojo, if I call MavenProject's getArtifacts(), I can only get artifacts from the project level dependencies. How do I obtain artifacts from a plugin's dependencies? The question which comes to my mind: Why do you need the dependencies of your own ? Aren't the defined in your plugin's pom ? Maybe I misunderstand a thing here? Presumably I call something like project.getPlugin(key).getDependencies()? If the 'key' required for project.getPlugin(key) is of the form myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2 can I get my mojo's own key programmatically in the mojo to avoid hard-coding it? Can you please explain what you are trying to accomplish ? The users of my plugin define a dependency which the mojo unpacks and extracts certain files from. You know that such a plugin already exists? maven-dependency-plugin:unpack / unpack-dependencies ? https://maven.apache.org/plugins/maven-dependency-plugin/examples/unpacking-artifacts.html Furthermore the question is why do you need only certain files from it ? At the moment, I have coded the plugin to take the groupId and artifactId of this dependency via the mojo config. Sounds good so far...so counting one place... something like this. ... .. .. .. Group to be unpacked artifact of being upackage ... This strikes me as doppel gemoppelt I assume you mean duplicated ? ( I understand that; But only a few people here on the list have german background). for the user to put that info in twice. >I thought I could just enter it once as a plugin dependency in the user project pom - assuming it would be the only one. What do you think will the usage as plugin depenency change ? You can give this via the plugin configuration and which means your plugin must resolve it's dependencies and make a required download for it...which can be easily done by using a maven-artifact-transfer[3]. But I don't see the requirement to define it in two place ? Kind regards Karl Heinz Marbaise [1]: https://maven.apache.org/plugins/maven-dependency-plugin/unpack-mojo.html [2]: https://maven.apache.org/plugins/maven-dependency-plugin/unpack-dependencies-mojo.html [3]: https://maven.apache.org/shared/maven-artifact-transfer/install-project.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project dependencies vs plugin dependencies for a mojo looking at the project
On 12/09/17 18:05, Adam Hardy wrote: when I'm coding a mojo, if I call MavenProject's getArtifacts(), I can only get artifacts from the project level dependencies. How do I obtain artifacts from a plugin's dependencies? The question which comes to my mind: Why do you need the dependencies of your own ? Aren't the defined in your plugin's pom ? Maybe I misunderstand a thing here? Presumably I call something like project.getPlugin(key).getDependencies()? If the 'key' required for project.getPlugin(key) is of the form myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2 can I get my mojo's own key programmatically in the mojo to avoid hard-coding it? Can you please explain what you are trying to accomplish ? The users of my plugin define a dependency which the mojo unpacks and extracts certain files from. At the moment, I have coded the plugin to take the groupId and artifactId of this dependency via the mojo config. This strikes me as doppel gemoppelt for the user to put that info in twice. I thought I could just enter it once as a plugin dependency in the user project pom - assuming it would be the only one. Regards Adam - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Project dependencies vs plugin dependencies for a mojo looking at the project
Hi Adam, On 12/09/17 18:05, Adam Hardy wrote: Hi, when I'm coding a mojo, if I call MavenProject's getArtifacts(), I can only get artifacts from the project level dependencies. How do I obtain artifacts from a plugin's dependencies? The question which comes to my mind: Why do you need the dependencies of your own ? Aren't the defined in your plugin's pom ? Maybe I misunderstand a thing here? Presumably I call something like project.getPlugin(key).getDependencies()? If the 'key' required for project.getPlugin(key) is of the form myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2 can I get my mojo's own key programmatically in the mojo to avoid hard-coding it? Can you please explain what you are trying to accomplish ? Thanks Adam Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Project dependencies vs plugin dependencies for a mojo looking at the project
Hi, when I'm coding a mojo, if I call MavenProject's getArtifacts(), I can only get artifacts from the project level dependencies. How do I obtain artifacts from a plugin's dependencies? Presumably I call something like project.getPlugin(key).getDependencies()? If the 'key' required for project.getPlugin(key) is of the form myGroup:myPlugin:version e.g. com.megacorp:thing-plugin:1.0.2 can I get my mojo's own key programmatically in the mojo to avoid hard-coding it? Thanks Adam
How to run dependency:unpack-dependencies for plugin dependencies?
Hi, I have an issue I am not able to find an answer to. How do I configure *dependency:unpack-dependencies* to process dependencies declared inside the section? There are three artifacts in this story: "product", "plugin" and "compiler". - "Plugin" depends on a "compiler" of a particular version. - In order to create "product", I need to download "plugin", its "compiler" and unpack them (they contain binaries I need to run) - The usage of "product" should not depend on "plugin", therefore I declared dependency on it inside the section. The plugin (and compiler) are only needed to build the artifact, not to use it. The problem is that it seems the *dependency:unpack-dependencies* Maven plugin only looks for project dependencies, not plugin dependencies. *dependency:unpack* is able to unpack a plugin dependency, but I need to explicitly state its GAVC, which I do not know (for the transitive dependency - compiler). Detailed question on SO is here: http://stackoverflow.com/questions/37304236/maven-unpack-dependencies-of-a-plugin-dependency Thank you all -- *Martin Melka *| *Junior Release Engineer* *AVAST Software s.r.o.* | Budějovická 1518/13a | 140 00 Praha 4 *M* +420 721 113 324 *E* me...@avast.com | *W* www.avast.com
AW: Plugin dependencies to artifacts of the same build?
Ok ... so I did some more debugging ... I output the classpath and it seemed to contain the jar containing the class I tried to load. So I took the urls of the existing Classloader and created a new Instance with exactly this set of URLs and I was able to load the class. Is is possible that Maven can have problems with classloaders if the JARs it contains are replaced during the build? I did encounter similar problems with other builds and they always occur if I load classes in plugins that have been built as part of the build. Is there a way to avoid this type of problem? Chris Von: Christofer Dutz Gesendet: Dienstag, 29. März 2016 19:14 An: users@maven.apache.org Betreff: AW: Plugin dependencies to artifacts of the same build? Sorry ... that email went off unintentionally ... well to continue ... if the plugin is part of the reactor: --- constituent[0]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-api-1.0.2.v20150114.jar constituent[1]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-connector-basic-1.0.2.v20150114.jar constituent[2]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-impl-1.0.2.v20150114.jar constituent[3]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-spi-1.0.2.v20150114.jar constituent[4]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-transport-wagon-1.0.2.v20150114.jar constituent[5]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aether-util-1.0.2.v20150114.jar constituent[6]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/aopalliance-1.0.jar constituent[7]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/cdi-api-1.0.jar constituent[8]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/commons-cli-1.2.jar constituent[9]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/commons-io-2.2.jar constituent[10]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/commons-lang-2.6.jar constituent[11]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/guava-18.0.jar constituent[12]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/javax.inject-1.jar constituent[13]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/jsoup-1.7.2.jar constituent[14]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/jsr250-api-1.0.jar constituent[15]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-aether-provider-3.3.3.jar constituent[16]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-artifact-3.3.3.jar constituent[17]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-builder-support-3.3.3.jar constituent[18]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-compat-3.3.3.jar constituent[19]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-core-3.3.3.jar constituent[20]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-embedder-3.3.3.jar constituent[21]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-model-3.3.3.jar constituent[22]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-model-builder-3.3.3.jar constituent[23]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-plugin-api-3.3.3.jar constituent[24]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-repository-metadata-3.3.3.jar constituent[25]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-settings-3.3.3.jar constituent[26]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/maven-settings-builder-3.3.3.jar constituent[27]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/org.eclipse.sisu.inject-0.3.0.jar constituent[28]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/org.eclipse.sisu.plexus-0.3.0.jar constituent[29]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-cipher-1.7.jar constituent[30]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-component-annotations-1.5.5.jar constituent[31]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-interpolation-1.21.jar constituent[32]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-sec-dispatcher-1.3.jar constituent[33]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/plexus-utils-3.0.20.jar constituent[34]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/sisu-guice-3.2.5-no_aop.jar constituent[35]: file:/Users/christoferdutz/Devtools/Apache/apache-maven-3.3.3/lib/slf4j-api-1.7.5.jar constituent[36]: file:/Users/christoferdutz/Devtools
AW: Plugin dependencies to artifacts of the same build?
0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jx/0.6.0-SNAPSHOT/compiler-jx-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler/0.6.0-SNAPSHOT/compiler-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jburg-types/0.6.0-SNAPSHOT/compiler-jburg-types-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar /Users/christoferdutz/Maven-Repository/org/antlr/antlr/3.3/antlr-3.3.jar /Users/christoferdutz/Maven-Repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar /Users/christoferdutz/Maven-Repository/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar /Users/christoferdutz/Maven-Repository/antlr/antlr/2.7.7/antlr-2.7.7.jar /Users/christoferdutz/Maven-Repository/com/google/guava/guava/18.0/guava-18.0.jar /Users/christoferdutz/Maven-Repository/net/sourceforge/jburg/jburg/1.10.3/jburg-1.10.3.jar /Users/christoferdutz/Maven-Repository/de/jflex/jflex/1.6.0/jflex-1.6.0.jar /Users/christoferdutz/Maven-Repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar /Users/christoferdutz/Maven-Repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar /Users/christoferdutz/Maven-Repository/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar /Users/christoferdutz/Maven-Repository/args4j/args4j/2.0.28/args4j-2.0.28.jar /Users/christoferdutz/Maven-Repository/org/codeartisans/org.json/20131017/org.json-20131017.jar /Users/christoferdutz/Maven-Repository/com/google/javascript/closure-compiler/v20151015/closure-compiler-v20151015.jar /Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library/0.0-20150902-b129bb9e/google-closure-library-0.0-20150902-b129bb9e.jar /Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library-third-party/0.0-20150902-b129bb9e/google-closure-library-third-party-0.0-20150902-b129bb9e.jar Can anyone here explain why? Chris Von: Christofer Dutz Gesendet: Dienstag, 29. März 2016 19:13 An: users@maven.apache.org Betreff: AW: Plugin dependencies to artifacts of the same build? So I added some code to dump the threads context classpath during the execution of the plugin: If I execute everything without the plugin being part of the reactor, I get this: [INFO] --- flexjs-maven-plugin:0.6.0-SNAPSHOT:generate (default-generate) @ flexjs-externs-js --- Classpath - /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/flexjs-maven-plugin/0.6.0-SNAPSHOT/flexjs-maven-plugin-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jx/0.6.0-SNAPSHOT/compiler-jx-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler/0.6.0-SNAPSHOT/compiler-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jburg-types/0.6.0-SNAPSHOT/compiler-jburg-types-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar /Users/christoferdutz/Maven-Repository/org/antlr/antlr/3.3/antlr-3.3.jar /Users/christoferdutz/Maven-Repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar /Users/christoferdutz/Maven-Repository/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar /Users/christoferdutz/Maven-Repository/antlr/antlr/2.7.7/antlr-2.7.7.jar /Users/christoferdutz/Maven-Repository/com/google/guava/guava/18.0/guava-18.0.jar /Users/christoferdutz/Maven-Repository/net/sourceforge/jburg/jburg/1.10.3/jburg-1.10.3.jar /Users/christoferdutz/Maven-Repository/de/jflex/jflex/1.6.0/jflex-1.6.0.jar /Users/christoferdutz/Maven-Repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar /Users/christoferdutz/Maven-Repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar /Users/christoferdutz/Maven-Repository/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar /Users/christoferdutz/Maven-Repository/args4j/args4j/2.0.28/args4j-2.0.28.jar /Users/christoferdutz/Maven-Repository/org/codeartisans/org.json/20131017/org.json-20131017.jar /Users/christoferdutz/Maven-Repository/com/google/javascript/closure-compiler/v20151015/closure-compiler-v20151015.jar /Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library/0.0-20150902-b129bb9e/google-closure-library-0.0-20150902-b129bb9e.jar /Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library-third-party/0.0-20150902-b129bb9e/google-closure-library-third-party-0.0-20150902-b129bb9e.jar /Users/christoferdutz/Maven-Repository/org/sonatype/aether/aether-util/1.13.1/aether-util-1.13.1.jar /Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-inject-bean/2.3.0/sisu-inject-bean-2.3.0.jar /Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar /Users/christoferdutz/Maven-Repository/org/codehaus/plexus/p
AW: Plugin dependencies to artifacts of the same build?
So I added some code to dump the threads context classpath during the execution of the plugin: If I execute everything without the plugin being part of the reactor, I get this: [INFO] --- flexjs-maven-plugin:0.6.0-SNAPSHOT:generate (default-generate) @ flexjs-externs-js --- Classpath - /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/flexjs-maven-plugin/0.6.0-SNAPSHOT/flexjs-maven-plugin-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jx/0.6.0-SNAPSHOT/compiler-jx-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler/0.6.0-SNAPSHOT/compiler-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flexjs/compiler/compiler-jburg-types/0.6.0-SNAPSHOT/compiler-jburg-types-0.6.0-SNAPSHOT.jar /Users/christoferdutz/Maven-Repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar /Users/christoferdutz/Maven-Repository/org/antlr/antlr/3.3/antlr-3.3.jar /Users/christoferdutz/Maven-Repository/org/antlr/antlr-runtime/3.3/antlr-runtime-3.3.jar /Users/christoferdutz/Maven-Repository/org/antlr/stringtemplate/3.2.1/stringtemplate-3.2.1.jar /Users/christoferdutz/Maven-Repository/antlr/antlr/2.7.7/antlr-2.7.7.jar /Users/christoferdutz/Maven-Repository/com/google/guava/guava/18.0/guava-18.0.jar /Users/christoferdutz/Maven-Repository/net/sourceforge/jburg/jburg/1.10.3/jburg-1.10.3.jar /Users/christoferdutz/Maven-Repository/de/jflex/jflex/1.6.0/jflex-1.6.0.jar /Users/christoferdutz/Maven-Repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar /Users/christoferdutz/Maven-Repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar /Users/christoferdutz/Maven-Repository/org/b1/pack/lzma-sdk-4j/9.22.0/lzma-sdk-4j-9.22.0.jar /Users/christoferdutz/Maven-Repository/args4j/args4j/2.0.28/args4j-2.0.28.jar /Users/christoferdutz/Maven-Repository/org/codeartisans/org.json/20131017/org.json-20131017.jar /Users/christoferdutz/Maven-Repository/com/google/javascript/closure-compiler/v20151015/closure-compiler-v20151015.jar /Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library/0.0-20150902-b129bb9e/google-closure-library-0.0-20150902-b129bb9e.jar /Users/christoferdutz/Maven-Repository/org/clojure/google-closure-library-third-party/0.0-20150902-b129bb9e/google-closure-library-third-party-0.0-20150902-b129bb9e.jar /Users/christoferdutz/Maven-Repository/org/sonatype/aether/aether-util/1.13.1/aether-util-1.13.1.jar /Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-inject-bean/2.3.0/sisu-inject-bean-2.3.0.jar /Users/christoferdutz/Maven-Repository/org/sonatype/sisu/sisu-guice/3.1.0/sisu-guice-3.1.0-no_aop.jar /Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar /Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar /Users/christoferdutz/Maven-Repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar /Users/christoferdutz/Maven-Repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar /Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-compiler-api/2.2/plexus-compiler-api-2.2.jar /Users/christoferdutz/Maven-Repository/commons-io/commons-io/2.4/commons-io-2.4.jar /Users/christoferdutz/Maven-Repository/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.jar /Users/christoferdutz/Maven-Repository/org/codehaus/plexus/plexus-utils/3.0.3/plexus-utils-3.0.3.jar /Users/christoferdutz/Maven-Repository/org/apache/flex/flex-tool-api/1.0.0/flex-tool-api-1.0.0.jar - In case the plugin is part of the reactor, the list looks like this: Von: Christofer Dutz Gesendet: Dienstag, 29. März 2016 16:14 An: users@maven.apache.org Betreff: Plugin dependencies to artifacts of the same build? Hi, I am currently trying to sort out some glitches in my Maven build. I am working on a new flexjs-maven-plugin as part of my efforts to migrate more and more of the Apache Flex project to Maven. In the reactor I have a a compiler, a maven-plugin providing a custom lifecycle mapping for FlexJS projects, and a set of libraries that are built using the maven-plugin and the compiler (Let's call them "framework"). The maven plugin uses an externally released API to decouple the plugin from the compiler. I know that if you start from scratch, Maven will abort with an error message as the maven plugin does not exist and it needs that for the framework. For this reason I have a "minimal" profile that simply builds the maven plugin. So ideally you only have to build once with the "minimal" profile and then you can go back to the "default" profile, which builds everything (I know th
Plugin dependencies to artifacts of the same build?
Hi, I am currently trying to sort out some glitches in my Maven build. I am working on a new flexjs-maven-plugin as part of my efforts to migrate more and more of the Apache Flex project to Maven. In the reactor I have a a compiler, a maven-plugin providing a custom lifecycle mapping for FlexJS projects, and a set of libraries that are built using the maven-plugin and the compiler (Let's call them "framework"). The maven plugin uses an externally released API to decouple the plugin from the compiler. I know that if you start from scratch, Maven will abort with an error message as the maven plugin does not exist and it needs that for the framework. For this reason I have a "minimal" profile that simply builds the maven plugin. So ideally you only have to build once with the "minimal" profile and then you can go back to the "default" profile, which builds everything (I know this is not ideal, but I haven't come across a solution that would not have me split up everything into completely separate Projects ... anyway ... my problem is not directly related to this problem) If building everything in one big build I get ClassNotFound exceptions from the Maven-Plugin complaining the compiler classes not being available, if however I build only the framework all is good. So I am guessing that if Maven starts building and a plugin references a library that is re-built prior to it's usage inside the same build, the jar is no longer available. Why is that the case? ... Flexmojos (another plugin I have been maintaining for years now) relies heavily on this and It must have been working prior to my new plugin. I am using Maven 3.3.3 and Oracle Java 1.7 Chris
Re: How to get a dependency tree view of plugin dependencies used in the build
Yeah I did try dependency:resolve-plugins but that just shows the first level dependencies not what I needed. Seems like this would be a very useful goal to add to dependency plugin. -Dave On Wed, Sep 10, 2014 at 1:13 PM, Baptiste Mathus wrote: > Found that, seems to match your question: > http://stackoverflow.com/a/7079876/345845. > > Karl-Heinz is everywhere :-). > > 2014-09-10 16:50 GMT+02:00 David Hoffer : > > > Similar to dependency:tree for project dependencies how can I get a > similar > > list of plugin dependencies used in the build? > > > > -Dave > > > > -- > > Baptiste MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! nbsp;! >
Re: How to get a dependency tree view of plugin dependencies used in the build
Found that, seems to match your question: http://stackoverflow.com/a/7079876/345845. Karl-Heinz is everywhere :-). 2014-09-10 16:50 GMT+02:00 David Hoffer : > Similar to dependency:tree for project dependencies how can I get a similar > list of plugin dependencies used in the build? > > -Dave > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! nbsp;!
How to get a dependency tree view of plugin dependencies used in the build
Similar to dependency:tree for project dependencies how can I get a similar list of plugin dependencies used in the build? -Dave
Re: Custom plugin dependencies
In fact 1.1 is only on my machine. I installed it from source. Anyway, I went back to 1.0 and the same results. However, it's working now, as I just had to add ant. On Sun, Jul 27, 2014 at 8:33 AM, Thomas Sundberg wrote: > On 27 July 2014 12:02, Mansour Al Akeel wrote: >> Thomas, >> Thank you for the fast response. Unfortunately this is not the case. >> I have generate a maven plugin project from the archetype, and add: >> >> >> org.apache.ddlutils >> ddlutils >> 1.1 >> >> > > Interesting, when I search for the artifact you declare above at > http://search.maven.org I can only find version 1.0, not version 1.1 > > What happens if you declare version 1.0? > >> >> I added the import statement to my Mojo: >> >> import org.apache.ddlutils.task.DdlToDatabaseTask; >> >> and declare it: >> >> private DdlToDatabaseTask ddlToDatabaseTask; >> >> >> Now when I do: >> >> mvn install >> and try to run the Mojo, I get >> >> java.lang.NoClassDefFoundError: org/apache/tools/ant/Task >> >> So I am wondering, how to make this library available to the plugin ? >> > > You could consider adding a dependency in your project to the Ant plugin. > > Search at Central Repository and see what you can find. > > /Thomas > > >> >> On Sun, Jul 27, 2014 at 5:10 AM, Thomas Sundberg wrote: >>> On 27 July 2014 10:05, Mansour Al Akeel wrote: I am writing a custom plug in. This plugin has other dependencies. How can I make these dependencies available when running the plugin without having to add them manually ?? >>> >>> I assume that your dependencies are declared in your plugin project. >>> If they are, then they will be downloaded and made available >>> automatically by Maven. >>> >>> /Thomas >>> >>> -- >>> Thomas Sundberg >>> M. Sc. in Computer Science >>> >>> Mobile: +46 70 767 33 15 >>> Blog: http://thomassundberg.wordpress.com/ >>> Twitter: @thomassundberg >>> >>> Better software through faster feedback >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > > > -- > Thomas Sundberg > M. Sc. in Computer Science > > Mobile: +46 70 767 33 15 > Blog: http://thomassundberg.wordpress.com/ > Twitter: @thomassundberg > > Better software through faster feedback > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom plugin dependencies
Issue resolve. My bad. I had to explicitly include ant dependency. On Sun, Jul 27, 2014 at 6:02 AM, Mansour Al Akeel wrote: > Thomas, > Thank you for the fast response. Unfortunately this is not the case. > I have generate a maven plugin project from the archetype, and add: > > > org.apache.ddlutils > ddlutils > 1.1 > > > I added the import statement to my Mojo: > > import org.apache.ddlutils.task.DdlToDatabaseTask; > > and declare it: > > private DdlToDatabaseTask ddlToDatabaseTask; > > > Now when I do: > > mvn install > and try to run the Mojo, I get > > java.lang.NoClassDefFoundError: org/apache/tools/ant/Task > > So I am wondering, how to make this library available to the plugin ? > > > On Sun, Jul 27, 2014 at 5:10 AM, Thomas Sundberg wrote: >> On 27 July 2014 10:05, Mansour Al Akeel wrote: >>> I am writing a custom plug in. This plugin has other dependencies. How >>> can I make these dependencies available when running the plugin >>> without having to add them manually ?? >> >> I assume that your dependencies are declared in your plugin project. >> If they are, then they will be downloaded and made available >> automatically by Maven. >> >> /Thomas >> >> -- >> Thomas Sundberg >> M. Sc. in Computer Science >> >> Mobile: +46 70 767 33 15 >> Blog: http://thomassundberg.wordpress.com/ >> Twitter: @thomassundberg >> >> Better software through faster feedback >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom plugin dependencies
On 27 July 2014 12:02, Mansour Al Akeel wrote: > Thomas, > Thank you for the fast response. Unfortunately this is not the case. > I have generate a maven plugin project from the archetype, and add: > > > org.apache.ddlutils > ddlutils > 1.1 > > Interesting, when I search for the artifact you declare above at http://search.maven.org I can only find version 1.0, not version 1.1 What happens if you declare version 1.0? > > I added the import statement to my Mojo: > > import org.apache.ddlutils.task.DdlToDatabaseTask; > > and declare it: > > private DdlToDatabaseTask ddlToDatabaseTask; > > > Now when I do: > > mvn install > and try to run the Mojo, I get > > java.lang.NoClassDefFoundError: org/apache/tools/ant/Task > > So I am wondering, how to make this library available to the plugin ? > You could consider adding a dependency in your project to the Ant plugin. Search at Central Repository and see what you can find. /Thomas > > On Sun, Jul 27, 2014 at 5:10 AM, Thomas Sundberg wrote: >> On 27 July 2014 10:05, Mansour Al Akeel wrote: >>> I am writing a custom plug in. This plugin has other dependencies. How >>> can I make these dependencies available when running the plugin >>> without having to add them manually ?? >> >> I assume that your dependencies are declared in your plugin project. >> If they are, then they will be downloaded and made available >> automatically by Maven. >> >> /Thomas >> >> -- >> Thomas Sundberg >> M. Sc. in Computer Science >> >> Mobile: +46 70 767 33 15 >> Blog: http://thomassundberg.wordpress.com/ >> Twitter: @thomassundberg >> >> Better software through faster feedback >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > -- Thomas Sundberg M. Sc. in Computer Science Mobile: +46 70 767 33 15 Blog: http://thomassundberg.wordpress.com/ Twitter: @thomassundberg Better software through faster feedback - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom plugin dependencies
Thomas, Thank you for the fast response. Unfortunately this is not the case. I have generate a maven plugin project from the archetype, and add: org.apache.ddlutils ddlutils 1.1 I added the import statement to my Mojo: import org.apache.ddlutils.task.DdlToDatabaseTask; and declare it: private DdlToDatabaseTask ddlToDatabaseTask; Now when I do: mvn install and try to run the Mojo, I get java.lang.NoClassDefFoundError: org/apache/tools/ant/Task So I am wondering, how to make this library available to the plugin ? On Sun, Jul 27, 2014 at 5:10 AM, Thomas Sundberg wrote: > On 27 July 2014 10:05, Mansour Al Akeel wrote: >> I am writing a custom plug in. This plugin has other dependencies. How >> can I make these dependencies available when running the plugin >> without having to add them manually ?? > > I assume that your dependencies are declared in your plugin project. > If they are, then they will be downloaded and made available > automatically by Maven. > > /Thomas > > -- > Thomas Sundberg > M. Sc. in Computer Science > > Mobile: +46 70 767 33 15 > Blog: http://thomassundberg.wordpress.com/ > Twitter: @thomassundberg > > Better software through faster feedback > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom plugin dependencies
On 27 July 2014 10:05, Mansour Al Akeel wrote: > I am writing a custom plug in. This plugin has other dependencies. How > can I make these dependencies available when running the plugin > without having to add them manually ?? I assume that your dependencies are declared in your plugin project. If they are, then they will be downloaded and made available automatically by Maven. /Thomas -- Thomas Sundberg M. Sc. in Computer Science Mobile: +46 70 767 33 15 Blog: http://thomassundberg.wordpress.com/ Twitter: @thomassundberg Better software through faster feedback - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Custom plugin dependencies
I am writing a custom plug in. This plugin has other dependencies. How can I make these dependencies available when running the plugin without having to add them manually ?? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: use separate mirrors for project dendencies and plugin dependencies ??
> > Also, do i need to redefine 'central' it looks redundant to me It's best-practice IMO. It ensures that the central definition declared in the super-POM is overwritten with a dummy (not working) URL. It will/should then be handled by the mirror so that it is redirected to the internal mirror. If, for any reason, the mirror definition is removed or not correctly declared you will then quickly noticed this as your Maven build will not work (as the calls to 'central' will fail). /Anders > > Thanks > > -D > > > > On Mon, May 26, 2014 at 10:34 PM, Anders Hammar wrote: > > > For my solution on this topic I didn't declare a mirror for > > 'plugin-central', i.e. I didn't have the 'plugin-repo' mirror > declaration. > > I does not add anything as it is only a mirror for one repo. > > > > /Anders > > > > > > On Sun, May 25, 2014 at 3:00 AM, Dan Tran wrote: > > > > > I got some thing working > > > > > > 1. at my repo manager, create a proxy, called plugin-central, to host > > > another central.maven.org/maven2 > > > 2. reconfigure my global settings.xml with the following contents. > Please > > > help to review this content > > > > > > > > > > > > product-repo > > > *,!plugin-central > > > Internal Maven Repository Manager > > > http://repos.xxx.com:8081/nexus/content/groups/public > > > > > > > > > plugin-repo > > > plugin-central > > > Internal Maven Repository Manager for plugin and its > > transitive > > > dependencies > > > > http://repos..com:8081/nexus/content/groups/plugin-public > > > > > > > > > > > > > > > > > > > > > redefine-default-repositories > > > > > > > > > > > > central > > > http://central > > > true > > > true > > > > > > > > > > > > > > > > > > plugin-central > > > http://central > > > true > > > true > > > > > > > > > > > > central > > > http://central > > > true > > > true > > > > > > > > > > > > > > > > > > > > > redefine-default-repositories > > > > > > > > > > > > Thank you every one for participate in this discussion, specially > Anders > > > for leading to this solution > > > > > > > > > If you have anything you want to add please chime in > > > > > > > > > -Dan > > > > > > > > > > > > On Sat, May 24, 2014 at 1:19 AM, Anders Hammar > > wrote: > > > > > > > It will if you use the same id, ie 'central'. > > > > > > > > /Anders (mobile) > > > > Den 24 maj 2014 09:36 skrev "Dan Tran" : > > > > > > > > > Anders' suggestion sounds very logical > > > > > > > > > > however, i found this at super pom > > > > > > > > > > > > > > > > > > > > central > > > > > Central Repository > > > > > http://repo.maven.apache.org/maven2 > > > > > default > > > > > > > > > > false > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > central > > > > > Central Repository > > > > > http://repo.maven.apache.org/maven2 > > > > > default > > > > > > > > > > false > > > > > > > > > > > > > > > never > > > > > > > > > > > > > > > > > > > > > > > > > Is there a way to disable/clear out the super pom > pluginRepositories? > > > > > If I add my own pluginRepositories, will it override the super pom > > > > > one? > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, May 6, 2014 at 6:20 AM, Barrie Treloar > > > > > wrote: > > > > > > > > > > > On 6 May 2014 20:23, Anders Hammar wrote: > > > > > > > > > > > > > > > > > > > > > > Presumably you are trying to separate artifacts used by > plugins > > > > > during > > > > > > > > your build (where you might use e.g. GPL licensed modules) > from > > > > > > artifacts > > > > > > > > used as dependencies in your project proper (where using that > > > same > > > > > GPL > > > > > > > > licensed modules would make your legal department scream) by > > > > > separating > > > > > > > the > > > > > > > > repositories used to provide them. > > > > > > > > > > > > > > > > As far as I know/understand all artifacts are downloaded to > the > > > > same > > > > > > > local > > > > > > > > cache repository (~/.m2/repository), regardless of whether > they > > > > were > > > > > > > > required by some plugin or as a dependency of your project. > > > > > > > > > > > > > > > > This makes them available for both purposes and thus > > obliterates > > > > all > > > > > > your > > > > > > > > efforts of keeping them separate. > > > > > > > > > > > > > > > > Maven Masters: Please correct me if I'm wrong. > > > > > > > > > > > > > > > > > > > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether > > > which > > > >
Re: use separate mirrors for project dendencies and plugin dependencies ??
Hi Ander that makes sense now i only have product-repo *,!plugin-central Internal Maven Repository Manager http://repos.xxx.com:8081/nexus/content/groups/public Also, do i need to redefine 'central' it looks redundant to me Thanks -D On Mon, May 26, 2014 at 10:34 PM, Anders Hammar wrote: > For my solution on this topic I didn't declare a mirror for > 'plugin-central', i.e. I didn't have the 'plugin-repo' mirror declaration. > I does not add anything as it is only a mirror for one repo. > > /Anders > > > On Sun, May 25, 2014 at 3:00 AM, Dan Tran wrote: > > > I got some thing working > > > > 1. at my repo manager, create a proxy, called plugin-central, to host > > another central.maven.org/maven2 > > 2. reconfigure my global settings.xml with the following contents. Please > > help to review this content > > > > > > > > product-repo > > *,!plugin-central > > Internal Maven Repository Manager > > http://repos.xxx.com:8081/nexus/content/groups/public > > > > > > plugin-repo > > plugin-central > > Internal Maven Repository Manager for plugin and its > transitive > > dependencies > > http://repos..com:8081/nexus/content/groups/plugin-public > > > > > > > > > > > > > > redefine-default-repositories > > > > > > > > central > > http://central > > true > > true > > > > > > > > > > > > plugin-central > > http://central > > true > > true > > > > > > > > central > > http://central > > true > > true > > > > > > > > > > > > > > redefine-default-repositories > > > > > > > > Thank you every one for participate in this discussion, specially Anders > > for leading to this solution > > > > > > If you have anything you want to add please chime in > > > > > > -Dan > > > > > > > > On Sat, May 24, 2014 at 1:19 AM, Anders Hammar > wrote: > > > > > It will if you use the same id, ie 'central'. > > > > > > /Anders (mobile) > > > Den 24 maj 2014 09:36 skrev "Dan Tran" : > > > > > > > Anders' suggestion sounds very logical > > > > > > > > however, i found this at super pom > > > > > > > > > > > > > > > > central > > > > Central Repository > > > > http://repo.maven.apache.org/maven2 > > > > default > > > > > > > > false > > > > > > > > > > > > > > > > > > > > > > > > > > > > central > > > > Central Repository > > > > http://repo.maven.apache.org/maven2 > > > > default > > > > > > > > false > > > > > > > > > > > > never > > > > > > > > > > > > > > > > > > > > Is there a way to disable/clear out the super pom pluginRepositories? > > > > If I add my own pluginRepositories, will it override the super pom > > > > one? > > > > > > > > > > > > Thanks > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > On Tue, May 6, 2014 at 6:20 AM, Barrie Treloar > > > wrote: > > > > > > > > > On 6 May 2014 20:23, Anders Hammar wrote: > > > > > > > > > > > > > > > > > > > Presumably you are trying to separate artifacts used by plugins > > > > during > > > > > > > your build (where you might use e.g. GPL licensed modules) from > > > > > artifacts > > > > > > > used as dependencies in your project proper (where using that > > same > > > > GPL > > > > > > > licensed modules would make your legal department scream) by > > > > separating > > > > > > the > > > > > > > repositories used to provide them. > > > > > > > > > > > > > > As far as I know/understand all artifacts are downloaded to the > > > same > > > > > > local > > > > > > > cache repository (~/.m2/repository), regardless of whether they > > > were > > > > > > > required by some plugin or as a dependency of your project. > > > > > > > > > > > > > > This makes them available for both purposes and thus > obliterates > > > all > > > > > your > > > > > > > efforts of keeping them separate. > > > > > > > > > > > > > > Maven Masters: Please correct me if I'm wrong. > > > > > > > > > > > > > > > > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether > > which > > > > > AFAIK > > > > > > keeps the repository id for the artifact to verify from where it > > was > > > > > > downloaded. Haven't verified for this use case though. > > > > > > > > > > > > So, using Maven 3 it should be possible to specify one repository > > > > > > declaration for your deps and one pluginRepository declaration > > (with > > > a > > > > > > different repo id) for your plugins (incl deps). If you msut use > > > mirror > > > > > > declarations, I would use this for the deps and add exclusions > > (using > > > > > '!') > > > > > > for any pluginRepository. > > > > > > > > > > > > /
Re: use separate mirrors for project dendencies and plugin dependencies ??
For my solution on this topic I didn't declare a mirror for 'plugin-central', i.e. I didn't have the 'plugin-repo' mirror declaration. I does not add anything as it is only a mirror for one repo. /Anders On Sun, May 25, 2014 at 3:00 AM, Dan Tran wrote: > I got some thing working > > 1. at my repo manager, create a proxy, called plugin-central, to host > another central.maven.org/maven2 > 2. reconfigure my global settings.xml with the following contents. Please > help to review this content > > > > product-repo > *,!plugin-central > Internal Maven Repository Manager > http://repos.xxx.com:8081/nexus/content/groups/public > > > plugin-repo > plugin-central > Internal Maven Repository Manager for plugin and its transitive > dependencies > http://repos..com:8081/nexus/content/groups/plugin-public > > > > > > > redefine-default-repositories > > > > central > http://central > true > true > > > > > > plugin-central > http://central > true > true > > > > central > http://central > true > true > > > > > > > redefine-default-repositories > > > > Thank you every one for participate in this discussion, specially Anders > for leading to this solution > > > If you have anything you want to add please chime in > > > -Dan > > > > On Sat, May 24, 2014 at 1:19 AM, Anders Hammar wrote: > > > It will if you use the same id, ie 'central'. > > > > /Anders (mobile) > > Den 24 maj 2014 09:36 skrev "Dan Tran" : > > > > > Anders' suggestion sounds very logical > > > > > > however, i found this at super pom > > > > > > > > > > > > central > > > Central Repository > > > http://repo.maven.apache.org/maven2 > > > default > > > > > > false > > > > > > > > > > > > > > > > > > > > > central > > > Central Repository > > > http://repo.maven.apache.org/maven2 > > > default > > > > > > false > > > > > > > > > never > > > > > > > > > > > > > > > Is there a way to disable/clear out the super pom pluginRepositories? > > > If I add my own pluginRepositories, will it override the super pom > > > one? > > > > > > > > > Thanks > > > > > > Dan > > > > > > > > > > > > > > > On Tue, May 6, 2014 at 6:20 AM, Barrie Treloar > > wrote: > > > > > > > On 6 May 2014 20:23, Anders Hammar wrote: > > > > > > > > > > > > > > > > Presumably you are trying to separate artifacts used by plugins > > > during > > > > > > your build (where you might use e.g. GPL licensed modules) from > > > > artifacts > > > > > > used as dependencies in your project proper (where using that > same > > > GPL > > > > > > licensed modules would make your legal department scream) by > > > separating > > > > > the > > > > > > repositories used to provide them. > > > > > > > > > > > > As far as I know/understand all artifacts are downloaded to the > > same > > > > > local > > > > > > cache repository (~/.m2/repository), regardless of whether they > > were > > > > > > required by some plugin or as a dependency of your project. > > > > > > > > > > > > This makes them available for both purposes and thus obliterates > > all > > > > your > > > > > > efforts of keeping them separate. > > > > > > > > > > > > Maven Masters: Please correct me if I'm wrong. > > > > > > > > > > > > > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether > which > > > > AFAIK > > > > > keeps the repository id for the artifact to verify from where it > was > > > > > downloaded. Haven't verified for this use case though. > > > > > > > > > > So, using Maven 3 it should be possible to specify one repository > > > > > declaration for your deps and one pluginRepository declaration > (with > > a > > > > > different repo id) for your plugins (incl deps). If you msut use > > mirror > > > > > declarations, I would use this for the deps and add exclusions > (using > > > > '!') > > > > > for any pluginRepository. > > > > > > > > > > /Anders > > > > > > > > > > > > I don't remember what happens for duplicates. > > > > I think it used to complain that the artifact doesn't exist (if the > one > > > it > > > > downloaded from is not available, even though its available > elsewhere). > > > > > > > > The GPL example isn't a good one, as the output of running GPL is not > > GPL > > > > itself. > > > > > > > > I think Nexus allows you to restrict things by licence so that you > can > > > > curate what is available in your repository manager. You'd have to > look > > > at > > > > the docs to find out. > > > > > > > > > >
Re: use separate mirrors for project dendencies and plugin dependencies ??
I got some thing working 1. at my repo manager, create a proxy, called plugin-central, to host another central.maven.org/maven2 2. reconfigure my global settings.xml with the following contents. Please help to review this content product-repo *,!plugin-central Internal Maven Repository Manager http://repos.xxx.com:8081/nexus/content/groups/public plugin-repo plugin-central Internal Maven Repository Manager for plugin and its transitive dependencies http://repos..com:8081/nexus/content/groups/plugin-public redefine-default-repositories central http://central true true plugin-central http://central true true central http://central true true redefine-default-repositories Thank you every one for participate in this discussion, specially Anders for leading to this solution If you have anything you want to add please chime in -Dan On Sat, May 24, 2014 at 1:19 AM, Anders Hammar wrote: > It will if you use the same id, ie 'central'. > > /Anders (mobile) > Den 24 maj 2014 09:36 skrev "Dan Tran" : > > > Anders' suggestion sounds very logical > > > > however, i found this at super pom > > > > > > > > central > > Central Repository > > http://repo.maven.apache.org/maven2 > > default > > > > false > > > > > > > > > > > > > > central > > Central Repository > > http://repo.maven.apache.org/maven2 > > default > > > > false > > > > > > never > > > > > > > > > > Is there a way to disable/clear out the super pom pluginRepositories? > > If I add my own pluginRepositories, will it override the super pom > > one? > > > > > > Thanks > > > > Dan > > > > > > > > > > On Tue, May 6, 2014 at 6:20 AM, Barrie Treloar > wrote: > > > > > On 6 May 2014 20:23, Anders Hammar wrote: > > > > > > > > > > > > > Presumably you are trying to separate artifacts used by plugins > > during > > > > > your build (where you might use e.g. GPL licensed modules) from > > > artifacts > > > > > used as dependencies in your project proper (where using that same > > GPL > > > > > licensed modules would make your legal department scream) by > > separating > > > > the > > > > > repositories used to provide them. > > > > > > > > > > As far as I know/understand all artifacts are downloaded to the > same > > > > local > > > > > cache repository (~/.m2/repository), regardless of whether they > were > > > > > required by some plugin or as a dependency of your project. > > > > > > > > > > This makes them available for both purposes and thus obliterates > all > > > your > > > > > efforts of keeping them separate. > > > > > > > > > > Maven Masters: Please correct me if I'm wrong. > > > > > > > > > > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether which > > > AFAIK > > > > keeps the repository id for the artifact to verify from where it was > > > > downloaded. Haven't verified for this use case though. > > > > > > > > So, using Maven 3 it should be possible to specify one repository > > > > declaration for your deps and one pluginRepository declaration (with > a > > > > different repo id) for your plugins (incl deps). If you msut use > mirror > > > > declarations, I would use this for the deps and add exclusions (using > > > '!') > > > > for any pluginRepository. > > > > > > > > /Anders > > > > > > > > > I don't remember what happens for duplicates. > > > I think it used to complain that the artifact doesn't exist (if the one > > it > > > downloaded from is not available, even though its available elsewhere). > > > > > > The GPL example isn't a good one, as the output of running GPL is not > GPL > > > itself. > > > > > > I think Nexus allows you to restrict things by licence so that you can > > > curate what is available in your repository manager. You'd have to look > > at > > > the docs to find out. > > > > > >
Re: use separate mirrors for project dendencies and plugin dependencies ??
It will if you use the same id, ie 'central'. /Anders (mobile) Den 24 maj 2014 09:36 skrev "Dan Tran" : > Anders' suggestion sounds very logical > > however, i found this at super pom > > > > central > Central Repository > http://repo.maven.apache.org/maven2 > default > > false > > > > > > > central > Central Repository > http://repo.maven.apache.org/maven2 > default > > false > > > never > > > > > Is there a way to disable/clear out the super pom pluginRepositories? > If I add my own pluginRepositories, will it override the super pom > one? > > > Thanks > > Dan > > > > > On Tue, May 6, 2014 at 6:20 AM, Barrie Treloar wrote: > > > On 6 May 2014 20:23, Anders Hammar wrote: > > > > > > > > > > Presumably you are trying to separate artifacts used by plugins > during > > > > your build (where you might use e.g. GPL licensed modules) from > > artifacts > > > > used as dependencies in your project proper (where using that same > GPL > > > > licensed modules would make your legal department scream) by > separating > > > the > > > > repositories used to provide them. > > > > > > > > As far as I know/understand all artifacts are downloaded to the same > > > local > > > > cache repository (~/.m2/repository), regardless of whether they were > > > > required by some plugin or as a dependency of your project. > > > > > > > > This makes them available for both purposes and thus obliterates all > > your > > > > efforts of keeping them separate. > > > > > > > > Maven Masters: Please correct me if I'm wrong. > > > > > > > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether which > > AFAIK > > > keeps the repository id for the artifact to verify from where it was > > > downloaded. Haven't verified for this use case though. > > > > > > So, using Maven 3 it should be possible to specify one repository > > > declaration for your deps and one pluginRepository declaration (with a > > > different repo id) for your plugins (incl deps). If you msut use mirror > > > declarations, I would use this for the deps and add exclusions (using > > '!') > > > for any pluginRepository. > > > > > > /Anders > > > > > > I don't remember what happens for duplicates. > > I think it used to complain that the artifact doesn't exist (if the one > it > > downloaded from is not available, even though its available elsewhere). > > > > The GPL example isn't a good one, as the output of running GPL is not GPL > > itself. > > > > I think Nexus allows you to restrict things by licence so that you can > > curate what is available in your repository manager. You'd have to look > at > > the docs to find out. > > >
Re: use separate mirrors for project dendencies and plugin dependencies ??
Anders' suggestion sounds very logical however, i found this at super pom central Central Repository http://repo.maven.apache.org/maven2 default false central Central Repository http://repo.maven.apache.org/maven2 default false never Is there a way to disable/clear out the super pom pluginRepositories? If I add my own pluginRepositories, will it override the super pom one? Thanks Dan On Tue, May 6, 2014 at 6:20 AM, Barrie Treloar wrote: > On 6 May 2014 20:23, Anders Hammar wrote: > > > > > > > Presumably you are trying to separate artifacts used by plugins during > > > your build (where you might use e.g. GPL licensed modules) from > artifacts > > > used as dependencies in your project proper (where using that same GPL > > > licensed modules would make your legal department scream) by separating > > the > > > repositories used to provide them. > > > > > > As far as I know/understand all artifacts are downloaded to the same > > local > > > cache repository (~/.m2/repository), regardless of whether they were > > > required by some plugin or as a dependency of your project. > > > > > > This makes them available for both purposes and thus obliterates all > your > > > efforts of keeping them separate. > > > > > > Maven Masters: Please correct me if I'm wrong. > > > > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether which > AFAIK > > keeps the repository id for the artifact to verify from where it was > > downloaded. Haven't verified for this use case though. > > > > So, using Maven 3 it should be possible to specify one repository > > declaration for your deps and one pluginRepository declaration (with a > > different repo id) for your plugins (incl deps). If you msut use mirror > > declarations, I would use this for the deps and add exclusions (using > '!') > > for any pluginRepository. > > > > /Anders > > > I don't remember what happens for duplicates. > I think it used to complain that the artifact doesn't exist (if the one it > downloaded from is not available, even though its available elsewhere). > > The GPL example isn't a good one, as the output of running GPL is not GPL > itself. > > I think Nexus allows you to restrict things by licence so that you can > curate what is available in your repository manager. You'd have to look at > the docs to find out. >
Re: use separate mirrors for project dendencies and plugin dependencies ??
On 6 May 2014 20:23, Anders Hammar wrote: > > > > Presumably you are trying to separate artifacts used by plugins during > > your build (where you might use e.g. GPL licensed modules) from artifacts > > used as dependencies in your project proper (where using that same GPL > > licensed modules would make your legal department scream) by separating > the > > repositories used to provide them. > > > > As far as I know/understand all artifacts are downloaded to the same > local > > cache repository (~/.m2/repository), regardless of whether they were > > required by some plugin or as a dependency of your project. > > > > This makes them available for both purposes and thus obliterates all your > > efforts of keeping them separate. > > > > Maven Masters: Please correct me if I'm wrong. > > > > I don't think this is correct with Maven 3. Maven 3 uses Aether which AFAIK > keeps the repository id for the artifact to verify from where it was > downloaded. Haven't verified for this use case though. > > So, using Maven 3 it should be possible to specify one repository > declaration for your deps and one pluginRepository declaration (with a > different repo id) for your plugins (incl deps). If you msut use mirror > declarations, I would use this for the deps and add exclusions (using '!') > for any pluginRepository. > > /Anders I don't remember what happens for duplicates. I think it used to complain that the artifact doesn't exist (if the one it downloaded from is not available, even though its available elsewhere). The GPL example isn't a good one, as the output of running GPL is not GPL itself. I think Nexus allows you to restrict things by licence so that you can curate what is available in your repository manager. You'd have to look at the docs to find out.
Re: use separate mirrors for project dendencies and plugin dependencies ??
> > Presumably you are trying to separate artifacts used by plugins during > your build (where you might use e.g. GPL licensed modules) from artifacts > used as dependencies in your project proper (where using that same GPL > licensed modules would make your legal department scream) by separating the > repositories used to provide them. > > As far as I know/understand all artifacts are downloaded to the same local > cache repository (~/.m2/repository), regardless of whether they were > required by some plugin or as a dependency of your project. > > This makes them available for both purposes and thus obliterates all your > efforts of keeping them separate. > > Maven Masters: Please correct me if I'm wrong. > I don't think this is correct with Maven 3. Maven 3 uses Aether which AFAIK keeps the repository id for the artifact to verify from where it was downloaded. Haven't verified for this use case though. So, using Maven 3 it should be possible to specify one repository declaration for your deps and one pluginRepository declaration (with a different repo id) for your plugins (incl deps). If you msut use mirror declarations, I would use this for the deps and add exclusions (using '!') for any pluginRepository. /Anders > > Cheers, > Wolf > > >> >> >> On Mon, May 5, 2014 at 11:59 PM, Christian Domsch >> wrote: >> >> Hi Dan, >>> >>> Did you consider using nexus? There you can setup any kind of strange >>> repo >>> setup your mind can come up with ;-) For your case, create one repo for >>> your project stuff and one repo for your plugin stuff. Create a group for >>> both for easy access and control access by authorization... >>> >>> Christian >>> >>> >>> On 06.05.2014 06:29, Dan Tran wrote: >>> >>> Thanks Barrie, Will see what I can can do. On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar wrote: On 6 May 2014 09:21, Dan Tran wrote: > for legal purpose ( btw, please dont drill me here), I would like to > use > >> one mirror as a gate way for all of of my project dependencies,and >> >> another > > mirror as a gate way for all of my plugins and their dependencies >> >> >> is it possible? Posting a settings.xml config here is very much >> >> appreciated > > > Having not done this, here is some more insane advice. > > I'd use three. > One proxy to proxy the other two proxies. > All developers point to the master proxy. > You can then configure the master proxy to refer to the project > dependencies proxy and another for plugins dependencies proxy. > > You might need a more sophisticated maven repository manager that you > can > restrict what is allowed in the proxies (i.e. it just doesn't go and > grab > stuff for you). > > You're going to have to do a lot of fiddling to get this to work. > I'm not convinced it is going to give you what legal thinks it will... > > If you could write up what you tried and whether it worked it would be > helpful for anyone else attempting the same thing... > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: use separate mirrors for project dendencies and plugin dependencies ??
On 06.05.2014 09:07, Dan Tran wrote: Ofcourse, I do have Maven repo manager ̣ nexus at this time), however still struggle on how to get only plugin's artifact goto one proxy and others goto to another proxy using mirror settings. Are you able to do so? -Dan I'm none to sure that this would even help at all: Presumably you are trying to separate artifacts used by plugins during your build (where you might use e.g. GPL licensed modules) from artifacts used as dependencies in your project proper (where using that same GPL licensed modules would make your legal department scream) by separating the repositories used to provide them. As far as I know/understand all artifacts are downloaded to the same local cache repository (~/.m2/repository), regardless of whether they were required by some plugin or as a dependency of your project. This makes them available for both purposes and thus obliterates all your efforts of keeping them separate. Maven Masters: Please correct me if I'm wrong. Cheers, Wolf On Mon, May 5, 2014 at 11:59 PM, Christian Domsch wrote: Hi Dan, Did you consider using nexus? There you can setup any kind of strange repo setup your mind can come up with ;-) For your case, create one repo for your project stuff and one repo for your plugin stuff. Create a group for both for easy access and control access by authorization... Christian On 06.05.2014 06:29, Dan Tran wrote: Thanks Barrie, Will see what I can can do. On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar wrote: On 6 May 2014 09:21, Dan Tran wrote: for legal purpose ( btw, please dont drill me here), I would like to use one mirror as a gate way for all of of my project dependencies,and another mirror as a gate way for all of my plugins and their dependencies is it possible? Posting a settings.xml config here is very much appreciated Having not done this, here is some more insane advice. I'd use three. One proxy to proxy the other two proxies. All developers point to the master proxy. You can then configure the master proxy to refer to the project dependencies proxy and another for plugins dependencies proxy. You might need a more sophisticated maven repository manager that you can restrict what is allowed in the proxies (i.e. it just doesn't go and grab stuff for you). You're going to have to do a lot of fiddling to get this to work. I'm not convinced it is going to give you what legal thinks it will... If you could write up what you tried and whether it worked it would be helpful for anyone else attempting the same thing... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: use separate mirrors for project dendencies and plugin dependencies ??
Hello, It would be good if Proxy requests would actually carry the repository URLs or names the request is actually proxied for. I havent seen a proxy which allows configuration in this regard (and therefore I think the protocol does not provide this extra information) Bernd > Am 06.05.2014 um 09:07 schrieb Dan Tran : > > Ofcourse, I do have Maven repo manager ̣ nexus at this time), however still > struggle on how to get only plugin's artifact goto one proxy and others > goto to another proxy using mirror settings. > > Are you able to do so? > > -Dan > > > >> On Mon, May 5, 2014 at 11:59 PM, Christian Domsch wrote: >> >> Hi Dan, >> >> Did you consider using nexus? There you can setup any kind of strange repo >> setup your mind can come up with ;-) For your case, create one repo for >> your project stuff and one repo for your plugin stuff. Create a group for >> both for easy access and control access by authorization... >> >> Christian >> >> >>> On 06.05.2014 06:29, Dan Tran wrote: >>> >>> Thanks Barrie, >>> >>> Will see what I can can do. >>> >>> >>> On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar >>> wrote: >>> On 6 May 2014 09:21, Dan Tran wrote: for legal purpose ( btw, please dont drill me here), I would like to use > one mirror as a gate way for all of of my project dependencies,and another > mirror as a gate way for all of my plugins and their dependencies > > > is it possible? Posting a settings.xml config here is very much appreciated Having not done this, here is some more insane advice. I'd use three. One proxy to proxy the other two proxies. All developers point to the master proxy. You can then configure the master proxy to refer to the project dependencies proxy and another for plugins dependencies proxy. You might need a more sophisticated maven repository manager that you can restrict what is allowed in the proxies (i.e. it just doesn't go and grab stuff for you). You're going to have to do a lot of fiddling to get this to work. I'm not convinced it is going to give you what legal thinks it will... If you could write up what you tried and whether it worked it would be helpful for anyone else attempting the same thing... >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: use separate mirrors for project dendencies and plugin dependencies ??
Ofcourse, I do have Maven repo manager ̣ nexus at this time), however still struggle on how to get only plugin's artifact goto one proxy and others goto to another proxy using mirror settings. Are you able to do so? -Dan On Mon, May 5, 2014 at 11:59 PM, Christian Domsch wrote: > Hi Dan, > > Did you consider using nexus? There you can setup any kind of strange repo > setup your mind can come up with ;-) For your case, create one repo for > your project stuff and one repo for your plugin stuff. Create a group for > both for easy access and control access by authorization... > > Christian > > > On 06.05.2014 06:29, Dan Tran wrote: > >> Thanks Barrie, >> >> Will see what I can can do. >> >> >> On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar >> wrote: >> >> On 6 May 2014 09:21, Dan Tran wrote: >>> >>> for legal purpose ( btw, please dont drill me here), I would like to use one mirror as a gate way for all of of my project dependencies,and >>> another >>> mirror as a gate way for all of my plugins and their dependencies is it possible? Posting a settings.xml config here is very much >>> appreciated >>> >>> >>> Having not done this, here is some more insane advice. >>> >>> I'd use three. >>> One proxy to proxy the other two proxies. >>> All developers point to the master proxy. >>> You can then configure the master proxy to refer to the project >>> dependencies proxy and another for plugins dependencies proxy. >>> >>> You might need a more sophisticated maven repository manager that you can >>> restrict what is allowed in the proxies (i.e. it just doesn't go and grab >>> stuff for you). >>> >>> You're going to have to do a lot of fiddling to get this to work. >>> I'm not convinced it is going to give you what legal thinks it will... >>> >>> If you could write up what you tried and whether it worked it would be >>> helpful for anyone else attempting the same thing... >>> >>> >
Re: use separate mirrors for project dendencies and plugin dependencies ??
Hi Dan, Did you consider using nexus? There you can setup any kind of strange repo setup your mind can come up with ;-) For your case, create one repo for your project stuff and one repo for your plugin stuff. Create a group for both for easy access and control access by authorization... Christian On 06.05.2014 06:29, Dan Tran wrote: Thanks Barrie, Will see what I can can do. On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar wrote: On 6 May 2014 09:21, Dan Tran wrote: for legal purpose ( btw, please dont drill me here), I would like to use one mirror as a gate way for all of of my project dependencies,and another mirror as a gate way for all of my plugins and their dependencies is it possible? Posting a settings.xml config here is very much appreciated Having not done this, here is some more insane advice. I'd use three. One proxy to proxy the other two proxies. All developers point to the master proxy. You can then configure the master proxy to refer to the project dependencies proxy and another for plugins dependencies proxy. You might need a more sophisticated maven repository manager that you can restrict what is allowed in the proxies (i.e. it just doesn't go and grab stuff for you). You're going to have to do a lot of fiddling to get this to work. I'm not convinced it is going to give you what legal thinks it will... If you could write up what you tried and whether it worked it would be helpful for anyone else attempting the same thing...
Re: use separate mirrors for project dendencies and plugin dependencies ??
Thanks Barrie, Will see what I can can do. On Mon, May 5, 2014 at 5:04 PM, Barrie Treloar wrote: > On 6 May 2014 09:21, Dan Tran wrote: > > > for legal purpose ( btw, please dont drill me here), I would like to use > > one mirror as a gate way for all of of my project dependencies,and > another > > mirror as a gate way for all of my plugins and their dependencies > > > > > > is it possible? Posting a settings.xml config here is very much > appreciated > > > Having not done this, here is some more insane advice. > > I'd use three. > One proxy to proxy the other two proxies. > All developers point to the master proxy. > You can then configure the master proxy to refer to the project > dependencies proxy and another for plugins dependencies proxy. > > You might need a more sophisticated maven repository manager that you can > restrict what is allowed in the proxies (i.e. it just doesn't go and grab > stuff for you). > > You're going to have to do a lot of fiddling to get this to work. > I'm not convinced it is going to give you what legal thinks it will... > > If you could write up what you tried and whether it worked it would be > helpful for anyone else attempting the same thing... >
Re: use separate mirrors for project dendencies and plugin dependencies ??
On 6 May 2014 09:21, Dan Tran wrote: > for legal purpose ( btw, please dont drill me here), I would like to use > one mirror as a gate way for all of of my project dependencies,and another > mirror as a gate way for all of my plugins and their dependencies > > > is it possible? Posting a settings.xml config here is very much appreciated Having not done this, here is some more insane advice. I'd use three. One proxy to proxy the other two proxies. All developers point to the master proxy. You can then configure the master proxy to refer to the project dependencies proxy and another for plugins dependencies proxy. You might need a more sophisticated maven repository manager that you can restrict what is allowed in the proxies (i.e. it just doesn't go and grab stuff for you). You're going to have to do a lot of fiddling to get this to work. I'm not convinced it is going to give you what legal thinks it will... If you could write up what you tried and whether it worked it would be helpful for anyone else attempting the same thing...
use separate mirrors for project dendencies and plugin dependencies ??
for legal purpose ( btw, please dont drill me here), I would like to use one mirror as a gate way for all of of my project dependencies,and another mirror as a gate way for all of my plugins and their dependencies is it possible? Posting a settings.xml config here is very much appreciated Thanks -D BTW as documented, I am currently able to get both type of artifacts to use the same mirror to my repo manager http://maven.apache.org/guides/mini/guide-mirror-settings.html does not seem to support what I am looking for
Re: Ant based plugin dependencies
Hi, Thanks for your answer. I'll try to explain better what I am trying to do. I have an artifact, say, com.mycompany.ant-build-utils containing ant scripts that do some interaction with SCM an CI, that we need to use during the build. Now, as you say, it is untarred manually on a shared drive and called directly from a build script that is in every project. So every project we have has a pom.xml, and a build.xml. The build.xml is called either by maven via the ant plugin, or invoked directy from the command line using ant for the particular task I am discussing. What I would like to do, is to use the scripts that are in my com.mycompany.ant-build-utils via maven, and I thought the best way to do that was to create a plugin (I chose an ant-based plugin). My plugin, say com.mycompany.ci-plugin has a pom that will look like this : 4.0.0 com.mycompany ci-plugin 1.0-SNAPSHOT maven-plugin CI plugin org.apache.maven maven-script-ant 2.0.6 com.mycompany ant-build-utils 1.0-SNAPSHOT maven-plugin-plugin 2.5 org.apache.maven.plugin-tools maven-plugin-tools-ant 2.5 update-ci and has an ant mojo like this : Here we should call the ant script from ant-build-scripts My problem is, as you see, to be able to fetch the ant-build-scripts when the plugin is used from another project, and execute a target from it. One solution I guess would be to explicitly call maven from my mojo to copy and unpack the deps, but it is a solution I would like to avoid as it breaks the standard maven process. I hope my explanations were clear, Thanks for your interest, Arnaud 2013/5/17 Baptiste Mathus > Hi, > Not sure I understand what your issue is. > Are you depending on some filesystem path? > What's the displayed error? > > -- Baptiste > Le 16 mai 2013 18:42, "arnaud dufranne" a écrit : > > > Hi, > > > > I am currently looking into writing an ant based maven plugin. My main > > issue is that this plugin depends on an artifact (tar.gz in a company > > repository) containing a few ant scripts, whose tasks should be run when > > using the plugin. > > > > I declared the dependency in my plugin's pom.xml, and the plugin builds > and > > installs fine. > > > > When using the plugin from another project, the dependency to my ant > > artifact is not pulled from the repository, so not visible from my ant > > plugin. > > > > I have seen other discussions where the path to the scripts would be hard > > coded in the plugin, but my goal is to keep my ant library nicely > packaged > > and to avoid this solution. > > > > Does anyone have any experience in doing that kind of things ? > > > > Thanks for you input, > > > > Arnaud > > >
Re: Ant based plugin dependencies
Hi, Not sure I understand what your issue is. Are you depending on some filesystem path? What's the displayed error? -- Baptiste Le 16 mai 2013 18:42, "arnaud dufranne" a écrit : > Hi, > > I am currently looking into writing an ant based maven plugin. My main > issue is that this plugin depends on an artifact (tar.gz in a company > repository) containing a few ant scripts, whose tasks should be run when > using the plugin. > > I declared the dependency in my plugin's pom.xml, and the plugin builds and > installs fine. > > When using the plugin from another project, the dependency to my ant > artifact is not pulled from the repository, so not visible from my ant > plugin. > > I have seen other discussions where the path to the scripts would be hard > coded in the plugin, but my goal is to keep my ant library nicely packaged > and to avoid this solution. > > Does anyone have any experience in doing that kind of things ? > > Thanks for you input, > > Arnaud >
Ant based plugin dependencies
Hi, I am currently looking into writing an ant based maven plugin. My main issue is that this plugin depends on an artifact (tar.gz in a company repository) containing a few ant scripts, whose tasks should be run when using the plugin. I declared the dependency in my plugin's pom.xml, and the plugin builds and installs fine. When using the plugin from another project, the dependency to my ant artifact is not pulled from the repository, so not visible from my ant plugin. I have seen other discussions where the path to the scripts would be hard coded in the plugin, but my goal is to keep my ant library nicely packaged and to avoid this solution. Does anyone have any experience in doing that kind of things ? Thanks for you input, Arnaud
Ant based plugin dependencies
Hi, I am currently looking into writing an ant based maven plugin. My main issue is that this plugin depends on an artifact (tar.gz in a company repository) containing a few ant scripts, whose tasks should be run when using the plugin. I declared the dependency in my plugin's pom.xml, and the plugin builds and installs fine. When using the plugin from another project, the dependency to my ant artifact is not pulled from the repository, so not visible from my ant plugin. I have seen other discussions where the path to the scripts would be hard coded in the plugin, but my goal is to keep my ant library nicely packaged and to avoid this solution. Does anyone have any experience in doing that kind of things ? Thanks for you input, Arnaud
RE: Override plugin dependencies?
Billy according to http://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html Requires dependency resolution of artifacts in scope: test. did you specifically configure go-offline to include compile scope (via includeScope)? http://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html#includeScope Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: newman...@gmail.com > Date: Tue, 21 Aug 2012 09:20:37 -0600 > Subject: Re: Override plugin dependencies? > To: users@maven.apache.org > > Anders, > > I agree with you comment about internet access. Unfortunately I will > never have access to the internet from my workstation. This has made > maven extremely painful to work with, but something I have to deal > with. > > As for your solution I cannot get it to work. In my main pom I have: > > > > > maven-javadoc-plugin > 2.8.1 > . > > > > > When I try to use the release:perform goal I get the following error: > > Error building POM (may not be this projects POM) > > Project ID: org.apache.maven.plugins:maven-javadoc-plugin > > Reason: POM 'org.apache.maven.plugins:maven-javadoc-plugin' not found > in repository: Unable to download the artifact from any repository > org.apache.maven.plugins:maven-javadoc-plugin:pom:2.5 > > > So this error is not telling me anything I don't already know, > maven-javadoc-plugin version 2.5 is not in my repository, I only have > version 2.8.1. But adding version 2.8.1 to my plugin management > section did not work as the release-plugin has a dependency that has a > dependency on version 2.5. > > Sure I can pull version 2.5 back to my internal repo, but if I can > control the version of a plugin that maven would use throughout its > build (even if another pom says use a different version) that would > help. > > I also tried to create a pom with maven-release-plugin defined then: > mvn dependency:go-offline > > That pulled some of the dependencies but not all. I.E. that did not > pull the maven-javadoc-plugin > > Any more ideas? > > Thanks for all the help thus far. > Billy > > > On Mon, Aug 20, 2012 at 11:57 PM, Anders Hammar wrote: > > Just ignore Martin's mail. It doesn't make any sense to me either. > > > > To answer your questions, I'll start with #2 first: > > > > The best solution to this problem is to get a repo manager (archiva in > > your case) that has Internet access. It will be VERY difficult for you > > to work with Maven unless you do this. Trust me, I've tried! > > > > And then #1: > > > > What you need to do is to define the version of the plugins you want > > to use in the pluginManagement section. The best solution to handle > > this is to do this in a parent pom which all your projects inherit > > from. This will ensure that you'll use that version you want, and it > > will also ensure that the same version is always used (which is not > > the case when you don't pin down the version, it could then change > > when new versions are released or when you upgrade Maven depending on > > what plugin we're talking about). > > > > > > > > On Tue, Aug 21, 2012 at 3:21 AM, Billy Newman wrote: > >> This is very confusing to me. I have a remote repository (Archiva) where > >> we store all the plugins we bring in. This includes version 2.3.2 of the > >> release plugin. When I use the 2.3.2 release plugin it asks for 2.5 of the > >> javadoc plugin which I do not have in my internal remote repository. > >> > >> Sent from my iPhone > >> > >&g
Re: Override plugin dependencies?
Anders, I agree with you comment about internet access. Unfortunately I will never have access to the internet from my workstation. This has made maven extremely painful to work with, but something I have to deal with. As for your solution I cannot get it to work. In my main pom I have: maven-javadoc-plugin 2.8.1 . When I try to use the release:perform goal I get the following error: Error building POM (may not be this projects POM) Project ID: org.apache.maven.plugins:maven-javadoc-plugin Reason: POM 'org.apache.maven.plugins:maven-javadoc-plugin' not found in repository: Unable to download the artifact from any repository org.apache.maven.plugins:maven-javadoc-plugin:pom:2.5 So this error is not telling me anything I don't already know, maven-javadoc-plugin version 2.5 is not in my repository, I only have version 2.8.1. But adding version 2.8.1 to my plugin management section did not work as the release-plugin has a dependency that has a dependency on version 2.5. Sure I can pull version 2.5 back to my internal repo, but if I can control the version of a plugin that maven would use throughout its build (even if another pom says use a different version) that would help. I also tried to create a pom with maven-release-plugin defined then: mvn dependency:go-offline That pulled some of the dependencies but not all. I.E. that did not pull the maven-javadoc-plugin Any more ideas? Thanks for all the help thus far. Billy On Mon, Aug 20, 2012 at 11:57 PM, Anders Hammar wrote: > Just ignore Martin's mail. It doesn't make any sense to me either. > > To answer your questions, I'll start with #2 first: > > The best solution to this problem is to get a repo manager (archiva in > your case) that has Internet access. It will be VERY difficult for you > to work with Maven unless you do this. Trust me, I've tried! > > And then #1: > > What you need to do is to define the version of the plugins you want > to use in the pluginManagement section. The best solution to handle > this is to do this in a parent pom which all your projects inherit > from. This will ensure that you'll use that version you want, and it > will also ensure that the same version is always used (which is not > the case when you don't pin down the version, it could then change > when new versions are released or when you upgrade Maven depending on > what plugin we're talking about). > > > > On Tue, Aug 21, 2012 at 3:21 AM, Billy Newman wrote: >> This is very confusing to me. I have a remote repository (Archiva) where we >> store all the plugins we bring in. This includes version 2.3.2 of the >> release plugin. When I use the 2.3.2 release plugin it asks for 2.5 of the >> javadoc plugin which I do not have in my internal remote repository. >> >> Sent from my iPhone >> >> On Aug 20, 2012, at 7:13 PM, Martin Gainty wrote: >> >>> >>> I would aggregate all of your local plugins into a local-only pom.xml which >>> would identify your local repository as your 'primary repository' >>> when using the local-only pom you would always identify 2.8.1 as the only >>> maven-javadoc-plugin stored in local repository >>> the other poms will reference the 'normal' repositories from maven >>> settings.xml which will of course reference the 2.5 maven-javadoc-plugin >>> >>> http://maven.apache.org/guides/introduction/introduction-to-repositories.html >>> >>> Martin Gainty >>> __ >>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >>> >>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >>> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >>> dient lediglich dem Austausch von Informationen und entfaltet keine >>> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >>> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le >>> destinataire prévu, nous te demandons avec bonté que pour satisfaire >>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >>> de ceci est interdite. Ce message sert à l'information seulement et n'aura >>> pas n'importe quel effet légalement obligatoire. Étant donné que les email >>> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >>> aucune responsabilité pour le contenu fourni
Re: Override plugin dependencies?
Just ignore Martin's mail. It doesn't make any sense to me either. To answer your questions, I'll start with #2 first: The best solution to this problem is to get a repo manager (archiva in your case) that has Internet access. It will be VERY difficult for you to work with Maven unless you do this. Trust me, I've tried! And then #1: What you need to do is to define the version of the plugins you want to use in the pluginManagement section. The best solution to handle this is to do this in a parent pom which all your projects inherit from. This will ensure that you'll use that version you want, and it will also ensure that the same version is always used (which is not the case when you don't pin down the version, it could then change when new versions are released or when you upgrade Maven depending on what plugin we're talking about). On Tue, Aug 21, 2012 at 3:21 AM, Billy Newman wrote: > This is very confusing to me. I have a remote repository (Archiva) where we > store all the plugins we bring in. This includes version 2.3.2 of the release > plugin. When I use the 2.3.2 release plugin it asks for 2.5 of the javadoc > plugin which I do not have in my internal remote repository. > > Sent from my iPhone > > On Aug 20, 2012, at 7:13 PM, Martin Gainty wrote: > >> >> I would aggregate all of your local plugins into a local-only pom.xml which >> would identify your local repository as your 'primary repository' >> when using the local-only pom you would always identify 2.8.1 as the only >> maven-javadoc-plugin stored in local repository >> the other poms will reference the 'normal' repositories from maven >> settings.xml which will of course reference the 2.5 maven-javadoc-plugin >> >> http://maven.apache.org/guides/introduction/introduction-to-repositories.html >> >> Martin Gainty >> __ >> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >> >> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >> dient lediglich dem Austausch von Informationen und entfaltet keine >> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le >> destinataire prévu, nous te demandons avec bonté que pour satisfaire >> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >> de ceci est interdite. Ce message sert à l'information seulement et n'aura >> pas n'importe quel effet légalement obligatoire. Étant donné que les email >> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >> aucune responsabilité pour le contenu fourni. >> >> >>> Subject: Override plugin dependencies? >>> From: newman...@gmail.com >>> Date: Mon, 20 Aug 2012 18:50:16 -0600 >>> To: users@maven.apache.org >>> >>> I have a couple of quick questions about plugins and their dependencies. I >>> am on a private network so it is sometimes difficult to get a plugin and >>> all it's dependencies. >>> >>> 1. I am trying to use the maven-release-plugin and during the deploy phase >>> it is looking for the maven-javadoc-plugin version 2.5. I have version >>> 2.8.1 in my private archiva repository. Is there anyway I can specify when >>> using the release plugin to use a different version for one of its >>> dependencies. >>> >>> 2. I do not think #1 is possible for a few reasons. As such is there a good >>> way to download a plugin and all of its dependencies so that I can bring >>> them over to a private repository? I think the problem here is that >>> different dependencies are pulled during different phases of the build, so >>> unless I actually run the plugin I am not sure I can get all the >>> dependencies. Any thoughts? >>> >>> Thanks, >>> Billy >>> >>> Sent from my iPhone >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Override plugin dependencies?
This is very confusing to me. I have a remote repository (Archiva) where we store all the plugins we bring in. This includes version 2.3.2 of the release plugin. When I use the 2.3.2 release plugin it asks for 2.5 of the javadoc plugin which I do not have in my internal remote repository. Sent from my iPhone On Aug 20, 2012, at 7:13 PM, Martin Gainty wrote: > > I would aggregate all of your local plugins into a local-only pom.xml which > would identify your local repository as your 'primary repository' > when using the local-only pom you would always identify 2.8.1 as the only > maven-javadoc-plugin stored in local repository > the other poms will reference the 'normal' repositories from maven > settings.xml which will of course reference the 2.5 maven-javadoc-plugin > > http://maven.apache.org/guides/introduction/introduction-to-repositories.html > > Martin Gainty > __ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger > sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung > oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich > dem Austausch von Informationen und entfaltet keine rechtliche > Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen > wir keine Haftung fuer den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire informez > l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci > est interdite. Ce message sert à l'information seulement et n'aura pas > n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > >> Subject: Override plugin dependencies? >> From: newman...@gmail.com >> Date: Mon, 20 Aug 2012 18:50:16 -0600 >> To: users@maven.apache.org >> >> I have a couple of quick questions about plugins and their dependencies. I >> am on a private network so it is sometimes difficult to get a plugin and all >> it's dependencies. >> >> 1. I am trying to use the maven-release-plugin and during the deploy phase >> it is looking for the maven-javadoc-plugin version 2.5. I have version 2.8.1 >> in my private archiva repository. Is there anyway I can specify when using >> the release plugin to use a different version for one of its dependencies. >> >> 2. I do not think #1 is possible for a few reasons. As such is there a good >> way to download a plugin and all of its dependencies so that I can bring >> them over to a private repository? I think the problem here is that >> different dependencies are pulled during different phases of the build, so >> unless I actually run the plugin I am not sure I can get all the >> dependencies. Any thoughts? >> >> Thanks, >> Billy >> >> Sent from my iPhone >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Override plugin dependencies?
I would aggregate all of your local plugins into a local-only pom.xml which would identify your local repository as your 'primary repository' when using the local-only pom you would always identify 2.8.1 as the only maven-javadoc-plugin stored in local repository the other poms will reference the 'normal' repositories from maven settings.xml which will of course reference the 2.5 maven-javadoc-plugin http://maven.apache.org/guides/introduction/introduction-to-repositories.html Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Subject: Override plugin dependencies? > From: newman...@gmail.com > Date: Mon, 20 Aug 2012 18:50:16 -0600 > To: users@maven.apache.org > > I have a couple of quick questions about plugins and their dependencies. I > am on a private network so it is sometimes difficult to get a plugin and all > it's dependencies. > > 1. I am trying to use the maven-release-plugin and during the deploy phase > it is looking for the maven-javadoc-plugin version 2.5. I have version 2.8.1 > in my private archiva repository. Is there anyway I can specify when using > the release plugin to use a different version for one of its dependencies. > > 2. I do not think #1 is possible for a few reasons. As such is there a good > way to download a plugin and all of its dependencies so that I can bring them > over to a private repository? I think the problem here is that different > dependencies are pulled during different phases of the build, so unless I > actually run the plugin I am not sure I can get all the dependencies. Any > thoughts? > > Thanks, > Billy > > Sent from my iPhone > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Override plugin dependencies?
I have a couple of quick questions about plugins and their dependencies. I am on a private network so it is sometimes difficult to get a plugin and all it's dependencies. 1. I am trying to use the maven-release-plugin and during the deploy phase it is looking for the maven-javadoc-plugin version 2.5. I have version 2.8.1 in my private archiva repository. Is there anyway I can specify when using the release plugin to use a different version for one of its dependencies. 2. I do not think #1 is possible for a few reasons. As such is there a good way to download a plugin and all of its dependencies so that I can bring them over to a private repository? I think the problem here is that different dependencies are pulled during different phases of the build, so unless I actually run the plugin I am not sure I can get all the dependencies. Any thoughts? Thanks, Billy Sent from my iPhone - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Report Plugin Dependencies (Maven 3 style) for Site
Hello,
I wonder if you try to declare checktyle plugin too in build/plugins
section with your dependency.
That should works for maven3
2011/11/15 Nate Stoddard :
> I'm resending this because the formatting got butchered the first type.
> Sorry for the duplicate.
>
> Nate Stoddard
>
> =
>
> I'm trying to use the new Maven 3 style of generating reports, but I'm
> having problems with one in particular. I have some custom Checkstyle
> checks, but I'm not able to add the dependency in the right spot to make
> everything work. Here's part of my POM:
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.0-beta-3
>
>
> [deleted]
> checkstyle
> ${project.version}
>
>
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> 2.8
>
>
> [deleted]/checkstyle.xml
>
>
>
>
>
>
>
>
> In previous versions of Maven, I could add dependencies to the actual report
> plugin, but not anymore. Adding the dependency to the maven-site-plugin
> doesn't work since it's added to the wrong level of the classloader. In
> this case two classloaders are created: 1) maven-site-plugin, which is the
> parent classloader of 2) maven-checkstyle-plugin. The Checkstyle JAR is
> added to (2), so by adding my dependency to the the maven-site-plugin (1)
> things won't work because it can't reference the Checkstyle types in (2).
> Adding the Checkstyle JAR as an additional dependency doesn't work either
> since the types from different classloaders are incompatible. There's no
> way of adding the dependency such that it ends up in (2). I've tried
> configuring the plugin under the pluginManagement section also, but that
> seems to be ignored for the newest style.
>
> I'm just wondering if this is even possible, or if I need to roll back my
> reporting configurations to the older style until the newer one is fixed up
> and functioning better.
>
> Nate Stoddard
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Report Plugin Dependencies (Maven 3 style) for Site
I'm resending this because the formatting got butchered the first type.
Sorry for the duplicate.
Nate Stoddard
=
I'm trying to use the new Maven 3 style of generating reports, but I'm
having problems with one in particular. I have some custom Checkstyle
checks, but I'm not able to add the dependency in the right spot to make
everything work. Here's part of my POM:
org.apache.maven.plugins
maven-site-plugin
3.0-beta-3
[deleted]
checkstyle
${project.version}
org.apache.maven.plugins
maven-checkstyle-plugin
2.8
[deleted]/checkstyle.xml
In previous versions of Maven, I could add dependencies to the actual
report plugin, but not anymore. Adding the dependency to the
maven-site-plugin doesn't work since it's added to the wrong level of
the classloader. In this case two classloaders are created: 1)
maven-site-plugin, which is the parent classloader of 2)
maven-checkstyle-plugin. The Checkstyle JAR is added to (2), so by
adding my dependency to the the maven-site-plugin (1) things won't work
because it can't reference the Checkstyle types in (2). Adding the
Checkstyle JAR as an additional dependency doesn't work either since the
types from different classloaders are incompatible. There's no way of
adding the dependency such that it ends up in (2). I've tried
configuring the plugin under the pluginManagement section also, but that
seems to be ignored for the newest style.
I'm just wondering if this is even possible, or if I need to roll back
my reporting configurations to the older style until the newer one is
fixed up and functioning better.
Nate Stoddard
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Report Plugin Dependencies (Maven 3 style) for Site
I'm trying to use the new Maven 3 style of generating reports, but
I'm having problems with one in particular. I have some custom
Checkstyle checks, but I'm not able to add the dependency in the right
spot to make everything work. Here's part of my POM:
org.apache.maven.plugins
maven-site-plugin
3.0-beta-3
[deleted]
checkstyle
${project.version}
org.apache.maven.plugins
maven-checkstyle-plugin
2.8
[deleted]/checkstyle.xml
In previous
versions of Maven, I could add dependencies to the actual report plugin,
but not anymore. Adding the dependency to the maven-site-plugin doesn't
work since it's added to the wrong level of the classloader. In this
case two classloaders are created: 1) maven-site-plugin, which is the
parent classloader of 2) maven-checkstyle-plugin. The Checkstyle JAR is
added to (2), so by adding my dependency to the the maven-site-plugin
(1) things won't work because it can't reference the Checkstyle types in
(2). Adding the Checkstyle JAR as an additional dependency doesn't work
either since the types from different classloaders are incompatible.
There's no way of adding the dependency such that it ends up in (2).
I've tried configuring the plugin under the pluginManagement section
also, but that seems to be ignored for the newest style.
I'm just
wondering if this is even possible, or if I need to roll back my
reporting configurations to the older style until the newer one is fixed
up and functioning better.
Nate Stoddard
Re: reactor and plugin dependencies & the reactor
It is a bit hard to know what you want to do but it seems that you are using module (a) to build something that needs to be deployed to someplace prior to module (b) trying to use it. I guess that the trick it give Maven a property that tells Module A where to deploy the Antrun file and tells module (b) where to look for the file. This might be possible using a parent POM to define the property that both modules use to construct a location where the file can be put and found. I hope that this helps. Ron On 26/10/2011 12:17 PM, Benson Margulies wrote: I'd like to have a multi-module project in which module (a) builds the code of an ant task, and module (b) lists module (a) as a dependency of the antrun plugin to use it. I have a vague memory that this isn't going to work in the reactor. Can anyone tell me if I'm inventing a problem? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
reactor and plugin dependencies & the reactor
I'd like to have a multi-module project in which module (a) builds the code of an ant task, and module (b) lists module (a) as a dependency of the antrun plugin to use it. I have a vague memory that this isn't going to work in the reactor. Can anyone tell me if I'm inventing a problem? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
antrun plugin dependencies & parent pluginManagement
Hi all,
I have a parent pom that declares the antrun plugin in pluginManagement
section. It supplies a version, and a set of dependencies to fix the version
of Ant used.
I then have a child project that uses the antrun plugin and adds a reactor
library to the list of dependencies.
When the parent uses antrun 1.4, and the child overrides it to use 1.6,
everything works.
When the parent is upgraded to use 1.6, and the child either removes the
version, or continues to override with 1.6, the reactor library is not
included and the build fails.
a) Has anyone else run into this?
b) Is this scenario expected to work?
Parent pom section:
org.apache.maven.plugins
maven-antrun-plugin
1.4
ant-contrib
ant-contrib
1.0b3
ant
ant
org.apache.ant
ant
${ant.version}
org.apache.ant
ant-apache-regexp
${ant.version}
org.apache.ant
ant-nodeps
${ant.version}
Child pom section:
org.apache.maven.plugins
maven-antrun-plugin
1.6
com.mycompany.library
library
1.25-SNAPSHOT
Thanks!
-- Josh
Re: exclude plugin dependencies
Hi, You can use artifact exclusions for plugin dependencies as well. For example: ... ... kung.fu kick 1.2 com.foo bar Good luck, Martin -- View this message in context: http://maven.40175.n5.nabble.com/exclude-plugin-dependencies-tp4590474p4590488.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
exclude plugin dependencies
Hello, Is there any way how to exclude plugin dependency? I have parent pom with plugin ... org.apache.maven.plugins maven-checkstyle-plugin cz.autocont.internal Super_CheckStyle ... And in the child pom I have org.apache.maven.plugins maven-checkstyle-plugin cz.autocont.internal Specific_CheckStyle What I need is to remove depency from the parent pom. Why I am doing this. I have in the project Super_CheckStyle definitions of the checkstyle and suppressions. In the project Specific_Checkstyle is customized suppressions.xml file. Because of the maven lifecycle Super_CheckStyle project is used during child installation (mvn install). Am I able to force maven to use Specific_checkstyle project? Thanks for the help Vita
Plugin dependencies resolution - from repository or from pluginRepository?
Hello Maven users, Maven dependecy:resolve-plugins resolved plugin dependency from repository and not from pluginRepository. Isn't that a bug? Plugin used is http://code.google.com/p/maven-annotation-plugin/ , version 2.0.2. It's available at central but not all of it's dependencies are there (another failure of central repo policy just as repository declaration in plugin's pom but that's a different issue). That plugin has dependency to org.jfrog.maven.annomojo:maven-plugin-tools-anno:1.4.0 which can be found on http://repo.jfrog.org/artifactory/plugins-releases-local repository. When I added that repository as pluginRepository, maven would fail to resolve the plugin's dependencies, but when I added that repository as dependency repository, dependency:resolve-plugins would pass. I'm using Maven 3.0.3, and dependency plugin 2.1. Regards, Stevo. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: plugin dependencies at runtime
Adding pluginRepositories to my settings fixed it nicely. Thanks for the link, as well. On Thu, Mar 17, 2011 at 6:35 AM, Benjamin Bentmann < benjamin.bentm...@udo.edu> wrote: > Jason Nerothin wrote: > > The drools libs are out on the jboss snapshots repository and the >> connector >> lib is being staged in archiva. In both cases, they're sitting right where >> I >> expect them to be in my local repository. >> > > > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository > > A build has access to artifacts > a) that were locally built/installed or > b) that reside in any remote repo *configured* in the POM/settings > > So if your project cannot build from a clean local repo, you might want to > add the required *plugin* repositories to your POM/settings.xml. That still > failing, a JIRA issue with an example project is highly appreciated. > > > Benjamin > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: plugin dependencies at runtime
Jason Nerothin wrote: The drools libs are out on the jboss snapshots repository and the connector lib is being staged in archiva. In both cases, they're sitting right where I expect them to be in my local repository. https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository A build has access to artifacts a) that were locally built/installed or b) that reside in any remote repo *configured* in the POM/settings So if your project cannot build from a clean local repo, you might want to add the required *plugin* repositories to your POM/settings.xml. That still failing, a JIRA issue with an example project is highly appreciated. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
plugin dependencies at runtime
I'm in the process of building out my first plugin. The simple example worked fine, and I get it to build to my local repo with clean install. However, at runtime, it can't locate a handful of jars: [ERROR] Failed to execute goal com.xxx.xxx:xxx-maven-plugin:1.0:alive (default-cli) on project xxx: Execution default -cli of goal com.xxx.xxx:xxx-maven-plugin:1.0:alive failed: Plugin xxx.xxx.xxx:xxx-maven-plugin:1.0 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.drools:drools-api:jar:5.2.0.M1, o rg.drools:drools-core:jar:5.2.0.M1, org.drools:drools-compiler:jar:5.2.0.M1, org.drools:drools-templates:jar:5.2.0.M1, c om.xxx.3rdpartylibs:sqljdbc4:jar:1.0-PROVIDED: Could not find artifact org.drools:drools-api:jar:5.2.0.M1 in maven2-repo sitory.dev.java.net (http://download.java.net/maven/2) -> [Help 1] The drools libs are out on the jboss snapshots repository and the connector lib is being staged in archiva. In both cases, they're sitting right where I expect them to be in my local repository. Is maven getting nit-picky about the fact that they came out of a non-release build? I started wiring up the assembly plugin on my plugin's POM to stick the missing jars into a lib directory, but this didn't work, despite the jars being referenced in plugin.xml and the manifest file. When I run with --offline, I get: [WARNING] The POM for org.drools:drools-api:jar:5.2.0.M1 is missing, no dependency information available This is also not true. The POM is right there in my local repo. What am I missing here? JPN
Re: Chicken-and-egg problem: plugin dependencies as modules
Hi Stephen, The organizational pom can prescribe the use of the most recently released ruleset. The next version of the ruleset would "technically" be checked against the previous version, but as rulesets are not java code the check will not be applied on that artifact. True. But its a little bit tricky to get this setup off the ground in the first place: 1. Release version 1.0 of organizational POM (without m-pmd-p) 2. Release version 1.0 of ruleset (inheriting from organizational POM, version 1.0) 3. Release version 2.0 of organizational POM (with m-pmd-p and ruleset, version 1.0) And the ruleset is doomed to perpetually lag behind one version of the organizational POM. I think I like the two-parents solution better: the organizational POM is restricted to (plugin|dependency)Management, with the other parent binding plugins for real. Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
The organizational pom can prescribe the use of the most recently released ruleset. The next version of the ruleset would "technically" be checked against the previous version, but as rulesets are not java code the check will not be applied on that artifact. -Stephen On 17 December 2010 11:55, Andreas Sewe wrote: > Hi Wayne, > > thanks for the advice. > >>> What's the best way to resolve this kind of chicken-and-egg problem >>> without introducing too many extra projects just to break the cycle? Any >> >> This is exactly what you have to do. The rulesets should be packaged >> and versioned independent of the project. Ideally you'd have one >> corporate ruleset and all your various projects would just use it. > > But the ruleset project should inherit from the organizational POM -- as all > good projects in our organization do. Now, that would imply that the > organizational POM cannot prescribe the use of the ruleset, as this would > result in a cyclic dependency. > > What's the way out of this? Is something like the following considered best > practice? > > organizational POM > | > +-- ruleset > | > +-- project parent (configures p-pmd-plugin with "ruleset" dependency) > | > +-...- any other project that should be subject to m-pmd-d checks. > > Best wishes, > > Andreas > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
Hi Wayne, thanks for the advice. What's the best way to resolve this kind of chicken-and-egg problem without introducing too many extra projects just to break the cycle? Any This is exactly what you have to do. The rulesets should be packaged and versioned independent of the project. Ideally you'd have one corporate ruleset and all your various projects would just use it. But the ruleset project should inherit from the organizational POM -- as all good projects in our organization do. Now, that would imply that the organizational POM cannot prescribe the use of the ruleset, as this would result in a cyclic dependency. What's the way out of this? Is something like the following considered best practice? organizational POM | +-- ruleset | +-- project parent (configures p-pmd-plugin with "ruleset" dependency) | +-...- any other project that should be subject to m-pmd-d checks. Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Chicken-and-egg problem: plugin dependencies as modules
> What's the best way to resolve this kind of chicken-and-egg problem > without introducing too many extra projects just to break the cycle? Any This is exactly what you have to do. The rulesets should be packaged and versioned independent of the project. Ideally you'd have one corporate ruleset and all your various projects would just use it. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Chicken-and-egg problem: plugin dependencies as modules
Hi all, I am experiencing a kind of chicken-and-egg problem in my usage of the m-pmd-p, the m-checkstyle-p, and the m-license-p. All these plugins are capable of loading their respective configurations (rulesets or license headers) from the plugin's classpath. As such it seems sensible to create dedicated ruleset or license-header Maven projects, which the respective plugins then depend on. Problems start, however, if those ruleset or license-header projects are modules of a common parent project, which configures the respective plugins for all its descendants: parent (configures m-pmd-p with "ruleset" project as plugin dependency) | +-- ruleset | +-...- any other project that should be subject to m-pmd-d checks. This, of course, introduces a cycle in the projects dependencies; you cannot build "parent" without building "ruleset" first, which itself inherits from "parent". What's the best way to resolve this kind of chicken-and-egg problem without introducing too many extra projects just to break the cycle? Any best practices and recommendations? Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version range for plugin dependencies does not work?
On 16 August 2010 15:16, janne postilista wrote: > Heh. Not the first headache I have with this plugin... > > I'm curious, care to briefly explain what's the fundamental problem > with maven-glassfish-pluginwhy is having a plugin that depends on > another plugin a problem? > In Maven 2.x the first time a plugin is resolved, that version is the only version that is ever resolved, so when you have a dependency on another maven-plugin if a different version is used in a module earlier in the reactor, then you will not get the version you expect and all hell will break loose. The solution is to move the plugin heavy lifting code into a separate module (jar type) and then depend on that > > Does this somehow explain the mystery why the version range gets resolved > in > my windows environment but not in linux, or is this a separate issue? > > I don't think so On Mon, Aug 16, 2010 at 5:10 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Ohhh!!! > > > > You're using maven-glassfish-plugin well that explains it. > > > > Here is the golden rule. > > > > Friends don't let friends use the java.net maven repositories... > > > > Here is another bad example, they have a plugin that depends on another > > plugin... which will mess up big big big time unless you are using Maven > 3 > > (and even then its a bad plan) > > > > -Stephen > > > > On 16 August 2010 15:06, janne postilista > >wrote: > > > > > Thanks for the suggestion. This cured my build: > > > > > > > > >org.glassfish.maven.plugin > > >maven-glassfish-plugin > > >2.1 > > >... > > > > > > > > > > > >au.net.ocean.maven.plugin > > >maven-plugin > > >1.0 > > > > > > > > > org.apache.maven > > > > > > maven-plugin-api > > > > > > > > > > > > > > >org.apache.maven > > >maven-plugin-api > > >2.0 > > > > > > > > > > > > > > > Needless to say, this is ugly and it would be really really nice to > find > > > out > > > why version matching does not work on the linux maven build, when it > does > > > work on the windows build. > > > > > > > > > On Mon, Aug 16, 2010 at 5:03 PM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > you define the exclusions on your dependencies and that will purge > them > > > > from > > > > your entire dependency tree > > > > > > > > On 16 August 2010 14:49, janne postilista < > jannepostilis...@gmail.com > > > > >wrote: > > > > > > > > > I'm not sure what that means exactly? > > > > > > > > > > The problem is nested a few levels down in my dependencies: > > > > > > > > > > my webapp -> maven-glassfish-plugin -> maven-plugin -> > > maven-plugin-api > > > > > > > > > > maven-plugin's pom.xml has the problematic reference to > > > maven-plugin-api > > > > > version [2.0,) > > > > > > > > > > Is your suggestion still usable in this scenario? Can I define > > > exclusions > > > > > to > > > > > my dependencies dependencies? > > > > > > > > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:44 PM, Stephen Connolly < > > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > > > > > have you considered using exclusions to knock out the problematic > > > > > > transitive > > > > > > dep and then add in a corrected version for your own project > > > > > > > > > > > > On 16 August 2010 14:41, janne postilista < > > > jannepostilis...@gmail.com > > > > > > >wrote: > > > > > > > > > > > > > It's not the solution I want, but can I somehow tell in my > > pom.xml > > > > > > > that if a dependency has defined it's own dependency as: > > > > > > > > > > > > > > > > > > > > > org.apache.maven > > > > > > > maven-plugin-api > > > > > > > [2.0,) > > > > > > > compile > > > > > > > > > > > > > > > > > > > > > FORCE it to use 2.0 exactly? > > > > > > > > > > > > > > Tried adding to my pom.xml: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >org.apache.maven > > > > > > >maven-plugin-api > > > > > > >2.0 > > > > > > >compile > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > but it was of no help. > > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > > > > > > > wrote: > > > > > > > > And when I change my direct dependency in pom.xml > > > > > > > > > > > > > > > > from > > > > > > >
Re: Version range for plugin dependencies does not work?
Heh. Not the first headache I have with this plugin... I'm curious, care to briefly explain what's the fundamental problem with maven-glassfish-pluginwhy is having a plugin that depends on another plugin a problem? Does this somehow explain the mystery why the version range gets resolved in my windows environment but not in linux, or is this a separate issue? On Mon, Aug 16, 2010 at 5:10 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Ohhh!!! > > You're using maven-glassfish-plugin well that explains it. > > Here is the golden rule. > > Friends don't let friends use the java.net maven repositories... > > Here is another bad example, they have a plugin that depends on another > plugin... which will mess up big big big time unless you are using Maven 3 > (and even then its a bad plan) > > -Stephen > > On 16 August 2010 15:06, janne postilista >wrote: > > > Thanks for the suggestion. This cured my build: > > > > > >org.glassfish.maven.plugin > >maven-glassfish-plugin > >2.1 > >... > > > > > > > >au.net.ocean.maven.plugin > >maven-plugin > >1.0 > > > > > > org.apache.maven > > > > maven-plugin-api > > > > > > > > > >org.apache.maven > >maven-plugin-api > >2.0 > > > > > > > > > > Needless to say, this is ugly and it would be really really nice to find > > out > > why version matching does not work on the linux maven build, when it does > > work on the windows build. > > > > > > On Mon, Aug 16, 2010 at 5:03 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > you define the exclusions on your dependencies and that will purge them > > > from > > > your entire dependency tree > > > > > > On 16 August 2010 14:49, janne postilista > > >wrote: > > > > > > > I'm not sure what that means exactly? > > > > > > > > The problem is nested a few levels down in my dependencies: > > > > > > > > my webapp -> maven-glassfish-plugin -> maven-plugin -> > maven-plugin-api > > > > > > > > maven-plugin's pom.xml has the problematic reference to > > maven-plugin-api > > > > version [2.0,) > > > > > > > > Is your suggestion still usable in this scenario? Can I define > > exclusions > > > > to > > > > my dependencies dependencies? > > > > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:44 PM, Stephen Connolly < > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > > > have you considered using exclusions to knock out the problematic > > > > > transitive > > > > > dep and then add in a corrected version for your own project > > > > > > > > > > On 16 August 2010 14:41, janne postilista < > > jannepostilis...@gmail.com > > > > > >wrote: > > > > > > > > > > > It's not the solution I want, but can I somehow tell in my > pom.xml > > > > > > that if a dependency has defined it's own dependency as: > > > > > > > > > > > > > > > > > > org.apache.maven > > > > > > maven-plugin-api > > > > > > [2.0,) > > > > > > compile > > > > > > > > > > > > > > > > > > FORCE it to use 2.0 exactly? > > > > > > > > > > > > Tried adding to my pom.xml: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >org.apache.maven > > > > > >maven-plugin-api > > > > > >2.0 > > > > > >compile > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > but it was of no help. > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > > > > > > wrote: > > > > > > > And when I change my direct dependency in pom.xml > > > > > > > > > > > > > > from > > > > > > > > > > > > > > > > > > > > > org.apache.maven > > > > > > > maven-plugin-api > > > > > > > [2.0,) > > > > > > > compile > > > > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > > > > org.apache.maven > > > > > > > maven-plugin-api > > > > > > > 2.0 > > > > > > > compile > > > > > > > > > > > > > > > > > > > > > linux build finds the dependency from the repository fine. So > it > > > > seems > > > > > > that > > > > > > > > > > > > > > - linux maven for some reason cannot resolve > > > > [2.0,) > > > > > > > - windows maven can resolve [2.0,) > > > > > > > > > > > > > > Maven versions: > > > > > > > > > > > > > > C:\Windows\System32>mvn --version > > > > > > >
Re: Version range for plugin dependencies does not work?
Ohhh!!! You're using maven-glassfish-plugin well that explains it. Here is the golden rule. Friends don't let friends use the java.net maven repositories... Here is another bad example, they have a plugin that depends on another plugin... which will mess up big big big time unless you are using Maven 3 (and even then its a bad plan) -Stephen On 16 August 2010 15:06, janne postilista wrote: > Thanks for the suggestion. This cured my build: > > >org.glassfish.maven.plugin >maven-glassfish-plugin >2.1 >... > > > >au.net.ocean.maven.plugin >maven-plugin >1.0 > > > org.apache.maven > > maven-plugin-api > > > > >org.apache.maven >maven-plugin-api >2.0 > > > > > Needless to say, this is ugly and it would be really really nice to find > out > why version matching does not work on the linux maven build, when it does > work on the windows build. > > > On Mon, Aug 16, 2010 at 5:03 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > you define the exclusions on your dependencies and that will purge them > > from > > your entire dependency tree > > > > On 16 August 2010 14:49, janne postilista > >wrote: > > > > > I'm not sure what that means exactly? > > > > > > The problem is nested a few levels down in my dependencies: > > > > > > my webapp -> maven-glassfish-plugin -> maven-plugin -> maven-plugin-api > > > > > > maven-plugin's pom.xml has the problematic reference to > maven-plugin-api > > > version [2.0,) > > > > > > Is your suggestion still usable in this scenario? Can I define > exclusions > > > to > > > my dependencies dependencies? > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:44 PM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > have you considered using exclusions to knock out the problematic > > > > transitive > > > > dep and then add in a corrected version for your own project > > > > > > > > On 16 August 2010 14:41, janne postilista < > jannepostilis...@gmail.com > > > > >wrote: > > > > > > > > > It's not the solution I want, but can I somehow tell in my pom.xml > > > > > that if a dependency has defined it's own dependency as: > > > > > > > > > > > > > > > org.apache.maven > > > > > maven-plugin-api > > > > > [2.0,) > > > > > compile > > > > > > > > > > > > > > > FORCE it to use 2.0 exactly? > > > > > > > > > > Tried adding to my pom.xml: > > > > > > > > > > > > > > > > > > > > > > > > >org.apache.maven > > > > >maven-plugin-api > > > > >2.0 > > > > >compile > > > > > > > > > > > > > > > > > > > > > > > > > but it was of no help. > > > > > > > > > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > > > > > wrote: > > > > > > And when I change my direct dependency in pom.xml > > > > > > > > > > > > from > > > > > > > > > > > > > > > > > > org.apache.maven > > > > > > maven-plugin-api > > > > > > [2.0,) > > > > > > compile > > > > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > > org.apache.maven > > > > > > maven-plugin-api > > > > > > 2.0 > > > > > > compile > > > > > > > > > > > > > > > > > > linux build finds the dependency from the repository fine. So it > > > seems > > > > > that > > > > > > > > > > > > - linux maven for some reason cannot resolve > > > [2.0,) > > > > > > - windows maven can resolve [2.0,) > > > > > > > > > > > > Maven versions: > > > > > > > > > > > > C:\Windows\System32>mvn --version > > > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > > > > Java version: 1.6.0_14 > > > > > > Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre > > > > > > Default locale: fi_FI, platform encoding: Cp1252 > > > > > > OS name: "windows vista" version: "6.0" arch: "x86" Family: > > "windows" > > > > > > > > > > > > ]$ mvn --version > > > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > > > > Java version: 1.6.0_21 > > > > > > Java home: /usr/java/jdk1.6.0_21/jre > > > > > > Default locale: en_US, platform encoding: UTF-8 > > > > > > OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" > > Family: > > > > > "unix" > > > > > > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:24 PM, janne postilista > > > > > > wrote:
Re: Version range for plugin dependencies does not work?
Thanks for the suggestion. This cured my build: org.glassfish.maven.plugin maven-glassfish-plugin 2.1 ... au.net.ocean.maven.plugin maven-plugin 1.0 org.apache.maven maven-plugin-api org.apache.maven maven-plugin-api 2.0 Needless to say, this is ugly and it would be really really nice to find out why version matching does not work on the linux maven build, when it does work on the windows build. On Mon, Aug 16, 2010 at 5:03 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > you define the exclusions on your dependencies and that will purge them > from > your entire dependency tree > > On 16 August 2010 14:49, janne postilista >wrote: > > > I'm not sure what that means exactly? > > > > The problem is nested a few levels down in my dependencies: > > > > my webapp -> maven-glassfish-plugin -> maven-plugin -> maven-plugin-api > > > > maven-plugin's pom.xml has the problematic reference to maven-plugin-api > > version [2.0,) > > > > Is your suggestion still usable in this scenario? Can I define exclusions > > to > > my dependencies dependencies? > > > > > > > > On Mon, Aug 16, 2010 at 4:44 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > have you considered using exclusions to knock out the problematic > > > transitive > > > dep and then add in a corrected version for your own project > > > > > > On 16 August 2010 14:41, janne postilista > > >wrote: > > > > > > > It's not the solution I want, but can I somehow tell in my pom.xml > > > > that if a dependency has defined it's own dependency as: > > > > > > > > > > > > org.apache.maven > > > > maven-plugin-api > > > > [2.0,) > > > > compile > > > > > > > > > > > > FORCE it to use 2.0 exactly? > > > > > > > > Tried adding to my pom.xml: > > > > > > > > > > > > > > > > > > > >org.apache.maven > > > >maven-plugin-api > > > >2.0 > > > >compile > > > > > > > > > > > > > > > > > > > > but it was of no help. > > > > > > > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > > > > wrote: > > > > > And when I change my direct dependency in pom.xml > > > > > > > > > > from > > > > > > > > > > > > > > > org.apache.maven > > > > > maven-plugin-api > > > > > [2.0,) > > > > > compile > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > org.apache.maven > > > > > maven-plugin-api > > > > > 2.0 > > > > > compile > > > > > > > > > > > > > > > linux build finds the dependency from the repository fine. So it > > seems > > > > that > > > > > > > > > > - linux maven for some reason cannot resolve > > [2.0,) > > > > > - windows maven can resolve [2.0,) > > > > > > > > > > Maven versions: > > > > > > > > > > C:\Windows\System32>mvn --version > > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > > > Java version: 1.6.0_14 > > > > > Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre > > > > > Default locale: fi_FI, platform encoding: Cp1252 > > > > > OS name: "windows vista" version: "6.0" arch: "x86" Family: > "windows" > > > > > > > > > > ]$ mvn --version > > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > > > Java version: 1.6.0_21 > > > > > Java home: /usr/java/jdk1.6.0_21/jre > > > > > Default locale: en_US, platform encoding: UTF-8 > > > > > OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" > Family: > > > > "unix" > > > > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:24 PM, janne postilista > > > > > wrote: > > > > >> Thanks, but it doesn't seem to be a Hudson issue. > > > > >> > > > > >> Installed maven 2.2.1 (same as my local windows version) to the > > linux > > > > >> machine and trying the same build from there, I get: > > > > >> > > > > >> [INFO] > > > > > > > > > > >> [ERROR] BUILD ERROR > > > > >> [INFO] > > > > > > > > > > >> [INFO] Failed to resolve artifact. > > > > >> > > > > >> No versions are present in the repository for the artifact with a > > > range > > > > [2.0,) > > > > >> org.apache.maven:maven-plugin-api:jar:null > > > > >> > > > > >> from the
Re: Version range for plugin dependencies does not work?
you define the exclusions on your dependencies and that will purge them from your entire dependency tree On 16 August 2010 14:49, janne postilista wrote: > I'm not sure what that means exactly? > > The problem is nested a few levels down in my dependencies: > > my webapp -> maven-glassfish-plugin -> maven-plugin -> maven-plugin-api > > maven-plugin's pom.xml has the problematic reference to maven-plugin-api > version [2.0,) > > Is your suggestion still usable in this scenario? Can I define exclusions > to > my dependencies dependencies? > > > > On Mon, Aug 16, 2010 at 4:44 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > have you considered using exclusions to knock out the problematic > > transitive > > dep and then add in a corrected version for your own project > > > > On 16 August 2010 14:41, janne postilista > >wrote: > > > > > It's not the solution I want, but can I somehow tell in my pom.xml > > > that if a dependency has defined it's own dependency as: > > > > > > > > > org.apache.maven > > > maven-plugin-api > > > [2.0,) > > > compile > > > > > > > > > FORCE it to use 2.0 exactly? > > > > > > Tried adding to my pom.xml: > > > > > > > > > > > > > > >org.apache.maven > > >maven-plugin-api > > >2.0 > > >compile > > > > > > > > > > > > > > > but it was of no help. > > > > > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > > > wrote: > > > > And when I change my direct dependency in pom.xml > > > > > > > > from > > > > > > > > > > > > org.apache.maven > > > > maven-plugin-api > > > > [2.0,) > > > > compile > > > > > > > > > > > > to > > > > > > > > > > > > org.apache.maven > > > > maven-plugin-api > > > > 2.0 > > > > compile > > > > > > > > > > > > linux build finds the dependency from the repository fine. So it > seems > > > that > > > > > > > > - linux maven for some reason cannot resolve > [2.0,) > > > > - windows maven can resolve [2.0,) > > > > > > > > Maven versions: > > > > > > > > C:\Windows\System32>mvn --version > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > > Java version: 1.6.0_14 > > > > Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre > > > > Default locale: fi_FI, platform encoding: Cp1252 > > > > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" > > > > > > > > ]$ mvn --version > > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > > Java version: 1.6.0_21 > > > > Java home: /usr/java/jdk1.6.0_21/jre > > > > Default locale: en_US, platform encoding: UTF-8 > > > > OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" Family: > > > "unix" > > > > > > > > > > > > On Mon, Aug 16, 2010 at 4:24 PM, janne postilista > > > > wrote: > > > >> Thanks, but it doesn't seem to be a Hudson issue. > > > >> > > > >> Installed maven 2.2.1 (same as my local windows version) to the > linux > > > >> machine and trying the same build from there, I get: > > > >> > > > >> [INFO] > > > > > > > >> [ERROR] BUILD ERROR > > > >> [INFO] > > > > > > > >> [INFO] Failed to resolve artifact. > > > >> > > > >> No versions are present in the repository for the artifact with a > > range > > > [2.0,) > > > >> org.apache.maven:maven-plugin-api:jar:null > > > >> > > > >> from the specified remote repositories: > > > >> central (http://repo1.maven.org/maven2), > > > >> prime-repo (http://repository.prime.com.tr) > > > >> > > > >> Path to dependency: > > > >>1) zzz:webapp:war:1.0-SNAPSHOT > > > >> > > > >> I can't figure out why the same build fails on the linux box and > works > > > >> on my windows environment...I have tried telnetting repo1.maven.org > > > >> successfully. > > > >> > > > >> > > > >> On Mon, Aug 16, 2010 at 3:45 PM, Stephen Connolly > > > >> wrote: > > > >>> 1. This is a hudson issue so report on the hudson list. > > > >>> > > > >>> On 16 August 2010 12:54, janne postilista < > > jannepostilis...@gmail.com > > > >wrote: > > > >>> > > > My build craps out because > > > > > > [HUDSON] Archiving > > > /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to > > > > > > > > > > > > /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml > > > [INFO] > > > > > > > > > > [ERROR] BUILD ERROR > > > [INFO] > > > > > > > > > > [INFO] Failed to resolve artifact. > > > > > > No versions are present in the repository for
Re: Version range for plugin dependencies does not work?
I'm not sure what that means exactly? The problem is nested a few levels down in my dependencies: my webapp -> maven-glassfish-plugin -> maven-plugin -> maven-plugin-api maven-plugin's pom.xml has the problematic reference to maven-plugin-api version [2.0,) Is your suggestion still usable in this scenario? Can I define exclusions to my dependencies dependencies? On Mon, Aug 16, 2010 at 4:44 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > have you considered using exclusions to knock out the problematic > transitive > dep and then add in a corrected version for your own project > > On 16 August 2010 14:41, janne postilista >wrote: > > > It's not the solution I want, but can I somehow tell in my pom.xml > > that if a dependency has defined it's own dependency as: > > > > > > org.apache.maven > > maven-plugin-api > > [2.0,) > > compile > > > > > > FORCE it to use 2.0 exactly? > > > > Tried adding to my pom.xml: > > > > > > > > > >org.apache.maven > >maven-plugin-api > >2.0 > >compile > > > > > > > > > > but it was of no help. > > > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > > wrote: > > > And when I change my direct dependency in pom.xml > > > > > > from > > > > > > > > > org.apache.maven > > > maven-plugin-api > > > [2.0,) > > > compile > > > > > > > > > to > > > > > > > > > org.apache.maven > > > maven-plugin-api > > > 2.0 > > > compile > > > > > > > > > linux build finds the dependency from the repository fine. So it seems > > that > > > > > > - linux maven for some reason cannot resolve [2.0,) > > > - windows maven can resolve [2.0,) > > > > > > Maven versions: > > > > > > C:\Windows\System32>mvn --version > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > Java version: 1.6.0_14 > > > Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre > > > Default locale: fi_FI, platform encoding: Cp1252 > > > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" > > > > > > ]$ mvn --version > > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > > Java version: 1.6.0_21 > > > Java home: /usr/java/jdk1.6.0_21/jre > > > Default locale: en_US, platform encoding: UTF-8 > > > OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" Family: > > "unix" > > > > > > > > > On Mon, Aug 16, 2010 at 4:24 PM, janne postilista > > > wrote: > > >> Thanks, but it doesn't seem to be a Hudson issue. > > >> > > >> Installed maven 2.2.1 (same as my local windows version) to the linux > > >> machine and trying the same build from there, I get: > > >> > > >> [INFO] > > > > >> [ERROR] BUILD ERROR > > >> [INFO] > > > > >> [INFO] Failed to resolve artifact. > > >> > > >> No versions are present in the repository for the artifact with a > range > > [2.0,) > > >> org.apache.maven:maven-plugin-api:jar:null > > >> > > >> from the specified remote repositories: > > >> central (http://repo1.maven.org/maven2), > > >> prime-repo (http://repository.prime.com.tr) > > >> > > >> Path to dependency: > > >>1) zzz:webapp:war:1.0-SNAPSHOT > > >> > > >> I can't figure out why the same build fails on the linux box and works > > >> on my windows environment...I have tried telnetting repo1.maven.org > > >> successfully. > > >> > > >> > > >> On Mon, Aug 16, 2010 at 3:45 PM, Stephen Connolly > > >> wrote: > > >>> 1. This is a hudson issue so report on the hudson list. > > >>> > > >>> On 16 August 2010 12:54, janne postilista < > jannepostilis...@gmail.com > > >wrote: > > >>> > > My build craps out because > > > > [HUDSON] Archiving > > /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to > > > > > > > /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml > > [INFO] > > > > > > [ERROR] BUILD ERROR > > [INFO] > > > > > > [INFO] Failed to resolve artifact. > > > > No versions are present in the repository for the artifact with a > > range > > [2.0,) > > org.apache.maven:maven-plugin-api:jar:null > > > > from the specified remote repositories: > > maven2.dev.java.net (http://download.java.net/maven/2), > > central (http://repo1.maven.org/maven2), > > prime-repo (http://repository.prime.com.tr), > > snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), > > external.ocean.net.au (http://maven.ocean.net.au/external), > > >>>
Re: Version range for plugin dependencies does not work?
have you considered using exclusions to knock out the problematic transitive dep and then add in a corrected version for your own project On 16 August 2010 14:41, janne postilista wrote: > It's not the solution I want, but can I somehow tell in my pom.xml > that if a dependency has defined it's own dependency as: > > > org.apache.maven > maven-plugin-api > [2.0,) > compile > > > FORCE it to use 2.0 exactly? > > Tried adding to my pom.xml: > > > > >org.apache.maven >maven-plugin-api >2.0 >compile > > > > > but it was of no help. > > On Mon, Aug 16, 2010 at 4:29 PM, janne postilista > wrote: > > And when I change my direct dependency in pom.xml > > > > from > > > > > > org.apache.maven > > maven-plugin-api > > [2.0,) > > compile > > > > > > to > > > > > > org.apache.maven > > maven-plugin-api > > 2.0 > > compile > > > > > > linux build finds the dependency from the repository fine. So it seems > that > > > > - linux maven for some reason cannot resolve [2.0,) > > - windows maven can resolve [2.0,) > > > > Maven versions: > > > > C:\Windows\System32>mvn --version > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > Java version: 1.6.0_14 > > Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre > > Default locale: fi_FI, platform encoding: Cp1252 > > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" > > > > ]$ mvn --version > > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > > Java version: 1.6.0_21 > > Java home: /usr/java/jdk1.6.0_21/jre > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" Family: > "unix" > > > > > > On Mon, Aug 16, 2010 at 4:24 PM, janne postilista > > wrote: > >> Thanks, but it doesn't seem to be a Hudson issue. > >> > >> Installed maven 2.2.1 (same as my local windows version) to the linux > >> machine and trying the same build from there, I get: > >> > >> [INFO] > > >> [ERROR] BUILD ERROR > >> [INFO] > > >> [INFO] Failed to resolve artifact. > >> > >> No versions are present in the repository for the artifact with a range > [2.0,) > >> org.apache.maven:maven-plugin-api:jar:null > >> > >> from the specified remote repositories: > >> central (http://repo1.maven.org/maven2), > >> prime-repo (http://repository.prime.com.tr) > >> > >> Path to dependency: > >>1) zzz:webapp:war:1.0-SNAPSHOT > >> > >> I can't figure out why the same build fails on the linux box and works > >> on my windows environment...I have tried telnetting repo1.maven.org > >> successfully. > >> > >> > >> On Mon, Aug 16, 2010 at 3:45 PM, Stephen Connolly > >> wrote: > >>> 1. This is a hudson issue so report on the hudson list. > >>> > >>> On 16 August 2010 12:54, janne postilista >wrote: > >>> > My build craps out because > > [HUDSON] Archiving > /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to > > > /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml > [INFO] > > > [ERROR] BUILD ERROR > [INFO] > > > [INFO] Failed to resolve artifact. > > No versions are present in the repository for the artifact with a > range > [2.0,) > org.apache.maven:maven-plugin-api:jar:null > > from the specified remote repositories: > maven2.dev.java.net (http://download.java.net/maven/2), > central (http://repo1.maven.org/maven2), > prime-repo (http://repository.prime.com.tr), > snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), > external.ocean.net.au (http://maven.ocean.net.au/external), > release.ocean.net.au (http://maven.ocean.net.au/release), > java.net2 (http://download.java.net/maven/2) > > Path to dependency: > 1) > org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 > 2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 > > When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, > it > has > > > org.apache.maven > maven-plugin-api > [2.0,) > compile > > > and central repository has matching versions. Why doesn't maven find > it? Using maven 2.2.1 > > Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? > It seems to be since it'
Re: Version range for plugin dependencies does not work?
It's not the solution I want, but can I somehow tell in my pom.xml that if a dependency has defined it's own dependency as: org.apache.maven maven-plugin-api [2.0,) compile FORCE it to use 2.0 exactly? Tried adding to my pom.xml: org.apache.maven maven-plugin-api 2.0 compile but it was of no help. On Mon, Aug 16, 2010 at 4:29 PM, janne postilista wrote: > And when I change my direct dependency in pom.xml > > from > > > org.apache.maven > maven-plugin-api > [2.0,) > compile > > > to > > > org.apache.maven > maven-plugin-api > 2.0 > compile > > > linux build finds the dependency from the repository fine. So it seems that > > - linux maven for some reason cannot resolve [2.0,) > - windows maven can resolve [2.0,) > > Maven versions: > > C:\Windows\System32>mvn --version > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > Java version: 1.6.0_14 > Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre > Default locale: fi_FI, platform encoding: Cp1252 > OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" > > ]$ mvn --version > Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) > Java version: 1.6.0_21 > Java home: /usr/java/jdk1.6.0_21/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" Family: "unix" > > > On Mon, Aug 16, 2010 at 4:24 PM, janne postilista > wrote: >> Thanks, but it doesn't seem to be a Hudson issue. >> >> Installed maven 2.2.1 (same as my local windows version) to the linux >> machine and trying the same build from there, I get: >> >> [INFO] >> >> [ERROR] BUILD ERROR >> [INFO] >> >> [INFO] Failed to resolve artifact. >> >> No versions are present in the repository for the artifact with a range >> [2.0,) >> org.apache.maven:maven-plugin-api:jar:null >> >> from the specified remote repositories: >> central (http://repo1.maven.org/maven2), >> prime-repo (http://repository.prime.com.tr) >> >> Path to dependency: >> 1) zzz:webapp:war:1.0-SNAPSHOT >> >> I can't figure out why the same build fails on the linux box and works >> on my windows environment...I have tried telnetting repo1.maven.org >> successfully. >> >> >> On Mon, Aug 16, 2010 at 3:45 PM, Stephen Connolly >> wrote: >>> 1. This is a hudson issue so report on the hudson list. >>> >>> On 16 August 2010 12:54, janne postilista wrote: >>> My build craps out because [HUDSON] Archiving /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [2.0,) org.apache.maven:maven-plugin-api:jar:null from the specified remote repositories: maven2.dev.java.net (http://download.java.net/maven/2), central (http://repo1.maven.org/maven2), prime-repo (http://repository.prime.com.tr), snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), external.ocean.net.au (http://maven.ocean.net.au/external), release.ocean.net.au (http://maven.ocean.net.au/release), java.net2 (http://download.java.net/maven/2) Path to dependency: 1) org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, it has org.apache.maven maven-plugin-api [2.0,) compile and central repository has matching versions. Why doesn't maven find it? Using maven 2.2.1 Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? It seems to be since it's unresolved. But how could something this important remain unresolved for 3,5 years? PS. I have no idea why maven tries to retrieve the dependency. It's part of a child dependency's "compile scope" dependencies. No one is >>> >>> compile scope = at compile time and at runtime >>> provided scope = at compile time but not at runtime (because somebody else >>> will provide it) >>> runtime scope = not at compile time, but at runtime >>> >>> >>>
Re: Version range for plugin dependencies does not work?
And when I change my direct dependency in pom.xml from org.apache.maven maven-plugin-api [2.0,) compile to org.apache.maven maven-plugin-api 2.0 compile linux build finds the dependency from the repository fine. So it seems that - linux maven for some reason cannot resolve [2.0,) - windows maven can resolve [2.0,) Maven versions: C:\Windows\System32>mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) Java version: 1.6.0_14 Java home: C:\Program Files (x86)\Java\jdk1.6.0_14\jre Default locale: fi_FI, platform encoding: Cp1252 OS name: "windows vista" version: "6.0" arch: "x86" Family: "windows" ]$ mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300) Java version: 1.6.0_21 Java home: /usr/java/jdk1.6.0_21/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux" version: "2.6.18-194.8.1.el5" arch: "amd64" Family: "unix" On Mon, Aug 16, 2010 at 4:24 PM, janne postilista wrote: > Thanks, but it doesn't seem to be a Hudson issue. > > Installed maven 2.2.1 (same as my local windows version) to the linux > machine and trying the same build from there, I get: > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > No versions are present in the repository for the artifact with a range [2.0,) > org.apache.maven:maven-plugin-api:jar:null > > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > prime-repo (http://repository.prime.com.tr) > > Path to dependency: > 1) zzz:webapp:war:1.0-SNAPSHOT > > I can't figure out why the same build fails on the linux box and works > on my windows environment...I have tried telnetting repo1.maven.org > successfully. > > > On Mon, Aug 16, 2010 at 3:45 PM, Stephen Connolly > wrote: >> 1. This is a hudson issue so report on the hudson list. >> >> On 16 August 2010 12:54, janne postilista wrote: >> >>> My build craps out because >>> >>> [HUDSON] Archiving >>> /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to >>> >>> /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml >>> [INFO] >>> >>> [ERROR] BUILD ERROR >>> [INFO] >>> >>> [INFO] Failed to resolve artifact. >>> >>> No versions are present in the repository for the artifact with a range >>> [2.0,) >>> org.apache.maven:maven-plugin-api:jar:null >>> >>> from the specified remote repositories: >>> maven2.dev.java.net (http://download.java.net/maven/2), >>> central (http://repo1.maven.org/maven2), >>> prime-repo (http://repository.prime.com.tr), >>> snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), >>> external.ocean.net.au (http://maven.ocean.net.au/external), >>> release.ocean.net.au (http://maven.ocean.net.au/release), >>> java.net2 (http://download.java.net/maven/2) >>> >>> Path to dependency: >>> 1) >>> org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 >>> 2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 >>> >>> When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, it >>> has >>> >>> >>> org.apache.maven >>> maven-plugin-api >>> [2.0,) >>> compile >>> >>> >>> and central repository has matching versions. Why doesn't maven find >>> it? Using maven 2.2.1 >>> >>> Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? >>> It seems to be since it's unresolved. >>> >>> But how could something this important remain unresolved for 3,5 years? >>> >>> PS. I have no idea why maven tries to retrieve the dependency. It's >>> part of a child dependency's "compile scope" dependencies. No one is >>> >> >> compile scope = at compile time and at runtime >> provided scope = at compile time but not at runtime (because somebody else >> will provide it) >> runtime scope = not at compile time, but at runtime >> >> >>> trying to compile au.net.ocean.maven.plugin:maven-plugin:jar:1.0. >>> >>> PS2. This build works when I try it locally. Hudson does something >>> extra ([HUDSON] Archiving?) that wants the dependency. >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version range for plugin dependencies does not work?
Thanks, but it doesn't seem to be a Hudson issue. Installed maven 2.2.1 (same as my local windows version) to the linux machine and trying the same build from there, I get: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [2.0,) org.apache.maven:maven-plugin-api:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), prime-repo (http://repository.prime.com.tr) Path to dependency: 1) zzz:webapp:war:1.0-SNAPSHOT I can't figure out why the same build fails on the linux box and works on my windows environment...I have tried telnetting repo1.maven.org successfully. On Mon, Aug 16, 2010 at 3:45 PM, Stephen Connolly wrote: > 1. This is a hudson issue so report on the hudson list. > > On 16 August 2010 12:54, janne postilista wrote: > >> My build craps out because >> >> [HUDSON] Archiving >> /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to >> >> /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml >> [INFO] >> >> [ERROR] BUILD ERROR >> [INFO] >> >> [INFO] Failed to resolve artifact. >> >> No versions are present in the repository for the artifact with a range >> [2.0,) >> org.apache.maven:maven-plugin-api:jar:null >> >> from the specified remote repositories: >> maven2.dev.java.net (http://download.java.net/maven/2), >> central (http://repo1.maven.org/maven2), >> prime-repo (http://repository.prime.com.tr), >> snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), >> external.ocean.net.au (http://maven.ocean.net.au/external), >> release.ocean.net.au (http://maven.ocean.net.au/release), >> java.net2 (http://download.java.net/maven/2) >> >> Path to dependency: >> 1) >> org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 >> 2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 >> >> When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, it >> has >> >> >> org.apache.maven >> maven-plugin-api >> [2.0,) >> compile >> >> >> and central repository has matching versions. Why doesn't maven find >> it? Using maven 2.2.1 >> >> Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? >> It seems to be since it's unresolved. >> >> But how could something this important remain unresolved for 3,5 years? >> >> PS. I have no idea why maven tries to retrieve the dependency. It's >> part of a child dependency's "compile scope" dependencies. No one is >> > > compile scope = at compile time and at runtime > provided scope = at compile time but not at runtime (because somebody else > will provide it) > runtime scope = not at compile time, but at runtime > > >> trying to compile au.net.ocean.maven.plugin:maven-plugin:jar:1.0. >> >> PS2. This build works when I try it locally. Hudson does something >> extra ([HUDSON] Archiving?) that wants the dependency. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version range for plugin dependencies does not work?
1. This is a hudson issue so report on the hudson list. On 16 August 2010 12:54, janne postilista wrote: > My build craps out because > > [HUDSON] Archiving > /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to > > /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > No versions are present in the repository for the artifact with a range > [2.0,) > org.apache.maven:maven-plugin-api:jar:null > > from the specified remote repositories: > maven2.dev.java.net (http://download.java.net/maven/2), > central (http://repo1.maven.org/maven2), > prime-repo (http://repository.prime.com.tr), > snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), > external.ocean.net.au (http://maven.ocean.net.au/external), > release.ocean.net.au (http://maven.ocean.net.au/release), > java.net2 (http://download.java.net/maven/2) > > Path to dependency: >1) > org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 >2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 > > When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, it > has > > >org.apache.maven >maven-plugin-api >[2.0,) >compile > > > and central repository has matching versions. Why doesn't maven find > it? Using maven 2.2.1 > > Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? > It seems to be since it's unresolved. > > But how could something this important remain unresolved for 3,5 years? > > PS. I have no idea why maven tries to retrieve the dependency. It's > part of a child dependency's "compile scope" dependencies. No one is > compile scope = at compile time and at runtime provided scope = at compile time but not at runtime (because somebody else will provide it) runtime scope = not at compile time, but at runtime > trying to compile au.net.ocean.maven.plugin:maven-plugin:jar:1.0. > > PS2. This build works when I try it locally. Hudson does something > extra ([HUDSON] Archiving?) that wants the dependency. > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Version range for plugin dependencies does not work?
When I add this dependency directly to my pom.xml, build still works locally: org.apache.maven maven-plugin-api [2.0,) compile So it seems dependency version range resolving works after all. If I clear my repository before doing this, following versions appear after building: 2.0 2.0.6 2.0.11 3.0-beta-2 sheesh. Anyhow, local build, Windows + maven 2.2.1 is able to retrieve this dependency. When my Hudson build running on linux box (maven 2.2.1 "installed automatically from Apache", by Hudson) tries to do the same build it cannot find the dependency version: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [2.0,) org.apache.maven:maven-plugin-api:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), prime-repo (http://repository.prime.com.tr) Path to dependency: 1) com.gofore.valtimo:webapp:war:1.0-SNAPSHOT I checked that both machines can connect to http://repo1.maven.org/maven2. On Mon, Aug 16, 2010 at 2:54 PM, janne postilista wrote: > My build craps out because > > [HUDSON] Archiving > /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to > /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > No versions are present in the repository for the artifact with a range [2.0,) > org.apache.maven:maven-plugin-api:jar:null > > from the specified remote repositories: > maven2.dev.java.net (http://download.java.net/maven/2), > central (http://repo1.maven.org/maven2), > prime-repo (http://repository.prime.com.tr), > snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), > external.ocean.net.au (http://maven.ocean.net.au/external), > release.ocean.net.au (http://maven.ocean.net.au/release), > java.net2 (http://download.java.net/maven/2) > > Path to dependency: > 1) org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 > 2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 > > When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, it has > > > org.apache.maven > maven-plugin-api > [2.0,) > compile > > > and central repository has matching versions. Why doesn't maven find > it? Using maven 2.2.1 > > Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? > It seems to be since it's unresolved. > > But how could something this important remain unresolved for 3,5 years? > > PS. I have no idea why maven tries to retrieve the dependency. It's > part of a child dependency's "compile scope" dependencies. No one is > trying to compile au.net.ocean.maven.plugin:maven-plugin:jar:1.0. > > PS2. This build works when I try it locally. Hudson does something > extra ([HUDSON] Archiving?) that wants the dependency. > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Version range for plugin dependencies does not work?
My build craps out because [HUDSON] Archiving /home/zzz/.hudson/jobs/ci-build/workspace/trunk/webapp/pom.xml to /home/zzz/.hudson/jobs/ci-build/modules/zzz$webapp/builds/2010-08-16_14-27-53/archive/zzz/webapp/1.0-SNAPSHOT/pom.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [2.0,) org.apache.maven:maven-plugin-api:jar:null from the specified remote repositories: maven2.dev.java.net (http://download.java.net/maven/2), central (http://repo1.maven.org/maven2), prime-repo (http://repository.prime.com.tr), snapshot.ocean.net.au (http://maven.ocean.net.au/snapshot), external.ocean.net.au (http://maven.ocean.net.au/external), release.ocean.net.au (http://maven.ocean.net.au/release), java.net2 (http://download.java.net/maven/2) Path to dependency: 1) org.glassfish.maven.plugin:maven-glassfish-plugin:maven-plugin:2.1 2) au.net.ocean.maven.plugin:maven-plugin:jar:1.0 When I look at au.net.ocean.maven.plugin:maven-plugin:jar:1.0 pom.xml, it has org.apache.maven maven-plugin-api [2.0,) compile and central repository has matching versions. Why doesn't maven find it? Using maven 2.2.1 Is this problem still alive http://jira.codehaus.org/browse/MNG-2742? It seems to be since it's unresolved. But how could something this important remain unresolved for 3,5 years? PS. I have no idea why maven tries to retrieve the dependency. It's part of a child dependency's "compile scope" dependencies. No one is trying to compile au.net.ocean.maven.plugin:maven-plugin:jar:1.0. PS2. This build works when I try it locally. Hudson does something extra ([HUDSON] Archiving?) that wants the dependency. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Issues with plugin dependencies
We are all mortals...:-) However, it looks like it has been fixed in 3.0-alpha-1. Mike, try 3.0-alpha-5! When you've tried it, there is no going back...:-) http://www.sonatype.com/people/2009/11/maven-30-new-and-improved-formula/ /Anders On Tue, Dec 8, 2009 at 06:55, Wayne Fay wrote: > > Child project 2 has the exact same setup "however" it changes the > dependency > > defined in the plugin to be dependent on a different project. > > > > configurations. It always seems that the first time a plugin is loaded > that > > is the classpath used for that plugin whenever it is executed. > > This is a (very well) known bug in Maven 2. The "first" declaration of > a plugin's dependencies "wins" (as plugin containers are initialized > once per build) so you need to include all dependencies for all uses > of a given plugin in the "first" declaration. See JIRA: > http://jira.codehaus.org/browse/MNG-1949 > > I'm actually surprised Anders didn't know this one... ;-) > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Issues with plugin dependencies
> Child project 2 has the exact same setup "however" it changes the dependency > defined in the plugin to be dependent on a different project. > > configurations. It always seems that the first time a plugin is loaded that > is the classpath used for that plugin whenever it is executed. This is a (very well) known bug in Maven 2. The "first" declaration of a plugin's dependencies "wins" (as plugin containers are initialized once per build) so you need to include all dependencies for all uses of a given plugin in the "first" declaration. See JIRA: http://jira.codehaus.org/browse/MNG-1949 I'm actually surprised Anders didn't know this one... ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Issues with plugin dependencies
I haven't run into this use case, but I would think it should work. Have you tried other Maven versions like 2.0.x? Also, I would strongly suggest you try out 3.0-alpha-5. My experience is that errors that I've run into with the 2.x code is fixed in 3.0. /Anders On Mon, Dec 7, 2009 at 23:29, Mike Olson wrote: > > Hello, > > This is with Maven 2.2.1. > > I have an aggregate POM file that contains 2 child projects, say project A > and project B. > > Each of these child projects uses a custom build plugin. Project A calls > it like > > > > > myGrupId > myArtifactId > 1.0 > > > my-dep-1-group > my-dep-1-artifactId > my-dep-1-version > data > compile > > > > param > > > > EXEC1 > generate-sources > > generate-code > > > param2 > > > > > > > > Basically it invokes a custom MOJO in the generate-sources phase. The > plugin uses information on the classpath (among other things) to determine > what code to generate. > > Child project 2 has the exact same setup "however" it changes the > dependency defined in the plugin to be dependent on a different project. > > When I build each project individually, they build perfectly fine. > However, when I build the aggregate project, child project 2 fails because > it is using the dependencies of the first project. I have verified this > with various dumps of the class path, etc. I have tried inheriting the > plugin information, separate plugin definitions in the child project, many > configurations. It always seems that the first time a plugin is loaded that > is the classpath used for that plugin whenever it is executed. > > Is this a bug? I would have expected the inline dependencies to work just > like the configuration section of a plugin, basically it is for that > invocation only. > > If this is not a bug, how should I be invoking the same plugin twice, with > different class paths, within the same build. > > Thank > Mike > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Issues with plugin dependencies
Hello, This is with Maven 2.2.1. I have an aggregate POM file that contains 2 child projects, say project A and project B. Each of these child projects uses a custom build plugin. Project A calls it like myGrupId myArtifactId 1.0 my-dep-1-group my-dep-1-artifactId my-dep-1-version data compile param EXEC1 generate-sources generate-code param2 Basically it invokes a custom MOJO in the generate-sources phase. The plugin uses information on the classpath (among other things) to determine what code to generate. Child project 2 has the exact same setup "however" it changes the dependency defined in the plugin to be dependent on a different project. When I build each project individually, they build perfectly fine. However, when I build the aggregate project, child project 2 fails because it is using the dependencies of the first project. I have verified this with various dumps of the class path, etc. I have tried inheriting the plugin information, separate plugin definitions in the child project, many configurations. It always seems that the first time a plugin is loaded that is the classpath used for that plugin whenever it is executed. Is this a bug? I would have expected the inline dependencies to work just like the configuration section of a plugin, basically it is for that invocation only. If this is not a bug, how should I be invoking the same plugin twice, with different class paths, within the same build. Thank Mike - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugin Dependencies
> parent pom in one process the plugin seems to get stuck on the plugin > dependencies defined in the first module executed. Subsequent plugin > dependency configurations are ignored. It feels like this is an issue with > the underlying Maven dependency mechanism and not with the Flex-Mojos > plugin. We're using the latest Maven 2.2.1 release. You're right about what you're seeing, and this is how Maven2 currently works. You need to copy all your plugin deps (needed for all executions of that plugin across all modules etc) into the "first" declaration of that plugin which is executed -- the easiest is to just consolidate and copy the deps to each one. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Plugin Dependencies
known issue. I don't recall the JIRA 2009/11/12 Tim Fulmer : > Hi All, > > We've run into a slight issue with plugin dependencies. We're using plugin > dependencies to configure the version of Flex to use in several Flex modules > with the Flex-Mojos plugin. The idea is we need to support two different > versions of Flex, v3.4 and v4.0. This works fine as long as the different > versions are run in separate Maven processes. However, when run from a > parent pom in one process the plugin seems to get stuck on the plugin > dependencies defined in the first module executed. Subsequent plugin > dependency configurations are ignored. It feels like this is an issue with > the underlying Maven dependency mechanism and not with the Flex-Mojos > plugin. We're using the latest Maven 2.2.1 release. > > This affects our ability to do easy releases of the entire platform and > complicates our module structure greatly. I have a test project available > if that would help. > > Please advise, > > -- Tim > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Plugin Dependencies
Hi All, We've run into a slight issue with plugin dependencies. We're using plugin dependencies to configure the version of Flex to use in several Flex modules with the Flex-Mojos plugin. The idea is we need to support two different versions of Flex, v3.4 and v4.0. This works fine as long as the different versions are run in separate Maven processes. However, when run from a parent pom in one process the plugin seems to get stuck on the plugin dependencies defined in the first module executed. Subsequent plugin dependency configurations are ignored. It feels like this is an issue with the underlying Maven dependency mechanism and not with the Flex-Mojos plugin. We're using the latest Maven 2.2.1 release. This affects our ability to do easy releases of the entire platform and complicates our module structure greatly. I have a test project available if that would help. Please advise, -- Tim
Re: [m2] multi-project with plugin dependencies fails to build
afaik, no you can use a previous version of the plugin, but not the same version as is built in your reactor. the reason is that maven needs do determine the build plan before it starts, and your (as yet uncompiled) plugin in the reactor therefore has an unknown effect on the build, resulting in a circular reference at which point maven bombs out Sent from my [rhymes with tryPod] ;-) On 10 Oct 2009, at 07:50, Adrian Herscu wrote: Hi all, I am trying to set up a multi-project build in which one module depends on the Maven plugin created by other module. So far, the only way I could build the project is by building the Maven plugin module and then activate the multi-project build. Is there any possibility to define the plugin dependency? Adrian. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[m2] multi-project with plugin dependencies fails to build
Hi all, I am trying to set up a multi-project build in which one module depends on the Maven plugin created by other module. So far, the only way I could build the project is by building the Maven plugin module and then activate the multi-project build. Is there any possibility to define the plugin dependency? Adrian. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Resolving plugin dependencies
Hello, I'm trying to create a plugin that can either run in process or run in a separate process. To run in a separate process I need to examine the plugins dependencies and resolve them in case they have been overridden in the pom. For instance, I want to be able to do com.3levers.maven.plugins my-maven-plugin 1.0-SNAPSHOT false Which has a dependency on dependency.groupId:artifactId:1.1 I'd like to allow users to define their own version of the dependency such as com.3levers.maven.plugins my-maven-plugin 1.0-SNAPSHOT false dependency.groupId artifactId 1.2 To do that, I need to somehow be able to find the overridden dependencies version. I'll now the groupId and artifactId ahead of time and be able to hardcode them in the plugin. I just haven't been able to figure out how to get that version, of even better the artifact itself, and all of it's dependencies so I can build the classpath for the forked process. I've tried using the MavenProject.getPluginArtifacts() but that only gives me the plugin artifacts and I can't get the plugins dependencies from that. Is there any way I can do this or do I have to settle with the plugin dependency version not being overrideable? Thanks, Rich - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Adding plugin dependencies via a profile
My current solution, since this declaration is being made in a parent pom, is to declare the plugin with the custom rule dependency in the parent's build, and then the execution in the profile named 'release'. This allows children to define additional executions while preserving the dependency on the custom rule. jaxzin wrote: > > I'm writing a custom enforcer rule to enforce that my build contains no > snapshot dependencies. I only want to run the rule in a profile call > 'release'. But since I'm already using the enforcer plugin in my build > outside the profile it can't find my custom rule if I declare the plugin > dependency within the profile. I see a couple dead threads related to > this issue but no resolution. Does Maven allow you to override or append > a plugin's dependencies using a profile? How have people gotten around > this issue when enforcing custom rules? > -- View this message in context: http://www.nabble.com/Adding-plugin-dependencies-via-a-profile-tp19094340p19096205.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding plugin dependencies via a profile
I'm writing a custom enforcer rule to enforce that my build contains no snapshot dependencies. I only want to run the rule in a profile call 'release'. But since I'm already using the enforcer plugin in my build outside the profile it can't find my custom rule if I declare the plugin dependency within the profile. I see a couple dead threads related to this issue but no resolution. Does Maven allow you to override or append a plugin's dependencies using a profile? How have people gotten around this issue when enforcing custom rules? -- View this message in context: http://www.nabble.com/Adding-plugin-dependencies-via-a-profile-tp19094340p19094340.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
plugin dependencies in local repository
when I execute maven, it will download all project dependencies to the local repository, including the required plugins: e.g. the org.codehouse..mojo:findbugs-maven-plugin:maven-plugin:2.0-SNAPSHOT will be copied to my local repository. but this plugin itself depends on junit 3.8.2 when I execute 'mvn install' (or whatever goal) it works fine, but I wonder why junit 3.8.2 is NOT copied to my local repository. is it because I am using a SNAPSHOT version of the findbugs maven plugin? or do I need to do some config, so that maven will also fetch the dependencies of the maven-plugins? this is important for me, because I usually want to run maven in offlinemode (mvn -o), because my networkconnection is quite slow. and in this case, the offline build will stop, because junit 3.8.2 is missing any comments welcome thanks in advance - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
plugin dependencies between two modules
Hi, I have a project that has two child modules and a parent module. The child modules both use the same plugin, but have different plugin dependencies. If I run each child module separately, everything buids fine. If I build the child modules as part of the parent modules build, it fails due to the second modules dependencies being set to the first modules dependencies. ie (see below), if module 1 builds first and then module 2, module 2 won't be able to find any of the bar classes Any thoughts on how to get around this? Module 1: example example-plugin Module 2: example example-plugin BAR BAR - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
