Sure. I can document this. I have already written the code that accounts
for the circularity problem. Instead of getting the stack overflow or
out of memory error it will throw a ProjectBuildingException and
identify both the failing artifact and the parent. However, I have to
retest this since some changes have been recently been made to
DefaultMavenProjectBuilder. I also have not tested this with trunk.
The larger question is with regards to trunk. It was requested that
<scope>import</scope> not be used there and that importing just be the
defined behavior of specifying a pom in a dependencyManagement section.
I haven't questioned this because for the life of me I can't figure out
what the use case is that would put a pom as a dependency there and
expect something useful to happen. It also isn't at all clear to me why
the child pom even declares that it inherits from its parent. Maybe that
is simply because in the test case you sent me the child pom wasn't
doing anything? Can you describe what they are actually trying to do?
Ralph
John Casey wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
