On Thu, 06 Dec 2007 11:26:53 [EMAIL PROTECTED] wrote: > That's interesting. indeed
> > Would this version range work [1.2,-!) i.e., to match 1.2 or anything > later ? don't know good guess though > > Version range is certainly very useful but I think one can always work > around it, especially if it is buggy. Can you elaborate on what you mean > by "make complex project possible" when you get complex depedencies it is quite often very difficult to get a consistent set of know good artifacts in release assemblies... think dependency depths > 7 with lots of common deps by encasulating third party and even internal components in dependency compositions you can easily manage links to external projects... consider hibernate... we have a composite dependecy with version 1.X that any of our projects using hibernate use, they have a range [1,2-)... in order to upgrade hibernate i can release a new composite in the 1.x range and all projects will pick it up or i can increment the composite range to 2.x - e.g. for move from 3.1.X hibernate to 3.2.X. - and only project where i update the range to [2,3-!) will be affected... as a bonus its not possible to now aggregate components that a depedent on different versions of hibernate... this leads into your next question... > and "makes parallel development > possible" ? so with composites its possible to have a portion of artifacts using a particular version of a third party library upgraded in isolation... for example... a new deliverable is being built but needs the latest and greatest spring... however a bug stops it from being used for some other deliverables I can have two deliverables that use spring composite 1.x which is spring 2.0.7 and the new deliverable use composite 2.x which is spring 2.0.8 i only use spring and hibernate to illustrate the point as they tend to be ubiquitous across my projects... both are very high quality ;-) Obviously the same is true for artifacts reused across 'my own' projects. I can have two teams working in the most recent example on different versions of java... the 1.x versions of our libraries are java4 and the 2.x are java6... the appropriate use of ranges will mean that no java4 aggregation will ever accidentally pull in a java6 jar I would recommend a little research into linux and package management... in particular Gentoo's portage. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
