Hi all,
I wanted to bring up some interesting effects I've come across having
to do with the new import scope. In what I'd call conventional
cases, this feature seems to work just fine. These cases have been
covered in the core integration-tests for mng-3220. Basically, as
long as the referenced POM is outside the current reactor and
reachable through the repository system, its dependencyManagement
section is merged with the referencing POM's section. If the POM
referenced in a project's dependencyManagement section's scope !=
import, the pom will be included just as it always has been. This
means the dependencyManagement entries in this referenced pom will
not be available to the referencing project.
However, there are some scenarios where things break pretty
drastically. Basically, it hinges on a three critical references
between two POMs in order produce these errors:
1. a project that specifies a dependencyManagement reference with
scope == import and type == pom
2. a module reference to the same project, loaded as a result of the
modules in the project from #1
3. the module project must also have a <parent/> reference pointing
to the POM from #1 and #2.
When these three conditions are present, one of the following will
happen:
1. the referenced and referencing POMs are siblings, with the
referenced POM being built first by sheer chance: in these cases, the
build should proceed normally, since the referenced project instance
will be cached by the time it's required for dependencyManagement
merging.
2. the referenced POM is not in the local repository, and is loaded
after the referencing POM in the reactor: in these cases, the
referenced POM instance has not been built by the time it's required
for dependencyManagement merging. Nothing is yet known about the
location of the referenced POM, and the build fails with an
ArtifactNotFoundException because of the referenced POM that hasn't
been instantiated yet.
3. the referenced POM is both among the modules of the current build
and in the local repository: in these cases, a truly evil scenario
plays out. The referencing POM triggers the loading of the referenced
POM out of the local repository, NOT the project filesystem. This is
because nothing is yet known about the contents of module POMs, so
there is no way for Maven to know that the referenced POM will be
loaded as part of the reactor. When the referenced POM is loaded, it
must first build its ancestry in order to compute inheritance. The
referenced POM's parent (or some ancestor) is the same project that
triggered the referenced POM to be built from the local repository.
This produced a circular reference where the functional parts of the
cycle looks like this:
A [dependencyManagement -> B] -> B [parent -> A] -> A
[dependencyManagement -> B]
or something similar.
The tests for these problems are (or will be; I'm not sure how far
I'll get tonight) included in the integration-tests for mng-3391.
At a minimum, I think we need to document the cases where import
scope can cause big problems. The good news is, the problems only
occur when a build [mis]uses new functionality only available in 2.0.9
+, so we should be able to present this functionality as alpha-grade
with the aforementioned warnings.
Ralph, I think I have this stated as precisely as I can...would you
mind writing up the feature documentation for the website, including
the above and anything I may have missed? I'm not sure I have a solid
enough understanding of the purpose of the import scope, or the cases
where it should and should not be used.
Thanks,
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
