On 17 Sep 07, at 11:48 PM 17 Sep 07, Ralph Goers wrote:
I met with a group of maven users from several business units of my
company last week. The single largest pain point is still with
regard to dependency management. Despite the changes Patrick and I
introduced in MNG-1577 they are still having difficulties primarily
because it is impractical or impossible to use other projects POMs
via inheritance. During our discussions several mechanisms were
proposed but in the end none of them worked properly.
In the midst of the discussion it occurred to me that this was
easily solvable with a few lines of code. I've implemented
something that works over the weekend but before I commit it I'd
like to get some feedback, especially as this would be my first
direct commit into maven.
To illustrate this I created a sample test project that had three
child projects; first, second and third. "first" has a
dependencyManagement declared with a few dependencies in it.
"second" has a dependencyManagement with "first"'s pom declared as
dependency. Likewise, third also has a depdendencyManagement with
"second"'s pom declared as a dependency. "second" and "third" each
have a versionless dependency that is declared in one of the other
pom's dependencyManagement sections.
With maven 2.0.7 this fails as the dependency versions never get
resolved since each project only contains the version of the
referenced pom, not its managed depenendies. With my patched
version the dependency on the pom is removed and is replaced with
the managed dependencies of the referenced pom. This caused the
build to complete successfully. Of course, in the test project I
could have specified more than one pom in the dependencyManagement
section and had them merge together.
Normally, I'd wonder why someone had specified a dependency in
dependencyManagement with a type of pom as I can't think of a good
use for it. However, since I don't want any risk of breaking any
existing projects I also made a change to require that the
dependency in dependencyManagement specify a new scope, "import",
along with the type of "pom". This eliminates any possible problems
but it does introduce a new scope which is only used for this
purpose. I could have required a property to control this behavior,
but I prefer using the scope as it can control the handling of each
dependency.
Hopefully this explanation is clear enough. Please let me know
what you think.
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.
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]
