maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: [M2 REPO] mess in /servicemix
Date Mon, 06 Mar 2006 15:43:20 GMT
Brett Porter wrote:
> When we implement something like <provides>, so that these can say
> "treat me like the real one if it ever turns up", then this is probably
> a reasonably expedient way.

The meaning of <provides/> is really "i am the real one, but an 
equivalent _will_ show up".

> I'd much rather they use a private repo where they can do what they want
> until they get it into ibiblio. I think that's a better solution. WDYT?

That's probably the best solution. Anyone can still build against a 
project hosted repository and it stays out of the ibiblio population. 
Then the project can take whatever measures to get the real dependencies 
to ibiblio but everything can still function. Sounds like a good concept 
to promote.

> - Brett
> 
> Jason van Zyl wrote:
>> Brett Porter wrote:
>>> That's exactly the problem in this case - they're all in the servicemix
>>> groupId.
>>>
>>> This becomes harmful in transitive dependencies, as there's no way to
>>> express equivalence. So if you depend on OSGi and ServiceMix, you get
>>> two copies of OSGi, and all its dependencies.
>> Projects are always going to do this for the sake of expediency and
>> under the license they can.
>>
>> They obviously did this as not to claim to have provided the official
>> JARs which I think is correct and being a good citizen. This is going to
>> happen again I'm sure because projects don't want to push the official
>> project JARs into the repository. For highly used components do we just
>> push them in, maybe a flag on the dependency to indicate this scenerio?
>>
>> We definitely prefer that projects themselves issue to the repository
>> but this isn't always going to happen and we should probably account for
>> it.
>>
>> Jason van Zyl
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 
> 


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


Mime
View raw message