agree. The OSGi naming schema makes it easier to detect if a version is higher or lower than another. But the trade off is numerous, let alone compatibility with the versions of already existing maven artifacts.
LieGrue, strub Just as a side note: The handling of multiple jars in different versions in OSGi sounds cool in theory, but in practice it tends to make your system unstable. This really only works if the dependencies form an unidirectional directed graph and you need to recompile all dependencies downwards or you don't change any public APIs. Just upgrade Eclipse a few times and you see what I mean. After max 10 upgrades, your Eclipse installation is completely messed up as you _will_ get conflicting dependencies which don't work together nicely. --- On Sun, 7/31/11, Stephen Connolly <[email protected]> wrote: > From: Stephen Connolly <[email protected]> > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" <[email protected]> > Date: Sunday, July 31, 2011, 7:27 AM > i see two concerns that need > separation. > > 1. the code that fetches dependencies from wherever they > live. > > 2. the code that computed the dependencies graph. > > #1 should be something that is plugable, and in essence > could be part of the > repositories definitions... in saying that, i think we need > a way to > separate the current project build infrastructure from the > fixed information > inherent in tagging the codebase for a release. the > projects repositories > and issue tracker, are things which can evolve over time, > and having them > fixed in an immutable pom is bad for users. if we can find > some way of > fixing that concern then that would be a good thing. > > #2 is a different beast. i think forcing the osgi scheme on > users is bad for > users. i could be selfish and say that i no longer work for > a telecom > company that insists on 5-6 segment version numbers > (depends on how you > choose to release as to whether one of those segments > applies) but forcing 4 > segments on those users is wrong. i don't mind making life > a little harder > for people venturing away from maven's opinionated view, > but forcing people > to conform to get full functionality is bad for users. > where this all fits > in is defining which versions fall within a defined range, > and how to choose > a version from within that range. > > iirc osgi does allow hinting in regard for which end of the > range to favour, > but because of its classloading isolation, there is less of > a problem for > osgi. osgi being designed to solve the 2 dependencies > needing conflicting > versions of the same dependency problem. > > i am more willing to view #2 as being something that we > should be looking > into not being plugable, but instead allow hints to the > impl to say which > end of the range to favour... closest hint wins (sort of) > > however we do need a clear separation between exposing that > as a maven api > and whatever code we have solving that graph for us. > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, > random nonsense > words and other nonsense are a direct result of using swype > to type on the > screen > On 31 Jul 2011 07:41, "Mark Struberg" <[email protected]> > wrote: > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
