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:19:33 GMT
> 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
> >
> >
>

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