On Jul 31, 2011, at 3:27 AM, Stephen Connolly wrote: > i see two concerns that need separation. > > 1. the code that fetches dependencies from wherever they live. >
Sure, I've known people to change this in many ways. Integration of legacy artifact stores, migration strategies which involve pulling things from SCMs or what have you. Lots of people have modified this that I know of. This can happen in many ways and hasn't done anything too terrible in the places I've seen it implemented. > 2. the code that computed the dependencies graph. > Right, the specification and interpretation of a version scheme happening in multiple ways I think would be highly problematic. I don't really see much upside to making this pluggable. > #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: Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
