Multiproject inheritance (again)

can you download maven-1.0 (announced shortly) and see if it is still a problem? If it is a dupe of MPMULTIPROJECT-32, it is fixed.

Sure...I'm looking forward to it. Thanks for your quick response.

Unfortunately, this seems to be still present in 1.0. I've attached the code again which illustrates the problem and made the logging (a little) clearer. The problem manifests itself when using the multiproject plugin via
maven multiclean

and when using the reactor directly via

maven usereactor

.

Slightly clearer log output

Maven 1.0 works for me (solving MPMULTIPROJECT-32)

Could you clear and simplify the test case?

Cleared out the guff just to illustrate the problem

OK, I've simplified the test case. There is a master project in the root folder, which uses the reactor on a sub project called "Sub". This Sub project's POM inherits from Base, which in turn inherits from BaseBase.
In Base I override the property maven.repo.central=base, and in BaseBase I define the property astrogrid.basebase=Base Base Property

If I run the Sub project in isolation by executing
maven showprops
in the sub directory, then the above properties are displayed correctly.

If I run the Sub project via the reactor by executing
maven usereactor
in the root directory
then the property maven.repo.central retains its default value of login.ibiblio.org, and the astrogrid.basebase property doesn't get picked up at all.

I'm using Maven 1.0, and I've tried this on a Windows machine and a Linux machine.

Ok, I've made some tries and simplified a bit more the test.

Tried with "maven usereactor" and "maven -Dgoal=showprops multiproject:goal" and both fail.

Everything works fine if the root project extends basebase instead of base
<extend>$

/basebase/project.xml</extend>

Yes, as far as I can tell the issue is that subprojects inherit from one level above OK for most properties. However, inheritance/overriding of "built-in" properties such as maven.repo.* doesn't work at all. So, when you change sub to inherit directly from basebase it will pick up the astrogrid.basebase property OK, but if you then moved the maven.repo.central property to basebase, then it wouldn't be overridden.

Thanks for your replies - I'm glad you can reproduce the problem.

I think it has nothing to do with "built in" properties, all properties are at the same level.

OK, well I don't know enough about the internals of Maven, but there is certainly a difference between "maven.repo.central" and "astrogrid.basebase". Perhaps it's that the former already has a value and is being overridden in the properties, rather than any intrinsic difference between the properties.

If you set both
astrogrid.basebase=Base Base Property
maven.repo.central=base

in basebase, and make sub inherit directly from that instead of base, then you'll see that maven.repo.central retains its default ibiblio value.

Running with -X I get the ClassCastException reported by other issues

Unexpected error evaluating expression
java.lang.ClassCastException
at org.apache.maven.MavenUtils.integrateMapInContext(MavenUtils.java:820)
at org.apache.maven.MavenUtils.getNonJellyProject(MavenUtils.java:240)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:144)
at org.apache.maven.MavenUtils.getProject(MavenUtils.java:123)
at org.apache.maven.MavenUtils.getProjects(MavenUtils.java:290)
at org.apache.maven.jelly.tags.maven.ReactorTag.getSortedProjects(ReactorTag.java:400)
at org.apache.maven.jelly.tags.maven.ReactorTag.doTag(ReactorTag.java:296)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634)
at org.apache.maven.MavenSession.attainGoals(MavenSession.java:266)
at org.apache.maven.cli.App.doMain(App.java:486)
at org.apache.maven.cli.App.main(App.java:1215)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.werken.forehead.Forehead.run(Forehead.java:551)
at com.werken.forehead.Forehead.main(Forehead.java:581)

sanity check: none of these exist in build.properties of any form? These override any inheritence.

Not as far as I can see.

In my projects I had the problem with maven.repo.remote. I had to specify it in the project.properties file of the project where I run multiproject from.

But it doesn't happen with maven.javadoc.links, it's correctly inherited.

Furthur more, If I get my sub tree to inherit from the root,rather
then from its parent dir, I am build the subtree.

Sorry, I have one more fact.

If I go to the last node of the tree and do my normal build
(not multiproject:install)

My goal can see the properties I defined at the top node, which can be many levels up.

Attached is a messy patch to fix the inheritence problem. The testcase works under this patch. Maybe someone can volunteer to clean up the patch. It's probably unnecessary to create a new method as I have done.

Updated patch, handles more than one ancestor

dupe of MAVEN-1422

Sadly to say Edwin patch introduce a major problem for me. I am current testing a maven.jar built by Edwin.

It is best that I decribe my usage of Maven and introduce the scenario as I go along.

I have a tree of project directories that from the root, I can
issue "maven multiproject:install" which can transverse to all
subdirectories and build/install artifact to my local repo.

Some subtrees are ignored completely.

So here is how I structure it.

• In my root, I set maven.multiproject.type=ignore
  in my project.properties
• Add a do nothing goal "ignore:install" to maven.xml

This way, any sub tree with does not define maven.multiproject.type
will inherite the root definition, and therefore multiproject plugin
will invoke the do nothing goal "ignore:install"

For those subtrees that I want multiproject goal to build, all I need is to define "maven.multiproject.type=multiproject" in the subtree's project.properties file

For those project (leaf) that I want mutlproject goal to build, all I need is to define "maven.multiproject.type=jar|war..." in project.properties

The problem here is If start do a build from a subtree,
any maven.multiproeject.type defined in the subtree of this subtree, are ignored, and therefore inherit the root's value. And there for
all my intended buildable subtrees are igored.

In summary, please reverse the patch

The patch solves the problem where the sub project ignores the parent's properties, but introduce a new problem where sub project can not override parent's properties

I didn't apply Edwin's patch.

Please build from current CVS and see if it now works in both cases.

I fetched the latest snapshort of MAVEN-1.0 branch, built maven.jar, and use it with my maven 1.0 install.

Oh mine!!! it works. Kudos to maven team and volunteers.

Big thanks