maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Dependency resolution kicks in too early
Date Wed, 13 Feb 2013 16:09:48 GMT
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 <anders@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 <anders@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
> > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message