opinions on inheritence of tag

[Brett Porter <bp...@f2network.com.au>]

Hi,
 
I think I've implemented all of the code needed from the branch to solve the
main part of the leak, which is the multiple creation of plugin and ant
projects. All unit tests pass, but I can't currently bootstrap because of
some bugs in the execution. I'll work through them soon. I should be ready
to commit soon after RC1 is cut, and would want to do a little
polishing/refactoring just to clean up.
 
One thing that came up was when I redid the POM inheritence, it seemed the
previous behaviour was that if <sourceDirectory>src/java</sourceDirectory>
was given, then the extended project expected to use the same value, but
relative to its own basedir (ie basedir was evaluated after inheritence, not
before). There was even a unit test to check this.
 
To me, this seems unintuitive - if you are inheriting from something else,
you should inherit the same path, not the expression that will be changed.
The question I have is:
1) should I fix my code so that it works as it used to, unintuitive as it
is?
2) should it inherit the <sourceDirectory/>, etc. value relative to the
parent's directory?
3) should it not inherit the sourceDirectory? If so, what about resources?
 
I'd say we should not inherit any source directories, but should inherit
resources. This is how I have it implemented, so now POM inheritence
inherits everything (including merging lists for versions, mailing lists,
etc), except the source directories.
 
This probably breaks the way Maven builds because there are some subprojects
in the tests depending on the maven base directory, and likewise the plugin
builds. This can easily be addressed.
 
What are people thoughs on this?
 
Cheers,
Brett
 
--
Brett Porter
Team Leader, Core Systems
f2 network ~ everything essential
 

Re: opinions on inheritence of tag

[Jason van Zyl <jv...@maven.org>]

On Sun, 2003-09-28 at 18:52, Brett Porter wrote:
> Hi,
>  
> I think I've implemented all of the code needed from the branch to solve the
> main part of the leak, which is the multiple creation of plugin and ant
> projects. All unit tests pass, but I can't currently bootstrap because of
> some bugs in the execution. I'll work through them soon. I should be ready
> to commit soon after RC1 is cut, and would want to do a little
> polishing/refactoring just to clean up.
>  
> One thing that came up was when I redid the POM inheritence, it seemed the
> previous behaviour was that if <sourceDirectory>src/java</sourceDirectory>
> was given, then the extended project expected to use the same value, but
> relative to its own basedir (ie basedir was evaluated after inheritence, not
> before). There was even a unit test to check this.

Yes, this was definitely intended.
 
> To me, this seems unintuitive - if you are inheriting from something else,
> you should inherit the same path, not the expression that will be changed.
> The question I have is:
> 1) should I fix my code so that it works as it used to, unintuitive as it
> is?

Yes, I think it is best. Here's the reasoning: What is going on is
inheritance of the model. Ideally what we want is a clear separation
between the model and the transformation that ultimately gives us a
Project. For this little discussion lets call what you see in the XML
file the model. We want one project to inherit from a parent verbatim
model-wise.

We don't want interpolated values to be passed on because they may be
overriden in children. And even though we are deprecating the use of
${basedir} you definitely don't want that passed on because in the
context of the child project you do want the basedir of that project. So
you do want the literal expression to be fully inherited but not the
processed expression. Can you see the difference?

We also don't want inherited values passed on for the same reason and
where this becomes critical is the serialization and unserialization of
the model. We want the model to remain intact. If, what I call, runtime
information is mixed then the model you attempt to serialize that it
isn't accurate. For example if you if you have a child that extends from
a parent and you serialize that fully expanded version then what you
have is not the original.

What we have in the component version is the model in a separate jar, a
component for serializing the model, a component for unserializing the
model and then another component for building the project from the model
taking into account inheritance and interpolation. This was done so we
could cleanly separate operations with the model as opposed to Project
which is the model decorated with all sorts of other notions. It's a
muddle in our current code and the serialization/unserialization which
is a must decent IDE integration isn't possible.


> 2) should it inherit the <sourceDirectory/>, etc. value relative to the
> parent's directory?
> 3) should it not inherit the sourceDirectory? If so, what about resources?

Do not change the behaviour at this point and I believe the 1) form is
most correctly.

-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


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

Re: opinions on inheritence of tag

[di...@multitask.com.au]

Brett Porter <bp...@f2network.com.au> wrote on 29/09/2003 08:52:00 AM:

> Hi,
> 
> I think I've implemented all of the code needed from the branch to solve 
the
> main part of the leak, which is the multiple creation of plugin and ant
> projects. All unit tests pass, but I can't currently bootstrap because 
of
> some bugs in the execution. I'll work through them soon. I should be 
ready
> to commit soon after RC1 is cut, and would want to do a little
> polishing/refactoring just to clean up.
Cool!

> One thing that came up was when I redid the POM inheritence, it seemed 
the
> previous behaviour was that if 
<sourceDirectory>src/java</sourceDirectory>
> was given, then the extended project expected to use the same value, but
> relative to its own basedir (ie basedir was evaluated after inheritence, 
not
> before). There was even a unit test to check this.

Yep, values are inherited. The resolution of these values to an absolute 
path should happen post inheritance.

> To me, this seems unintuitive - if you are inheriting from something 
else,
> you should inherit the same path, not the expression that will be 
changed.
> The question I have is:
> 1) should I fix my code so that it works as it used to, unintuitive as 
it
> is?
IMHO, yes.

> 2) should it inherit the <sourceDirectory/>, etc. value relative to the
> parent's directory?
> 3) should it not inherit the sourceDirectory? If so, what about 
resources?
> 
> I'd say we should not inherit any source directories, but should inherit
> resources. This is how I have it implemented, so now POM inheritence
> inherits everything (including merging lists for versions, mailing 
lists,
> etc), except the source directories.
Bummer. This is a feature that is used a lot of places, the maven plugins 
included.

> This probably breaks the way Maven builds because there are some 
subprojects
> in the tests depending on the maven base directory, and likewise the 
plugin
> builds. This can easily be addressed.
> 
> What are people thoughs on this?

That's my .02c.
--
dIon Gillard, Multitask Consulting
Blog:      http://blogs.codehaus.org/people/dion/




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