You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Reinhard Nägele <re...@mgm-tp.com> on 2013/02/11 10:17:52 UTC
Dependency resolution kicks in too early
Hello,
A couple of years ago I used a plugin execution in the validate phase to
bootstrap jars that were not available on Maven Central as suggested in
[1]. I needed to do the same thing again today but noticed that this
approach does not seem to work any more with Maven 3. Right after
running Maven, dependency resolution kicks in making the build fail even
before the install plugin gets a chance to install the missing
dependency. Here's what I'm doing:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>boostrap-some-depencency</id>
<goals>
<goal>install-file</goal>
</goals>
<phase>validate</phase>
<configuration>
<groupId>com.some.groupid</groupId>
<artifactId>some-artifact</artifactId>
<version>${some.artifact.version}</version>
<packaging>jar</packaging>
<file>bootstrap-lib/some-artifact-${some.artifact.version}.jar</file>
<sources>bootstrap-lib/some-artifact-${some.artifact.version}-sources.jar</sources>
</configuration>
</execution>
</executions>
</plugin>
...
<dependency>
<groupId>com.some.groupid</groupId>
<artifactId>some-artifact</artifactId>
<version>${some.artifact.version}</version>
</dependency>
...
<properties>
<some.artifact.version>1.2.3</some.artifact.version>
</properties>
[1]
http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
Is this no longer possible? I'd really prefer this approach over using a
system dependency.
Thanks,
Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency resolution kicks in too early
Posted by Hilco Wijbenga <hi...@gmail.com>.
On 11 February 2013 01:17, Reinhard Nägele <re...@mgm-tp.com> wrote:
> A couple of years ago I used a plugin execution in the validate phase to
> bootstrap jars that were not available on Maven Central as suggested in [1].
> I needed to do the same thing again today but noticed that this approach
> does not seem to work any more with Maven 3. Right after running Maven,
> dependency resolution kicks in making the build fail even before the install
> plugin gets a chance to install the missing dependency. Here's what I'm
> doing:
>
<snip/>
> [1]
> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
>
> Is this no longer possible? I'd really prefer this approach over using a
> system dependency.
You can probably do this (or something very similar) using a multi-module build.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency resolution kicks in too early
Posted by Stephen Connolly <st...@gmail.com>.
On 14 February 2013 08:45, Reinhard Nägele <re...@mgm-tp.com>wrote:
> I don't think it is a good idea to pollute Maven Central with this
> artifact under a different groupId.
>
>
Nor do I, except when it is necessary... the old advice was to do it that
way... the new advice is that it should be a last resort... this is largely
a result of the lack of a <provides> mechanism in pom v4.0.0, which forces
an almighty collection of <excludes> on people... when I do push things to
central under my group Id you will find that I have the source code public
and in my github repo, so in a sense I am maintaining a fork of the
project.
In the case of https://github.com/stephenc/redmine-java-api this is now a
complete fork as I disagree with how the forked project has implemented
some features, and at some point in time I will rejig the back end to be
based off of async-http-client, so there is a legitimate reason for the
alternate groupId (given that the two artifacts are not equivalent)
If you are going to publish something under your own groupId you should at
least be ensuring that the source repository of what you are publishing is
available as anonymous read and independent of the "original" project as
then it is clear that you are maintaining a fork.
One of the features I would like to get into POM v5.0.0 is the idea of a
"provides" mechanism...
Thus one could indicate that
<dependency>
<groupId>org.apache.geronimo.specs</groupId>
<artifactId>geronimo-servlet_2.5_spec</artifactId>
<version>1.2</version>
<provides>
<provide>
<groupId>org.apache.tomcat</groupId>
<artifactId>servlet-api</artifactId>
<provide>
<provide>
<groupId>org.mortbay.jetty</groupId>
<artifactId>servlet-api</artifactId>
<provide>
</provides>
</dependency>
And the org.apache.geronimo.specs:geronimo-servlet_2.5_spec pom itself may
indicate that it provides javax.servlet:servlet-api
Not that I am saying that is how it would work... but in essence some
feature like the above is required.
My thinking is that a POM would have a <provides> element equivalent to a
<dependencies> where it listed the "apis" that this module provides,
additionally you can add additional entries to the project's list when you
pull it in as a dependency, because there is no way for a project to know
up front all the GroupId:ArtifactIds that it provides... and this would
just be <exclusions> done "right".
The harder part is mapping <provides> onto transitive consumers who are
using POM 4.0.0 parsers... but in a sense they are no worse off at the
moment, as long as the 4.0.0 compatible POM that we push to the repo as
part of the POM 5.0.0 deploy pins the dependency version (i.e. removing
ranges) it can add the necessary exclusions on its dependencies so that the
transitives injected into the consuming projects tree will be as clean as
it can inject them... IOW the consumer will be no worse off.
> Reinhard
>
> Am 13.02.2013 17:09, schrieb Stephen Connolly:
>
> Yes, I agree, but I have had to do it myself some times... in more radical
>> cases this has evolved into a complete fork for me (e.g. redmine-java-api)
>>
>>
>> On 13 February 2013 15:33, Anders Hammar <an...@hammar.net> wrote:
>>
>> Right, I was thinking they would deploy it to their Nexus instance where
>>> they deploy their own oss product.
>>> Having the same jar in two different groupIds in central only confuses
>>> people and causes problems I think. We should try to avoid that.
>>>
>>> /Anders
>>>
>>>
>>> On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.**com <st...@gmail.com>>
>>> wrote:
>>>
>>> On 13 February 2013 15:19, Anders Hammar <an...@hammar.net> wrote:
>>>>
>>>> deploy it to your own groupId
>>>>>>
>>>>>> Isn't it better if he uses the original groupId and artifactId, but
>>>>>
>>>> adds
>>>
>>>> a
>>>>
>>>>> qualifier to the version indicating that it's their release?
>>>>>
>>>>
>>>> Well... the chain you have to go when deploying something into central
>>>> under a groupId that you do not own is something like:
>>>>
>>>> 1. Show that you have engaged the owning project and that they are not
>>>> pushing a version
>>>> 2. Show blah blah blah
>>>> 3.
>>>> 4.
>>>> 5. Ok, create the bundle and upload it
>>>>
>>>> And given that he said the owning project is working on uploading to
>>>> central, he's going to fail on step 1... so if it is urgent the lesser
>>>>
>>> evil
>>>
>>>> is his own groupId...
>>>>
>>>> That said it would be best to keep the groupId it will end up with.
>>>>
>>>>
>>>> Like if he
>>>>> would have patched an official release.
>>>>>
>>>>> /Anders
>>>>>
>>>>>
>>>>>
>>>>>> On 13 February 2013 14:54, Reinhard Nägele <
>>>>>>
>>>>> reinhard.naegele@mgm-tp.com
>>>>
>>>>> wrote:
>>>>>>> Normally, I'd deploy it to our Nexus. But in this case, this is not
>>>>>>> possible. We are open-sourcing one of our products and need a
>>>>>>>
>>>>>> third-party
>>>>>
>>>>>> dependency which is not yet available on Maven Central. We are
>>>>>>>
>>>>>> working
>>>>
>>>>> with
>>>>>>
>>>>>>> the developer of the library to fix this, but until this is the
>>>>>>>
>>>>>> case,
>>>
>>>> we
>>>>>
>>>>>> need a temporary solution.
>>>>>>>
>>>>>>> Reinhard
>>>>>>>
>>>>>>>
>>>>>>> Am 11.02.2013 15:27, schrieb Ron Wheeler:
>>>>>>>
>>>>>>> Why not just load these stray orphans into your MRM once and then
>>>>>>>
>>>>>> treat
>>>>>
>>>>>> them and normal dependencies.
>>>>>>>>
>>>>>>>> Ron
>>>>>>>>
>>>>>>>> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> A couple of years ago I used a plugin execution in the validate
>>>>>>>>>
>>>>>>>> phase
>>>>
>>>>> to
>>>>>>
>>>>>>> bootstrap jars that were not available on Maven Central as
>>>>>>>>>
>>>>>>>> suggested
>>>>
>>>>> in
>>>>>
>>>>>> [1]. I needed to do the same thing again today but noticed that
>>>>>>>>>
>>>>>>>> this
>>>>
>>>>> approach does not seem to work any more with Maven 3. Right after
>>>>>>>>>
>>>>>>>> running
>>>>>>
>>>>>>> Maven, dependency resolution kicks in making the build fail even
>>>>>>>>>
>>>>>>>> before the
>>>>>>
>>>>>>> install plugin gets a chance to install the missing dependency.
>>>>>>>>>
>>>>>>>> Here's
>>>>>
>>>>>> what
>>>>>>
>>>>>>> I'm doing:
>>>>>>>>>
>>>>>>>>> <plugin>
>>>>>>>>> <groupId>org.apache.maven.****plugins</groupId>
>>>>>>>>> <artifactId>maven-install-****plugin</artifactId>
>>>>>>>>> <executions>
>>>>>>>>> <execution>
>>>>>>>>> <id>boostrap-some-depencency</****id>
>>>>>>>>> <goals>
>>>>>>>>> <goal>install-file</goal>
>>>>>>>>> </goals>
>>>>>>>>> <phase>validate</phase>
>>>>>>>>> <configuration>
>>>>>>>>> <groupId>com.some.groupid</****groupId>
>>>>>>>>> <artifactId>some-artifact</****artifactId>
>>>>>>>>> <version>${some.artifact.****version}</version>
>>>>>>>>> <packaging>jar</packaging>
>>>>>>>>> <file>bootstrap-lib/some-****artifact-${some.artifact.**
>>>>>>>>> version}.jar</file>
>>>>>>>>>
>>>>>>>>> <sources>bootstrap-lib/some-****artifact-${some.artifact.****
>>> version}-sources.jar</sources>
>>>
>>>> </configuration>
>>>>>>>>> </execution>
>>>>>>>>> </executions>
>>>>>>>>> </plugin>
>>>>>>>>> ...
>>>>>>>>> <dependency>
>>>>>>>>> <groupId>com.some.groupid</****groupId>
>>>>>>>>> <artifactId>some-artifact</****artifactId>
>>>>>>>>> <version>${some.artifact.****version}</version>
>>>>>>>>> </dependency>
>>>>>>>>> ...
>>>>>>>>> <properties>
>>>>>>>>> <some.artifact.version>1.2.3</****some.artifact.version>
>>>>>>>>> </properties>
>>>>>>>>>
>>>>>>>>> [1] http://www.blackbit.be/2010/****04/15/maven-automatically-**<http://www.blackbit.be/2010/**04/15/maven-automatically-**>
>>>>>>>>> install-dependencies-during-****build/<
>>>>>>>>>
>>>>>>>> http://www.blackbit.be/2010/**04/15/maven-automatically-**
>>> install-dependencies-during-**build/<http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/>
>>>
>>>> Is this no longer possible? I'd really prefer this approach over
>>>>>>>>>
>>>>>>>> using
>>>>>
>>>>>> a
>>>>>>
>>>>>>> system dependency.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Reinhard
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------****----------------------------**
>>>>>>>>> --**
>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>>>>>> <
>>>>>>>>>
>>>>>>>> users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>>>>> >
>>>>>>
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------****----------------------------**
>>> --**---------
>>>
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>>>>>> <
>>>>>>>
>>>>>> users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>>>>> >
>>>>>>
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Dependency resolution kicks in too early
Posted by Reinhard Nägele <re...@mgm-tp.com>.
I don't think it is a good idea to pollute Maven Central with this
artifact under a different groupId.
Reinhard
Am 13.02.2013 17:09, schrieb Stephen Connolly:
> Yes, I agree, but I have had to do it myself some times... in more radical
> cases this has evolved into a complete fork for me (e.g. redmine-java-api)
>
>
> On 13 February 2013 15:33, Anders Hammar <an...@hammar.net> wrote:
>
>> Right, I was thinking they would deploy it to their Nexus instance where
>> they deploy their own oss product.
>> Having the same jar in two different groupIds in central only confuses
>> people and causes problems I think. We should try to avoid that.
>>
>> /Anders
>>
>>
>> On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> On 13 February 2013 15:19, Anders Hammar <an...@hammar.net> wrote:
>>>
>>>>> deploy it to your own groupId
>>>>>
>>>> Isn't it better if he uses the original groupId and artifactId, but
>> adds
>>> a
>>>> qualifier to the version indicating that it's their release?
>>>
>>> Well... the chain you have to go when deploying something into central
>>> under a groupId that you do not own is something like:
>>>
>>> 1. Show that you have engaged the owning project and that they are not
>>> pushing a version
>>> 2. Show blah blah blah
>>> 3.
>>> 4.
>>> 5. Ok, create the bundle and upload it
>>>
>>> And given that he said the owning project is working on uploading to
>>> central, he's going to fail on step 1... so if it is urgent the lesser
>> evil
>>> is his own groupId...
>>>
>>> That said it would be best to keep the groupId it will end up with.
>>>
>>>
>>>> Like if he
>>>> would have patched an official release.
>>>>
>>>> /Anders
>>>>
>>>>
>>>>>
>>>>> On 13 February 2013 14:54, Reinhard Nägele <
>>> reinhard.naegele@mgm-tp.com
>>>>>> wrote:
>>>>>> Normally, I'd deploy it to our Nexus. But in this case, this is not
>>>>>> possible. We are open-sourcing one of our products and need a
>>>> third-party
>>>>>> dependency which is not yet available on Maven Central. We are
>>> working
>>>>> with
>>>>>> the developer of the library to fix this, but until this is the
>> case,
>>>> we
>>>>>> need a temporary solution.
>>>>>>
>>>>>> Reinhard
>>>>>>
>>>>>>
>>>>>> Am 11.02.2013 15:27, schrieb Ron Wheeler:
>>>>>>
>>>>>> Why not just load these stray orphans into your MRM once and then
>>>> treat
>>>>>>> them and normal dependencies.
>>>>>>>
>>>>>>> Ron
>>>>>>>
>>>>>>> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> A couple of years ago I used a plugin execution in the validate
>>> phase
>>>>> to
>>>>>>>> bootstrap jars that were not available on Maven Central as
>>> suggested
>>>> in
>>>>>>>> [1]. I needed to do the same thing again today but noticed that
>>> this
>>>>>>>> approach does not seem to work any more with Maven 3. Right after
>>>>> running
>>>>>>>> Maven, dependency resolution kicks in making the build fail even
>>>>> before the
>>>>>>>> install plugin gets a chance to install the missing dependency.
>>>> Here's
>>>>> what
>>>>>>>> I'm doing:
>>>>>>>>
>>>>>>>> <plugin>
>>>>>>>> <groupId>org.apache.maven.**plugins</groupId>
>>>>>>>> <artifactId>maven-install-**plugin</artifactId>
>>>>>>>> <executions>
>>>>>>>> <execution>
>>>>>>>> <id>boostrap-some-depencency</**id>
>>>>>>>> <goals>
>>>>>>>> <goal>install-file</goal>
>>>>>>>> </goals>
>>>>>>>> <phase>validate</phase>
>>>>>>>> <configuration>
>>>>>>>> <groupId>com.some.groupid</**groupId>
>>>>>>>> <artifactId>some-artifact</**artifactId>
>>>>>>>> <version>${some.artifact.**version}</version>
>>>>>>>> <packaging>jar</packaging>
>>>>>>>> <file>bootstrap-lib/some-**artifact-${some.artifact.**
>>>>>>>> version}.jar</file>
>>>>>>>>
>> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
>>>>>>>> </configuration>
>>>>>>>> </execution>
>>>>>>>> </executions>
>>>>>>>> </plugin>
>>>>>>>> ...
>>>>>>>> <dependency>
>>>>>>>> <groupId>com.some.groupid</**groupId>
>>>>>>>> <artifactId>some-artifact</**artifactId>
>>>>>>>> <version>${some.artifact.**version}</version>
>>>>>>>> </dependency>
>>>>>>>> ...
>>>>>>>> <properties>
>>>>>>>> <some.artifact.version>1.2.3</**some.artifact.version>
>>>>>>>> </properties>
>>>>>>>>
>>>>>>>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
>>>>>>>> install-dependencies-during-**build/<
>> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
>>>>>>>> Is this no longer possible? I'd really prefer this approach over
>>>> using
>>>>> a
>>>>>>>> system dependency.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Reinhard
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------**------------------------------**
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
>>>>> users-unsubscribe@maven.apache.org>
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>> ------------------------------**------------------------------**---------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
>>>>> users-unsubscribe@maven.apache.org>
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency resolution kicks in too early
Posted by Stephen Connolly <st...@gmail.com>.
Yes, I agree, but I have had to do it myself some times... in more radical
cases this has evolved into a complete fork for me (e.g. redmine-java-api)
On 13 February 2013 15:33, Anders Hammar <an...@hammar.net> wrote:
> Right, I was thinking they would deploy it to their Nexus instance where
> they deploy their own oss product.
> Having the same jar in two different groupIds in central only confuses
> people and causes problems I think. We should try to avoid that.
>
> /Anders
>
>
> On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 13 February 2013 15:19, Anders Hammar <an...@hammar.net> wrote:
> >
> > > > deploy it to your own groupId
> > > >
> > >
> > > Isn't it better if he uses the original groupId and artifactId, but
> adds
> > a
> > > qualifier to the version indicating that it's their release?
> >
> >
> > Well... the chain you have to go when deploying something into central
> > under a groupId that you do not own is something like:
> >
> > 1. Show that you have engaged the owning project and that they are not
> > pushing a version
> > 2. Show blah blah blah
> > 3.
> > 4.
> > 5. Ok, create the bundle and upload it
> >
> > And given that he said the owning project is working on uploading to
> > central, he's going to fail on step 1... so if it is urgent the lesser
> evil
> > is his own groupId...
> >
> > That said it would be best to keep the groupId it will end up with.
> >
> >
> > > Like if he
> > > would have patched an official release.
> > >
> > > /Anders
> > >
> > >
> > > >
> > > >
> > > > On 13 February 2013 14:54, Reinhard Nägele <
> > reinhard.naegele@mgm-tp.com
> > > > >wrote:
> > > >
> > > > > Normally, I'd deploy it to our Nexus. But in this case, this is not
> > > > > possible. We are open-sourcing one of our products and need a
> > > third-party
> > > > > dependency which is not yet available on Maven Central. We are
> > working
> > > > with
> > > > > the developer of the library to fix this, but until this is the
> case,
> > > we
> > > > > need a temporary solution.
> > > > >
> > > > > Reinhard
> > > > >
> > > > >
> > > > > Am 11.02.2013 15:27, schrieb Ron Wheeler:
> > > > >
> > > > > Why not just load these stray orphans into your MRM once and then
> > > treat
> > > > >> them and normal dependencies.
> > > > >>
> > > > >> Ron
> > > > >>
> > > > >> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
> > > > >>
> > > > >>> Hello,
> > > > >>>
> > > > >>> A couple of years ago I used a plugin execution in the validate
> > phase
> > > > to
> > > > >>> bootstrap jars that were not available on Maven Central as
> > suggested
> > > in
> > > > >>> [1]. I needed to do the same thing again today but noticed that
> > this
> > > > >>> approach does not seem to work any more with Maven 3. Right after
> > > > running
> > > > >>> Maven, dependency resolution kicks in making the build fail even
> > > > before the
> > > > >>> install plugin gets a chance to install the missing dependency.
> > > Here's
> > > > what
> > > > >>> I'm doing:
> > > > >>>
> > > > >>> <plugin>
> > > > >>> <groupId>org.apache.maven.**plugins</groupId>
> > > > >>> <artifactId>maven-install-**plugin</artifactId>
> > > > >>> <executions>
> > > > >>> <execution>
> > > > >>> <id>boostrap-some-depencency</**id>
> > > > >>> <goals>
> > > > >>> <goal>install-file</goal>
> > > > >>> </goals>
> > > > >>> <phase>validate</phase>
> > > > >>> <configuration>
> > > > >>> <groupId>com.some.groupid</**groupId>
> > > > >>> <artifactId>some-artifact</**artifactId>
> > > > >>> <version>${some.artifact.**version}</version>
> > > > >>> <packaging>jar</packaging>
> > > > >>> <file>bootstrap-lib/some-**artifact-${some.artifact.**
> > > > >>> version}.jar</file>
> > > > >>>
> > > >
> > >
> >
> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
> > > > >>>
> > > > >>> </configuration>
> > > > >>> </execution>
> > > > >>> </executions>
> > > > >>> </plugin>
> > > > >>> ...
> > > > >>> <dependency>
> > > > >>> <groupId>com.some.groupid</**groupId>
> > > > >>> <artifactId>some-artifact</**artifactId>
> > > > >>> <version>${some.artifact.**version}</version>
> > > > >>> </dependency>
> > > > >>> ...
> > > > >>> <properties>
> > > > >>> <some.artifact.version>1.2.3</**some.artifact.version>
> > > > >>> </properties>
> > > > >>>
> > > > >>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
> > > > >>> install-dependencies-during-**build/<
> > > >
> > >
> >
> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
> > > > >
> > > > >>>
> > > > >>> Is this no longer possible? I'd really prefer this approach over
> > > using
> > > > a
> > > > >>> system dependency.
> > > > >>>
> > > > >>> Thanks,
> > > > >>> Reinhard
> > > > >>>
> > > > >>>
> > > > >>> ------------------------------**------------------------------**
> > > > >>> ---------
> > > > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > > > users-unsubscribe@maven.apache.org>
> > > > >>> For additional commands, e-mail: users-help@maven.apache.org
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > >
> ------------------------------**------------------------------**---------
> > > > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > > > users-unsubscribe@maven.apache.org>
> > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Dependency resolution kicks in too early
Posted by Anders Hammar <an...@hammar.net>.
Right, I was thinking they would deploy it to their Nexus instance where
they deploy their own oss product.
Having the same jar in two different groupIds in central only confuses
people and causes problems I think. We should try to avoid that.
/Anders
On Wed, Feb 13, 2013 at 4:27 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On 13 February 2013 15:19, Anders Hammar <an...@hammar.net> wrote:
>
> > > deploy it to your own groupId
> > >
> >
> > Isn't it better if he uses the original groupId and artifactId, but adds
> a
> > qualifier to the version indicating that it's their release?
>
>
> Well... the chain you have to go when deploying something into central
> under a groupId that you do not own is something like:
>
> 1. Show that you have engaged the owning project and that they are not
> pushing a version
> 2. Show blah blah blah
> 3.
> 4.
> 5. Ok, create the bundle and upload it
>
> And given that he said the owning project is working on uploading to
> central, he's going to fail on step 1... so if it is urgent the lesser evil
> is his own groupId...
>
> That said it would be best to keep the groupId it will end up with.
>
>
> > Like if he
> > would have patched an official release.
> >
> > /Anders
> >
> >
> > >
> > >
> > > On 13 February 2013 14:54, Reinhard Nägele <
> reinhard.naegele@mgm-tp.com
> > > >wrote:
> > >
> > > > Normally, I'd deploy it to our Nexus. But in this case, this is not
> > > > possible. We are open-sourcing one of our products and need a
> > third-party
> > > > dependency which is not yet available on Maven Central. We are
> working
> > > with
> > > > the developer of the library to fix this, but until this is the case,
> > we
> > > > need a temporary solution.
> > > >
> > > > Reinhard
> > > >
> > > >
> > > > Am 11.02.2013 15:27, schrieb Ron Wheeler:
> > > >
> > > > Why not just load these stray orphans into your MRM once and then
> > treat
> > > >> them and normal dependencies.
> > > >>
> > > >> Ron
> > > >>
> > > >> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
> > > >>
> > > >>> Hello,
> > > >>>
> > > >>> A couple of years ago I used a plugin execution in the validate
> phase
> > > to
> > > >>> bootstrap jars that were not available on Maven Central as
> suggested
> > in
> > > >>> [1]. I needed to do the same thing again today but noticed that
> this
> > > >>> approach does not seem to work any more with Maven 3. Right after
> > > running
> > > >>> Maven, dependency resolution kicks in making the build fail even
> > > before the
> > > >>> install plugin gets a chance to install the missing dependency.
> > Here's
> > > what
> > > >>> I'm doing:
> > > >>>
> > > >>> <plugin>
> > > >>> <groupId>org.apache.maven.**plugins</groupId>
> > > >>> <artifactId>maven-install-**plugin</artifactId>
> > > >>> <executions>
> > > >>> <execution>
> > > >>> <id>boostrap-some-depencency</**id>
> > > >>> <goals>
> > > >>> <goal>install-file</goal>
> > > >>> </goals>
> > > >>> <phase>validate</phase>
> > > >>> <configuration>
> > > >>> <groupId>com.some.groupid</**groupId>
> > > >>> <artifactId>some-artifact</**artifactId>
> > > >>> <version>${some.artifact.**version}</version>
> > > >>> <packaging>jar</packaging>
> > > >>> <file>bootstrap-lib/some-**artifact-${some.artifact.**
> > > >>> version}.jar</file>
> > > >>>
> > >
> >
> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
> > > >>>
> > > >>> </configuration>
> > > >>> </execution>
> > > >>> </executions>
> > > >>> </plugin>
> > > >>> ...
> > > >>> <dependency>
> > > >>> <groupId>com.some.groupid</**groupId>
> > > >>> <artifactId>some-artifact</**artifactId>
> > > >>> <version>${some.artifact.**version}</version>
> > > >>> </dependency>
> > > >>> ...
> > > >>> <properties>
> > > >>> <some.artifact.version>1.2.3</**some.artifact.version>
> > > >>> </properties>
> > > >>>
> > > >>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
> > > >>> install-dependencies-during-**build/<
> > >
> >
> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
> > > >
> > > >>>
> > > >>> Is this no longer possible? I'd really prefer this approach over
> > using
> > > a
> > > >>> system dependency.
> > > >>>
> > > >>> Thanks,
> > > >>> Reinhard
> > > >>>
> > > >>>
> > > >>> ------------------------------**------------------------------**
> > > >>> ---------
> > > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > > users-unsubscribe@maven.apache.org>
> > > >>> For additional commands, e-mail: users-help@maven.apache.org
> > > >>>
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >
> > > >
> > ------------------------------**------------------------------**---------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > > users-unsubscribe@maven.apache.org>
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Dependency resolution kicks in too early
Posted by Stephen Connolly <st...@gmail.com>.
On 13 February 2013 15:19, Anders Hammar <an...@hammar.net> wrote:
> > deploy it to your own groupId
> >
>
> Isn't it better if he uses the original groupId and artifactId, but adds a
> qualifier to the version indicating that it's their release?
Well... the chain you have to go when deploying something into central
under a groupId that you do not own is something like:
1. Show that you have engaged the owning project and that they are not
pushing a version
2. Show blah blah blah
3.
4.
5. Ok, create the bundle and upload it
And given that he said the owning project is working on uploading to
central, he's going to fail on step 1... so if it is urgent the lesser evil
is his own groupId...
That said it would be best to keep the groupId it will end up with.
> Like if he
> would have patched an official release.
>
> /Anders
>
>
> >
> >
> > On 13 February 2013 14:54, Reinhard Nägele <reinhard.naegele@mgm-tp.com
> > >wrote:
> >
> > > Normally, I'd deploy it to our Nexus. But in this case, this is not
> > > possible. We are open-sourcing one of our products and need a
> third-party
> > > dependency which is not yet available on Maven Central. We are working
> > with
> > > the developer of the library to fix this, but until this is the case,
> we
> > > need a temporary solution.
> > >
> > > Reinhard
> > >
> > >
> > > Am 11.02.2013 15:27, schrieb Ron Wheeler:
> > >
> > > Why not just load these stray orphans into your MRM once and then
> treat
> > >> them and normal dependencies.
> > >>
> > >> Ron
> > >>
> > >> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
> > >>
> > >>> Hello,
> > >>>
> > >>> A couple of years ago I used a plugin execution in the validate phase
> > to
> > >>> bootstrap jars that were not available on Maven Central as suggested
> in
> > >>> [1]. I needed to do the same thing again today but noticed that this
> > >>> approach does not seem to work any more with Maven 3. Right after
> > running
> > >>> Maven, dependency resolution kicks in making the build fail even
> > before the
> > >>> install plugin gets a chance to install the missing dependency.
> Here's
> > what
> > >>> I'm doing:
> > >>>
> > >>> <plugin>
> > >>> <groupId>org.apache.maven.**plugins</groupId>
> > >>> <artifactId>maven-install-**plugin</artifactId>
> > >>> <executions>
> > >>> <execution>
> > >>> <id>boostrap-some-depencency</**id>
> > >>> <goals>
> > >>> <goal>install-file</goal>
> > >>> </goals>
> > >>> <phase>validate</phase>
> > >>> <configuration>
> > >>> <groupId>com.some.groupid</**groupId>
> > >>> <artifactId>some-artifact</**artifactId>
> > >>> <version>${some.artifact.**version}</version>
> > >>> <packaging>jar</packaging>
> > >>> <file>bootstrap-lib/some-**artifact-${some.artifact.**
> > >>> version}.jar</file>
> > >>>
> >
> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
> > >>>
> > >>> </configuration>
> > >>> </execution>
> > >>> </executions>
> > >>> </plugin>
> > >>> ...
> > >>> <dependency>
> > >>> <groupId>com.some.groupid</**groupId>
> > >>> <artifactId>some-artifact</**artifactId>
> > >>> <version>${some.artifact.**version}</version>
> > >>> </dependency>
> > >>> ...
> > >>> <properties>
> > >>> <some.artifact.version>1.2.3</**some.artifact.version>
> > >>> </properties>
> > >>>
> > >>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
> > >>> install-dependencies-during-**build/<
> >
> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
> > >
> > >>>
> > >>> Is this no longer possible? I'd really prefer this approach over
> using
> > a
> > >>> system dependency.
> > >>>
> > >>> Thanks,
> > >>> Reinhard
> > >>>
> > >>>
> > >>> ------------------------------**------------------------------**
> > >>> ---------
> > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > users-unsubscribe@maven.apache.org>
> > >>> For additional commands, e-mail: users-help@maven.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> > users-unsubscribe@maven.apache.org>
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
Re: Dependency resolution kicks in too early
Posted by Anders Hammar <an...@hammar.net>.
> deploy it to your own groupId
>
Isn't it better if he uses the original groupId and artifactId, but adds a
qualifier to the version indicating that it's their release? Like if he
would have patched an official release.
/Anders
>
>
> On 13 February 2013 14:54, Reinhard Nägele <reinhard.naegele@mgm-tp.com
> >wrote:
>
> > Normally, I'd deploy it to our Nexus. But in this case, this is not
> > possible. We are open-sourcing one of our products and need a third-party
> > dependency which is not yet available on Maven Central. We are working
> with
> > the developer of the library to fix this, but until this is the case, we
> > need a temporary solution.
> >
> > Reinhard
> >
> >
> > Am 11.02.2013 15:27, schrieb Ron Wheeler:
> >
> > Why not just load these stray orphans into your MRM once and then treat
> >> them and normal dependencies.
> >>
> >> Ron
> >>
> >> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
> >>
> >>> Hello,
> >>>
> >>> A couple of years ago I used a plugin execution in the validate phase
> to
> >>> bootstrap jars that were not available on Maven Central as suggested in
> >>> [1]. I needed to do the same thing again today but noticed that this
> >>> approach does not seem to work any more with Maven 3. Right after
> running
> >>> Maven, dependency resolution kicks in making the build fail even
> before the
> >>> install plugin gets a chance to install the missing dependency. Here's
> what
> >>> I'm doing:
> >>>
> >>> <plugin>
> >>> <groupId>org.apache.maven.**plugins</groupId>
> >>> <artifactId>maven-install-**plugin</artifactId>
> >>> <executions>
> >>> <execution>
> >>> <id>boostrap-some-depencency</**id>
> >>> <goals>
> >>> <goal>install-file</goal>
> >>> </goals>
> >>> <phase>validate</phase>
> >>> <configuration>
> >>> <groupId>com.some.groupid</**groupId>
> >>> <artifactId>some-artifact</**artifactId>
> >>> <version>${some.artifact.**version}</version>
> >>> <packaging>jar</packaging>
> >>> <file>bootstrap-lib/some-**artifact-${some.artifact.**
> >>> version}.jar</file>
> >>>
> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
> >>>
> >>> </configuration>
> >>> </execution>
> >>> </executions>
> >>> </plugin>
> >>> ...
> >>> <dependency>
> >>> <groupId>com.some.groupid</**groupId>
> >>> <artifactId>some-artifact</**artifactId>
> >>> <version>${some.artifact.**version}</version>
> >>> </dependency>
> >>> ...
> >>> <properties>
> >>> <some.artifact.version>1.2.3</**some.artifact.version>
> >>> </properties>
> >>>
> >>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
> >>> install-dependencies-during-**build/<
> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
> >
> >>>
> >>> Is this no longer possible? I'd really prefer this approach over using
> a
> >>> system dependency.
> >>>
> >>> Thanks,
> >>> Reinhard
> >>>
> >>>
> >>> ------------------------------**------------------------------**
> >>> ---------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
> users-unsubscribe@maven.apache.org>
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
Re: Dependency resolution kicks in too early
Posted by Stephen Connolly <st...@gmail.com>.
deploy it to your own groupId
On 13 February 2013 14:54, Reinhard Nägele <re...@mgm-tp.com>wrote:
> Normally, I'd deploy it to our Nexus. But in this case, this is not
> possible. We are open-sourcing one of our products and need a third-party
> dependency which is not yet available on Maven Central. We are working with
> the developer of the library to fix this, but until this is the case, we
> need a temporary solution.
>
> Reinhard
>
>
> Am 11.02.2013 15:27, schrieb Ron Wheeler:
>
> Why not just load these stray orphans into your MRM once and then treat
>> them and normal dependencies.
>>
>> Ron
>>
>> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
>>
>>> Hello,
>>>
>>> A couple of years ago I used a plugin execution in the validate phase to
>>> bootstrap jars that were not available on Maven Central as suggested in
>>> [1]. I needed to do the same thing again today but noticed that this
>>> approach does not seem to work any more with Maven 3. Right after running
>>> Maven, dependency resolution kicks in making the build fail even before the
>>> install plugin gets a chance to install the missing dependency. Here's what
>>> I'm doing:
>>>
>>> <plugin>
>>> <groupId>org.apache.maven.**plugins</groupId>
>>> <artifactId>maven-install-**plugin</artifactId>
>>> <executions>
>>> <execution>
>>> <id>boostrap-some-depencency</**id>
>>> <goals>
>>> <goal>install-file</goal>
>>> </goals>
>>> <phase>validate</phase>
>>> <configuration>
>>> <groupId>com.some.groupid</**groupId>
>>> <artifactId>some-artifact</**artifactId>
>>> <version>${some.artifact.**version}</version>
>>> <packaging>jar</packaging>
>>> <file>bootstrap-lib/some-**artifact-${some.artifact.**
>>> version}.jar</file>
>>> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
>>>
>>> </configuration>
>>> </execution>
>>> </executions>
>>> </plugin>
>>> ...
>>> <dependency>
>>> <groupId>com.some.groupid</**groupId>
>>> <artifactId>some-artifact</**artifactId>
>>> <version>${some.artifact.**version}</version>
>>> </dependency>
>>> ...
>>> <properties>
>>> <some.artifact.version>1.2.3</**some.artifact.version>
>>> </properties>
>>>
>>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
>>> install-dependencies-during-**build/<http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/>
>>>
>>> Is this no longer possible? I'd really prefer this approach over using a
>>> system dependency.
>>>
>>> Thanks,
>>> Reinhard
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Dependency resolution kicks in too early
Posted by Reinhard Nägele <re...@mgm-tp.com>.
Normally, I'd deploy it to our Nexus. But in this case, this is not
possible. We are open-sourcing one of our products and need a
third-party dependency which is not yet available on Maven Central. We
are working with the developer of the library to fix this, but until
this is the case, we need a temporary solution.
Reinhard
Am 11.02.2013 15:27, schrieb Ron Wheeler:
> Why not just load these stray orphans into your MRM once and then
> treat them and normal dependencies.
>
> Ron
>
> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
>> Hello,
>>
>> A couple of years ago I used a plugin execution in the validate phase
>> to bootstrap jars that were not available on Maven Central as
>> suggested in [1]. I needed to do the same thing again today but
>> noticed that this approach does not seem to work any more with Maven
>> 3. Right after running Maven, dependency resolution kicks in making
>> the build fail even before the install plugin gets a chance to
>> install the missing dependency. Here's what I'm doing:
>>
>> <plugin>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-install-plugin</artifactId>
>> <executions>
>> <execution>
>> <id>boostrap-some-depencency</id>
>> <goals>
>> <goal>install-file</goal>
>> </goals>
>> <phase>validate</phase>
>> <configuration>
>> <groupId>com.some.groupid</groupId>
>> <artifactId>some-artifact</artifactId>
>> <version>${some.artifact.version}</version>
>> <packaging>jar</packaging>
>> <file>bootstrap-lib/some-artifact-${some.artifact.version}.jar</file>
>> <sources>bootstrap-lib/some-artifact-${some.artifact.version}-sources.jar</sources>
>>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> ...
>> <dependency>
>> <groupId>com.some.groupid</groupId>
>> <artifactId>some-artifact</artifactId>
>> <version>${some.artifact.version}</version>
>> </dependency>
>> ...
>> <properties>
>> <some.artifact.version>1.2.3</some.artifact.version>
>> </properties>
>>
>> [1]
>> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
>>
>> Is this no longer possible? I'd really prefer this approach over
>> using a system dependency.
>>
>> Thanks,
>> Reinhard
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency resolution kicks in too early
Posted by Baptiste MATHUS <ml...@batmat.net>.
+1.
The right approach is to use a MRM.
You were unlucky to find an article that is actually more a quite dirty
hack than a solution.
You shouldn't put dependencies inside your SCM.
Put those dependencies once into the maven repository manager, and be happy
with a clean and simple build.
Cheers
2013/2/11 Ron Wheeler <rw...@artifact-software.com>
> Why not just load these stray orphans into your MRM once and then treat
> them and normal dependencies.
>
> Ron
>
>
> On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
>
>> Hello,
>>
>> A couple of years ago I used a plugin execution in the validate phase to
>> bootstrap jars that were not available on Maven Central as suggested in
>> [1]. I needed to do the same thing again today but noticed that this
>> approach does not seem to work any more with Maven 3. Right after running
>> Maven, dependency resolution kicks in making the build fail even before the
>> install plugin gets a chance to install the missing dependency. Here's what
>> I'm doing:
>>
>> <plugin>
>> <groupId>org.apache.maven.**plugins</groupId>
>> <artifactId>maven-install-**plugin</artifactId>
>> <executions>
>> <execution>
>> <id>boostrap-some-depencency</**id>
>> <goals>
>> <goal>install-file</goal>
>> </goals>
>> <phase>validate</phase>
>> <configuration>
>> <groupId>com.some.groupid</**groupId>
>> <artifactId>some-artifact</**artifactId>
>> <version>${some.artifact.**version}</version>
>> <packaging>jar</packaging>
>> <file>bootstrap-lib/some-**artifact-${some.artifact.**version}.jar</file>
>> <sources>bootstrap-lib/some-**artifact-${some.artifact.**version}-sources.jar</sources>
>>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>> ...
>> <dependency>
>> <groupId>com.some.groupid</**groupId>
>> <artifactId>some-artifact</**artifactId>
>> <version>${some.artifact.**version}</version>
>> </dependency>
>> ...
>> <properties>
>> <some.artifact.version>1.2.3</**some.artifact.version>
>> </properties>
>>
>> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
>> install-dependencies-during-**build/<http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/>
>>
>> Is this no longer possible? I'd really prefer this approach over using a
>> system dependency.
>>
>> Thanks,
>> Reinhard
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
> --
> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! <us...@maven.apache.org>
>
Re: Dependency resolution kicks in too early
Posted by Ron Wheeler <rw...@artifact-software.com>.
Why not just load these stray orphans into your MRM once and then treat
them and normal dependencies.
Ron
On 11/02/2013 4:17 AM, Reinhard Nägele wrote:
> Hello,
>
> A couple of years ago I used a plugin execution in the validate phase
> to bootstrap jars that were not available on Maven Central as
> suggested in [1]. I needed to do the same thing again today but
> noticed that this approach does not seem to work any more with Maven
> 3. Right after running Maven, dependency resolution kicks in making
> the build fail even before the install plugin gets a chance to install
> the missing dependency. Here's what I'm doing:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-install-plugin</artifactId>
> <executions>
> <execution>
> <id>boostrap-some-depencency</id>
> <goals>
> <goal>install-file</goal>
> </goals>
> <phase>validate</phase>
> <configuration>
> <groupId>com.some.groupid</groupId>
> <artifactId>some-artifact</artifactId>
> <version>${some.artifact.version}</version>
> <packaging>jar</packaging>
> <file>bootstrap-lib/some-artifact-${some.artifact.version}.jar</file>
> <sources>bootstrap-lib/some-artifact-${some.artifact.version}-sources.jar</sources>
>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ...
> <dependency>
> <groupId>com.some.groupid</groupId>
> <artifactId>some-artifact</artifactId>
> <version>${some.artifact.version}</version>
> </dependency>
> ...
> <properties>
> <some.artifact.version>1.2.3</some.artifact.version>
> </properties>
>
> [1]
> http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/
>
> Is this no longer possible? I'd really prefer this approach over using
> a system dependency.
>
> Thanks,
> Reinhard
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Dependency resolution kicks in too early
Posted by Brian Fox <br...@infinity.nu>.
You've run into a non-supported edge case.
On Mon, Feb 11, 2013 at 4:17 AM, Reinhard Nägele <
reinhard.naegele@mgm-tp.com> wrote:
> Hello,
>
> A couple of years ago I used a plugin execution in the validate phase to
> bootstrap jars that were not available on Maven Central as suggested in
> [1]. I needed to do the same thing again today but noticed that this
> approach does not seem to work any more with Maven 3. Right after running
> Maven, dependency resolution kicks in making the build fail even before the
> install plugin gets a chance to install the missing dependency. Here's what
> I'm doing:
>
> <plugin>
> <groupId>org.apache.maven.**plugins</groupId>
> <artifactId>maven-install-**plugin</artifactId>
> <executions>
> <execution>
> <id>boostrap-some-depencency</**id>
> <goals>
> <goal>install-file</goal>
> </goals>
> <phase>validate</phase>
> <configuration>
> <groupId>com.some.groupid</**groupId>
> <artifactId>some-artifact</**artifactId>
> <version>${some.artifact.**version}</version>
> <packaging>jar</packaging>
> <file>bootstrap-lib/some-**artifact-${some.artifact.**version}.jar</file>
> <sources>bootstrap-lib/some-**artifact-${some.artifact.**
> version}-sources.jar</sources>
> </configuration>
> </execution>
> </executions>
> </plugin>
> ...
> <dependency>
> <groupId>com.some.groupid</**groupId>
> <artifactId>some-artifact</**artifactId>
> <version>${some.artifact.**version}</version>
> </dependency>
> ...
> <properties>
> <some.artifact.version>1.2.3</**some.artifact.version>
> </properties>
>
> [1] http://www.blackbit.be/2010/**04/15/maven-automatically-**
> install-dependencies-during-**build/<http://www.blackbit.be/2010/04/15/maven-automatically-install-dependencies-during-build/>
>
> Is this no longer possible? I'd really prefer this approach over using a
> system dependency.
>
> Thanks,
> Reinhard
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>