maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Dependency resolution kicks in too early
Date Wed, 13 Feb 2013 15:33:34 GMT
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