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 <[email protected]> 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 < > [email protected]> wrote: > > > On 13 February 2013 15:19, Anders Hammar <[email protected]> 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 < > > [email protected] > > > > >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< > > > > [email protected]> > > > > >>> For additional commands, e-mail: [email protected] > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > ------------------------------**------------------------------**--------- > > > > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > > > > [email protected]> > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > >
