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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
