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.
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.
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 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.
There is a lot of truth in that but it goes beyond what my folks are
asking for. Basically we have a bunch of builds that generate multiple
artifacts. Their is a "bill of materials" (BOM) project that identifies
the versions of all the artifacts. In their projects they simply want to
specify the version of the "bom-pom" and cause all the correct versions
of the individual artifacts to be included. However, they still want the
flexibility to pick different versions of these main projects.
If I understand you correctly, your client could simply reference a
master pom in their dependencyManagement section using the method I've
outlined. This would bring in the master catalog. They could still
override it as any dependencies specified in the local
dependencyManagement are not overwritten by the imported pom.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
