Import scope intricacies

[John Casey <jd...@commonjava.org>]

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

RE: Import scope intricacies

["Brian E. Fox" <br...@reply.infinity.nu>]

>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 think the import scope should _NOT_ be assumed for pom projects. Pom
projects serve a third purpose in Maven (besides aggregation and
inheritance). They are really the "generic" module that is used because
there are essentially no bindings to the lifecycle by default. Think
about it, every time you want a separate assembly module, what packaging
do you start with? Pom. Same for any other not-out-of-the-box case like
running Its or ant etc. I think it's making too many assumptions and
*magic* if we just assume import, it's much better to just make it
explicit. (Not to mention the mess this would make for people that
upgrade later)


>It also isn't at all clear to me why 
>the child pom even declares that it inherits from its parent. 

This is going to be the norm in a multimodule structure. It's rare that
you have a module in a big tree that doesn't inherit up.

I'm going to go ahead and stage 2.0.9, but we'll need good site guides
and release notes (and ITS) for this feature so we don't have a bunch of
people diving over the cliff.

--Brian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Import scope intricacies

[Ralph Goers <Ra...@dslextreme.com>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org