On Tuesday 18 September 2007 19:40, Jason van Zyl wrote:
> I have been doing some similar work for a project with 1000+ projects > across 60 branches and I have come to the conclusion that dependency > management via inheritance is ineffective in many cases. Especially > for enterprise wide endeavors. i came to a similar conclusion I use composite dependencies to wrap significat groups of 3rd party libraries in known good sets, standard depedency managements takes care of the rest... heavy use of ranges [1,2), [2,3) make life very simple in this regard > > What people are looking for is a single source of truth for > versioning that is external to their projects, as heretical as that > may sound, it is a practical truth. Where I am there are a set of > people here through through the use of a build grid who determine > what works then the developers are pretty much unaware what versions > of artifacts they actually use. They may need new functionality and > know what artifacts to use but they don't see the versioning. to some degree i agree but there is a big difference between spring 1 and spring 2 or hibernate 2 and hibernate 3 or even better example jaxb and jaxb2 I don't care about minor version only the feature version, i use composites as mentioned above to say a consistent set of libraries for using hibernate is this, lets call it composite.hibernate-1.X to get support for hibernate in project i depend apon the composite with a range [1,2) when i need to introduce a new set of hibernate functionality or a new set of libraries which will break things i bump to 2.X trying to bring two trees together with different major version will fail however i can easily release small updates composite.hibernate-1.2, 1.3 etc etc that will just work across all projects and deliverables > > What is needed is a version provider or a version catalog. What I'm > trying to do with 2.1 in my current situation is to utilize and > existing set of dependency information. In my case I cannot take the > version information from anywhere as the designers of the original > system won't let this change and after much debate as to where this > version information should live I finally agreed with them. i can see the attraction... but nothing is reproducible... and how can you release and patch things if it not reproducible... i released version <please look in catalog> to env A... > > I think what large enterprises are looking for is a single source of > truth for the versions, and how to deal with conflicts for a > particular set of releases. > > So effectively what my POMs look are that they have no depMan > sections, and no versions of anything are specified in the POM. Not > even for the project itself as this is a particular problem for large > clearcase-centric shops where the version of an artifact is defined > by the clearcase label. > > So while your method works and may be good for 2.0.7 what are we > ultimately creating? A depMan section is a localized version catalog. > I think this could be implemented such that the default provider is > the current depMan section but allow for things what I'm currently > attempt which is vastly more appealing to my current client because > every last piece of version information sits in one single file. how can it be one file... is there only one service? one deliverable and no shared depedencies? Surely its a tree at least > > > Ralph > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
