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 <and...@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.conno...@gmail.com> wrote:
On 13 February 2013 15:19, Anders Hammar <and...@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.naeg...@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-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
------------------------------**------------------------------**---------
To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<
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
