maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Nägele <reinhard.naeg...@mgm-tp.com>
Subject Re: Dependency resolution kicks in too early
Date Thu, 14 Feb 2013 08:45:10 GMT
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 <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
>>>>>>
>>>>>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message