You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Vincent Massol <vm...@pivolis.com> on 2004/05/01 09:37:32 UTC
New build directory structure with RC3 (was RE: [Q] Project properties inheritance with RC3)
Ok thanks. I'll try to reproduce my use case and isolate it.
BTW, although this is a much wanted feature (I was probably one of the
first to ask for it), it'll break most people's build (I don't mind
personally but I feel we need to strongly warn users and propose a
strategy for them - see the directory hierarchy below).
A common build directory architecture so far was:
Topproject
|_ subproject1
|_ subprojetN
where topproject was doing 2 things at once:
- providing project.xml/maven.xml to be reused by subprojects
- providing global build with properties used only for this gloal build
Thus, we the new directory structure should now be:
Toproject
|_ masterbuild
|_ subproject1
|_ subprojetN
where topproject still contains stuff to be inherited by the different
projects and masterbuild is from where you run your master build
(reactor, multiproject, cruisecontrol, etc).
what do you think?
Note: BTW, this is already biting us in maven-plugins (but in a small
way). There is a property maven.clover.report.xml set to true that we
use for the master build. I've just noticed strangely yesterday that
when I was building some maven plugin it would generate 2 clover
reports: one in HTML format and another in XML format. It took me some
time to realize that's because the property was inherited. However we
do not want this. Thus we now need to isolate the master build settings
so that they are not inherited.
Thanks
-Vincent
> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: 01 May 2004 02:41
> To: dev@maven.apache.org
> Subject: Re: [Q] Project properties inheritance with RC3
>
> > What is now supported:
> > A/ project.properites inheritance
> > or
> > B/ inheritance of properties defined in project.xml
> > ?
>
> A
>
> > I've also just tried project.properties inheritance in RC3 and it
wasn't
> > working for me.
>
> Take a look in
src/test/touchstone-tests/src/reactor-build/inheritence. I
> thought this covered everything, but if you've got a different use
case
> thats
> failing, add it in and I'll see if I can fix it.
>
> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New build directory structure with RC3 (was RE: [Q] Project
properties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 03:37, Vincent Massol wrote:
> Ok thanks. I'll try to reproduce my use case and isolate it.
>
> BTW, although this is a much wanted feature (I was probably one of the
> first to ask for it), it'll break most people's build (I don't mind
> personally but I feel we need to strongly warn users and propose a
> strategy for them - see the directory hierarchy below).
Can you integrate this into:
http://wiki.codehaus.org/maven/DirectoryLayout
I've already started using this as a guide for layouts of all the maven2
components.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q] Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 01 May 2004 17:23
> To: Maven Developers List
> Subject: Re: New build directory structure with RC3 (was RE: [Q]
> Projectproperties inheritance with RC3)
>
> On Sat, 2004-05-01 at 03:37, Vincent Massol wrote:
> > Ok thanks. I'll try to reproduce my use case and isolate it.
> >
> > BTW, although this is a much wanted feature (I was probably one of
the
> > first to ask for it), it'll break most people's build (I don't mind
> > personally but I feel we need to strongly warn users and propose a
> > strategy for them - see the directory hierarchy below).
>
> This being for post 1.0, yes?
It's in RC3.
>
> As I want to mesh what I have in maven2 with what is decided
generally.
> It's important because reactor like capabilities are inherent in
maven2
> where it uses the type of the project and the context in which is
being
> to decide the right thing to do. So directory layout is critical and
so
> should not be slapped in pre 1.0.
There is no change to directory layout per see. I was just suggesting
some best practice to suggest to users now that we have properties
inheritance. It didn't matter before, it does now.
-Vincent
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will
come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New build directory structure with RC3 (was RE: [Q] Project
properties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 03:37, Vincent Massol wrote:
> Ok thanks. I'll try to reproduce my use case and isolate it.
>
> BTW, although this is a much wanted feature (I was probably one of the
> first to ask for it), it'll break most people's build (I don't mind
> personally but I feel we need to strongly warn users and propose a
> strategy for them - see the directory hierarchy below).
This being for post 1.0, yes?
As I want to mesh what I have in maven2 with what is decided generally.
It's important because reactor like capabilities are inherent in maven2
where it uses the type of the project and the context in which is being
to decide the right thing to do. So directory layout is critical and so
should not be slapped in pre 1.0.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q]Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Michal Maczka [mailto:mmaczka@interia.pl]
> Sent: 02 May 2004 05:02
> To: Maven Developers List
> Subject: Re: New build directory structure with RC3 (was RE:
> [Q]Projectproperties inheritance with RC3)
>
> Vincent Massol wrote:
>
> >
> >With your idea of master build = common build definitions, how do you
> >manage the properties required by the master build but not require by
> >the subprojects?
> >
> >
>
> I think that this problem is easy to solve. We can e.g have something
> like
> public.properties (those can be inherited)
> private.properties (those are not inherited)
How? Don't forget that we cannot change much for Maven 1.0! I'm not
talking about after where everything is possible. My emails were about
now.
However marking properties as either inheritable or not is complex. If I
have to choose between:
1/
[inheritable]
some.property = some.value
[not inheritable]
some.other.property = some.other.value
and
2/
Either having different properties file or better yet moving master
build in a subdirector.
Then I'd definitely choose option 2 (simpler, not change).
>
>
> But my main concern about this idea in general is quite different.
> Most people are using IDEs these days. And not every IDE is allowing
to
> have very flexible layout of projects.
> For example Eclipse 2.x was very limited and supported praticaly only
> flat (no hierachical) structure of directories.
> I don't know what's the percentage of popularity of each IDE but I
> suppose that Eclipse must be quite high in this ranking.
> Even if just 10% of users is using ( I suppose it's much more) it it
> will be nice to make maven compatible with it.
How does this impact the fact that the master build is located or not in
a subdirectory?
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New build directory structure with RC3 (was RE: [Q]Projectproperties
inheritance with RC3)
Posted by Michal Maczka <mm...@interia.pl>.
Vincent Massol wrote:
>
>With your idea of master build = common build definitions, how do you
>manage the properties required by the master build but not require by
>the subprojects?
>
>
I think that this problem is easy to solve. We can e.g have something like
public.properties (those can be inherited)
private.properties (those are not inherited)
But my main concern about this idea in general is quite different.
Most people are using IDEs these days. And not every IDE is allowing to
have very flexible layout of projects.
For example Eclipse 2.x was very limited and supported praticaly only
flat (no hierachical) structure of directories.
I don't know what's the percentage of popularity of each IDE but I
suppose that Eclipse must be quite high in this ranking.
Even if just 10% of users is using ( I suppose it's much more) it it
will be nice to make maven compatible with it.
Michal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q]Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 01 May 2004 18:13
> To: Maven Developers List
> Subject: RE: New build directory structure with RC3 (was RE:
> [Q]Projectproperties inheritance with RC3)
>
> On Sat, 2004-05-01 at 11:56, Vincent Massol wrote:
>
> > I don't think so. It's separated because there are 2 different
concerns
> > that should be separated:
> >
> > - a master build
>
> Which I feel could disappear entirely, so there wouldn't be a need to
a
> master build per se.
>
> What do you have in your master build?
Building the solution as a whole. Generating aggregated reports. Etc.
In essence exactly the same thing as the continuous build except that
you run it once. Or rather the continuous build is the same as the
master build except that you play it continuously.
>
> > - common build properties and build definitions
>
> Right, these would definitely remain at the top-level.
Which is what I was proposing. I was just moving the master build to a
side directory.
>
> > But master build is completely *different* than common build
> > definitions! To make it clearer, imagine you're using CC for your
master
> > build.
>
> What's in your master build? Aggregation directives? Operations to
> perform once your multiproject goals have run?
Yeah stuff like deploying the artifacts to the remote repo, performing
some rsync stuff, sending mails, publishing results to the intranet,
etc.
>
> > I still haven't understood this concept of "unified source root". Or
if
> > I have I don't see how it can work without having to use tons of
> > include/exclude filters.
>
> No include/exclude filters. With the maven2 alpha I'll will make an
> example of the geronimo build and the plexus build.
Ok
With your idea of master build = common build definitions, how do you
manage the properties required by the master build but not require by
the subprojects?
Note that all of my discussion is based on Maven1, which I'm using right
now. For example, have a look at maven-plugins/project.properties. There
are some properties that should be used only for the master build (e.g.
maven.clover.report.xml = true). But because they are at the top level,
they are inherited by the different subprojects, causing unwanted side
effects.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q]Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
Also, on a different but related subject, do you find it nice to have an
xdocs directory in maven-plugins? I would prefer to have a master
project and put that xdocs dir in there. Same for Fix.java, Fix2.java
and anything else that can crop up. Of course, we should resist the
temptation and move stuff as much as possible in the build itself but it
happens. Like maintenance scripts (like the create-checksum.sh script on
ibiblio), etc.
Just trying some other arguments to convince you... ;-) (don't forget
I'm a consultant!) :-)
Cheers,
-Vincent
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 01 May 2004 18:13
> To: Maven Developers List
> Subject: RE: New build directory structure with RC3 (was RE:
> [Q]Projectproperties inheritance with RC3)
>
> On Sat, 2004-05-01 at 11:56, Vincent Massol wrote:
>
> > I don't think so. It's separated because there are 2 different
concerns
> > that should be separated:
> >
> > - a master build
>
> Which I feel could disappear entirely, so there wouldn't be a need to
a
> master build per se.
>
> What do you have in your master build?
>
> > - common build properties and build definitions
>
> Right, these would definitely remain at the top-level.
>
> > But master build is completely *different* than common build
> > definitions! To make it clearer, imagine you're using CC for your
master
> > build.
>
> What's in your master build? Aggregation directives? Operations to
> perform once your multiproject goals have run?
>
> > I still haven't understood this concept of "unified source root". Or
if
> > I have I don't see how it can work without having to use tons of
> > include/exclude filters.
>
> No include/exclude filters. With the maven2 alpha I'll will make an
> example of the geronimo build and the plexus build.
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will
come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q]
Projectproperties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 11:56, Vincent Massol wrote:
> I don't think so. It's separated because there are 2 different concerns
> that should be separated:
>
> - a master build
Which I feel could disappear entirely, so there wouldn't be a need to a
master build per se.
What do you have in your master build?
> - common build properties and build definitions
Right, these would definitely remain at the top-level.
> But master build is completely *different* than common build
> definitions! To make it clearer, imagine you're using CC for your master
> build.
What's in your master build? Aggregation directives? Operations to
perform once your multiproject goals have run?
> I still haven't understood this concept of "unified source root". Or if
> I have I don't see how it can work without having to use tons of
> include/exclude filters.
No include/exclude filters. With the maven2 alpha I'll will make an
example of the geronimo build and the plexus build.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q] Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 01 May 2004 17:42
> To: Maven Developers List
> Subject: Re: New build directory structure with RC3 (was RE: [Q]
> Projectproperties inheritance with RC3)
>
> On Sat, 2004-05-01 at 10:48, David Jencks wrote:
> > I'd like to propose the geronimo build organization as making more
> > sense (at least to me), although having the same division.
> >
> > We have
> >
> > toplevel (runs complete project build)
> > |-etc (contains maven.xml and project.xml and global.properties)
>
> Why do you have a separate directory, why are these not in the
top-level
> directory. I still have call in with Dain to figure out how your build
> meshes with Maven2 so I'm interested. I think you have things separate
> because of limitations of maven1.
I don't think so. It's separated because there are 2 different concerns
that should be separated:
- a master build
- common build properties and build definitions
They really need to be separated.
>
> You basically have nothing in the top-level project.xml, nothing in
the
> project.properties file and all your logic for selecting which build
you
> want to execute in your maven.xml file.
>
> If the selection types and modules was something inherent in maven you
> wouldn't need most of the code in your maven.xml file and you could
have
> the code in your etc/maven.xml in the top-level.
I don't think so. Maven1 already supports the notion of types/modules
through the maven.multiproject.includes property.
>
> I'm interested because I feel that something like your build can be
> handled without any of the jelly goop you currently have. That from
the
> type of project specified and the context, maven should figure it
out.
>
> > |-type1
> > -|-subproject1
> > -|-subproject2
> > |-type2
> > -|-subproject3
> > -|-subproject4
> >
> > |-target (contains, in our case, runnable geronimo server)
> >
> > This is similar in spirit but has the master build and inheritable
> > pieces reversed.
> > To me it makes more sense to run the master build from the top level
> > folder than to have to find a specific subproject, however well
named.
>
> I agree, information for the master build shold be in the top-level
> directory to support inheritance properly.
But master build is completely *different* than common build
definitions! To make it clearer, imagine you're using CC for your master
build.
>
> If this debate continues I'll pull out the "Unified Source Root" use
> case I have in the wiki for maven2 which addresses most things related
> to highly nested builds for a single umbrella project like geronimo
and
> plexus.
I still haven't understood this concept of "unified source root". Or if
I have I don't see how it can work without having to use tons of
include/exclude filters.
>
> > We have also the idea of "types" of subproject that you can build
> > independently
> >
> > maven -Dtypes=type2
> >
> > will build only the type2 subprojects
> >
> > maven -Dmodules=subproject1,subproject3
> >
> > will build the named subprojects. I don't know how generally useful
> > this would be, but we find it extremely convenient.
>
> Certainly, maybe the nomenclature would change slightly to allow
> different levels of nesting but it is certainly useful.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New build directory structure with RC3 (was RE: [Q] Project
properties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 10:48, David Jencks wrote:
> I'd like to propose the geronimo build organization as making more
> sense (at least to me), although having the same division.
>
> We have
>
> toplevel (runs complete project build)
> |-etc (contains maven.xml and project.xml and global.properties)
Why do you have a separate directory, why are these not in the top-level
directory. I still have call in with Dain to figure out how your build
meshes with Maven2 so I'm interested. I think you have things separate
because of limitations of maven1.
You basically have nothing in the top-level project.xml, nothing in the
project.properties file and all your logic for selecting which build you
want to execute in your maven.xml file.
If the selection types and modules was something inherent in maven you
wouldn't need most of the code in your maven.xml file and you could have
the code in your etc/maven.xml in the top-level.
I'm interested because I feel that something like your build can be
handled without any of the jelly goop you currently have. That from the
type of project specified and the context, maven should figure it out.
> |-type1
> -|-subproject1
> -|-subproject2
> |-type2
> -|-subproject3
> -|-subproject4
>
> |-target (contains, in our case, runnable geronimo server)
>
> This is similar in spirit but has the master build and inheritable
> pieces reversed.
> To me it makes more sense to run the master build from the top level
> folder than to have to find a specific subproject, however well named.
I agree, information for the master build shold be in the top-level
directory to support inheritance properly.
If this debate continues I'll pull out the "Unified Source Root" use
case I have in the wiki for maven2 which addresses most things related
to highly nested builds for a single umbrella project like geronimo and
plexus.
> We have also the idea of "types" of subproject that you can build
> independently
>
> maven -Dtypes=type2
>
> will build only the type2 subprojects
>
> maven -Dmodules=subproject1,subproject3
>
> will build the named subprojects. I don't know how generally useful
> this would be, but we find it extremely convenient.
Certainly, maybe the nomenclature would change slightly to allow
different levels of nesting but it is certainly useful.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New build directory structure with RC3 (was RE: [Q] Project properties inheritance with RC3)
Posted by Emmanuel Venisse <em...@venisse.net>.
I'm ok with you.
----- Original Message -----
From: "David Jencks" <da...@coredevelopers.net>
To: "Maven Developers List" <de...@maven.apache.org>
Sent: Saturday, May 01, 2004 4:48 PM
Subject: Re: New build directory structure with RC3 (was RE: [Q] Project
properties inheritance with RC3)
> I'd like to propose the geronimo build organization as making more
> sense (at least to me), although having the same division.
>
> We have
>
> toplevel (runs complete project build)
> |-etc (contains maven.xml and project.xml and global.properties)
> |-type1
> -|-subproject1
> -|-subproject2
> |-type2
> -|-subproject3
> -|-subproject4
>
> |-target (contains, in our case, runnable geronimo server)
>
> This is similar in spirit but has the master build and inheritable
> pieces reversed.
> To me it makes more sense to run the master build from the top level
> folder than to have to find a specific subproject, however well named.
>
> We have also the idea of "types" of subproject that you can build
> independently
>
> maven -Dtypes=type2
>
> will build only the type2 subprojects
>
> maven -Dmodules=subproject1,subproject3
>
> will build the named subprojects. I don't know how generally useful
> this would be, but we find it extremely convenient.
>
>
> thanks
> david jencks
>
> On Saturday, May 1, 2004, at 12:37 AM, Vincent Massol wrote:
>
> > Ok thanks. I'll try to reproduce my use case and isolate it.
> >
> > BTW, although this is a much wanted feature (I was probably one of the
> > first to ask for it), it'll break most people's build (I don't mind
> > personally but I feel we need to strongly warn users and propose a
> > strategy for them - see the directory hierarchy below).
> >
> > A common build directory architecture so far was:
> >
> > Topproject
> > |_ subproject1
> > |_ subprojetN
> >
> > where topproject was doing 2 things at once:
> > - providing project.xml/maven.xml to be reused by subprojects
> > - providing global build with properties used only for this gloal build
> >
> > Thus, we the new directory structure should now be:
> >
> > Toproject
> > |_ masterbuild
> > |_ subproject1
> > |_ subprojetN
> >
> > where topproject still contains stuff to be inherited by the different
> > projects and masterbuild is from where you run your master build
> > (reactor, multiproject, cruisecontrol, etc).
> >
> > what do you think?
> >
> > Note: BTW, this is already biting us in maven-plugins (but in a small
> > way). There is a property maven.clover.report.xml set to true that we
> > use for the master build. I've just noticed strangely yesterday that
> > when I was building some maven plugin it would generate 2 clover
> > reports: one in HTML format and another in XML format. It took me some
> > time to realize that's because the property was inherited. However we
> > do not want this. Thus we now need to isolate the master build settings
> > so that they are not inherited.
> >
> > Thanks
> > -Vincent
> >
> >
> >> -----Original Message-----
> >> From: Brett Porter [mailto:brett@apache.org]
> >> Sent: 01 May 2004 02:41
> >> To: dev@maven.apache.org
> >> Subject: Re: [Q] Project properties inheritance with RC3
> >>
> >>> What is now supported:
> >>> A/ project.properites inheritance
> >>> or
> >>> B/ inheritance of properties defined in project.xml
> >>> ?
> >>
> >> A
> >>
> >>> I've also just tried project.properties inheritance in RC3 and it
> > wasn't
> >>> working for me.
> >>
> >> Take a look in
> > src/test/touchstone-tests/src/reactor-build/inheritence. I
> >> thought this covered everything, but if you've got a different use
> > case
> >> thats
> >> failing, add it in and I'll see if I can fix it.
> >>
> >> - Brett
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE:
[Q]Projectproperties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 15:42, Vincent Massol wrote:
> My only comment from what is below on "m2 --reactor jar" is that I would
> like to know why you would choose to make the reactor an intrinsic
> feature of the core vs making it a plugin?
I've waffled back and forth on this, as the reactor was intrinsic at
first, then became a tag but I feel for m2 it is a core feature. Far
better control and communication is possible allowing the core to handle
it. Managing multiple project builds has become one of the
distinguishing features of Maven and a behavior distinctly different
from a normal plugin.
> On this same subject, I had suggested a long time ago the notion of a
> Solution Object Model (SOM) comparable to the POM but for a set of
> projects. It would define the attributes/properties of a global master
> build. I haven't pushed it further to know exactly what to put in there,
> but I'm sure it could come handy.
This is handled in m2 using the unified source root, group builds in
addition to global across the board properties.
> I think it would be better to have the reactor/continuum/whatever it's
> called be wrapping m2 instead of making m2 know about it (which "m2
> --reactor" implies). It makes a better separation of concern, I think.
One of the concerns of m2 is dealing with multiple projects builds
cleanly which are far easier it being an intrinsic feature. As opposed
to having a plugin which then needs a reference to the core in order to
execute the goals requested by the plugin. The current reactor tag is,
to put it mildly, a clusterfuck. It doesn't do a whole lot but it's made
far more complicated by requiring a reference to the core. I turned it
around: collect the projects and execute the required goals. It makes it
far easier communicating across the plugins when the core has a
reference to all the projects and it make error handling much easier.
There's just no comparision, the reactor tag in maven1 is bad design on
my part.
> Of course, m2 should be built so that it provides all required
> information for external continuous build tools to be built on top.
M2 is simply embeddable which is what is done with continuum, but it
will be simple for things like CC to just do something like:
Maven maven = new Maven();
And do whatever they want. This is how the mevenide folks are using m2.
I'm working out some glitches but that will be the recommended for of
integration with m2.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q]Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
I think we're having a discussion where there isn't one... :-)
M1
==
Let me summarize. I was sending an email saying that we need to explain
to Maven RC3 users (up to 1.0) that they may now need a different
strategy when multiproject builds because the RC3 release has
project.properties inheritance. At the same time, I was proposing one
solution (again for Maven RC3 - I'm not talking about M2). David's
proposal is also working for RC3.
That's all I was saying. I was not suggesting that we should do this for
post 1.0 nor for m2. But for RC3 you have no choice.
M2
==
Now if you have some ideas for m2, I'm happy to hear them and I'll be
able to tell you if it'll work with the kind of projects I'm working on.
My only comment from what is below on "m2 --reactor jar" is that I would
like to know why you would choose to make the reactor an intrinsic
feature of the core vs making it a plugin?
On this same subject, I had suggested a long time ago the notion of a
Solution Object Model (SOM) comparable to the POM but for a set of
projects. It would define the attributes/properties of a global master
build. I haven't pushed it further to know exactly what to put in there,
but I'm sure it could come handy.
I think it would be better to have the reactor/continuum/whatever it's
called be wrapping m2 instead of making m2 know about it (which "m2
--reactor" implies). It makes a better separation of concern, I think.
Of course, m2 should be built so that it provides all required
information for external continuous build tools to be built on top.
-Vincent
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 01 May 2004 20:54
> To: Maven Developers List
> Subject: RE: New build directory structure with RC3 (was RE:
> [Q]Projectproperties inheritance with RC3)
>
> On Sat, 2004-05-01 at 12:18, Vincent Massol wrote:
>
> > Are you saying that you're using the same strategy to build a single
> > project that you are using to build a 50 subproject project? I
don't.
>
> I wouldn't either. Implicit in a reactor build is a different
behaviour
> all together. I will refer to something like geronimo's or plexus'
> top-level build as the group build. So for things like building all
the
> jars you would do something like:
>
> m2 --reactor jar
>
> Bear with me, there are methods for exluding builds, having named
> reactors with set of properties etc. We'll keep this out of the
> discussion for now.
>
> So for the "jar" this is not that difficult because there really is no
> special behavior required for the context of a reactor build. You just
> build the jar for each project.
>
> Now for something like a report this is different all together. There
is
> some special behaviour for the context of a reactor build. For
> checkstyle for example, you would run checkstyle for each project but
> then in the context of the reactor you would aggregate the information
> in a desired way.
>
> This would be the same for say the site goal executed within the
context
> of the reactor. The site would be generated for each project, but
within
> the context of the reactor the top-level would give you something
> equivalent to your dashboad automatically.
>
> > Are you saying that everyone has its own remote repo installed?
>
> Why would I assume that?
>
> > Not
> > true. For open source project, we use ibiblio for internal projects
at
> > work, we do. Some projects are built with the multiproject, others
are
> > built with CC. Why would you want all of them to use the same
process?
> > They both have pros and cons. I could go on indefinitely.
> >
> > It's a pure fantasy of the mind to believe that all projects have
the
> > same build pre-requisites... :-)
>
> I'm not saying project don't differ in their requirements. I'm saying
> even with differing requirements the build setup can still manifest
> itself in the same way across projects. What I take exception to is
the
> notion that the masterbuild could be done in any way shape or form.
>
> > Yes, the master build is different for each development group. Some
will
> > use the multiproject plugin, others will use DamageControl, others
> > AntHill, others CC, others the mythical continuum :-), etc...
>
> They may use these different things but that doesn't mean the form of
> the masterbuild should be different.
>
> > The needs are different. Each of the strategy above is good in a
certain
> > context.
>
> Different requirements do not imply a different structure as you
> suggest. That is my point.
>
> > You certainly do not want to allow only a single strategy,
> > unless it's a superset of all the previously mentioned systems (in
which
> > case it may become too complex to configure...).
>
> I'm not implying a single strategy, what I'm suggesting is something
> akin to what we have with goal decoration on the level of a single
> project. You can change what happens in the course of the build to
yield
> a different path and subsequently different results. You are not
> changing the fundamental structure of how the build works.
>
> If a master build was allowed to take any form what we are promoting
is
> all for naught. This is where maven will become most useful: in the
> arena of dealing with multiple projects.
>
> In the lack of any standard practice for a setup like
> plexus/geronimo/your stuff you do what's necessary to get things
> working. This is the normal course of things, but what I don't want is
> to see an "anything goes" stance of what the master build looks like.
> The same structure can yield different results is what I'm saying.
Just
> like we have now on the project level.
>
> I know we are at different extremes here: you use maven1 daily with a
> large build and large number of people and I'm pushing the next
> generation of maven. So we are naturally have some differences of
> opinion which is also perfectly fine. All I ask is that long-term
goals
> not be sacrificed for the sake of a gain in short-term utility.
>
> Much like many people once said "There is no way you build so many
> different projects with the same structure" and that seems not to be
the
> case. Given what some see as a rigidity structure has still yielded of
> enough variation to satisfy the requirements of most projects. The
same
> I believe is true for reactor builds. From folks like the people in
> Geronimo, yourself, folks doing the Plexus build a structure will drop
> out in a form that will satisfy the requirements of all those
projects.
>
> > That we want to promote one master build/continuous build tool is
good
> > and I don't mind but we should allow for the diversity as they each
have
> > pros and cons.
>
> All projects have different requirements and that's a fact, and not
one
> I deny. All I'm saying is that the satisfaction of those requirements
> can be gleaned from same fundamental structure. I'm willing to bet
that
> aside from the obvious coding differences between your master build
and
> geronimo's that there really isn't that much fundamentally different.
>
>
> > -Vincent
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> jvz.
>
> Jason van Zyl
> jason@maven.org
> http://maven.apache.org
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will
come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q]
Projectproperties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 12:18, Vincent Massol wrote:
> Are you saying that you're using the same strategy to build a single
> project that you are using to build a 50 subproject project? I don't.
I wouldn't either. Implicit in a reactor build is a different behaviour
all together. I will refer to something like geronimo's or plexus'
top-level build as the group build. So for things like building all the
jars you would do something like:
m2 --reactor jar
Bear with me, there are methods for exluding builds, having named
reactors with set of properties etc. We'll keep this out of the
discussion for now.
So for the "jar" this is not that difficult because there really is no
special behavior required for the context of a reactor build. You just
build the jar for each project.
Now for something like a report this is different all together. There is
some special behaviour for the context of a reactor build. For
checkstyle for example, you would run checkstyle for each project but
then in the context of the reactor you would aggregate the information
in a desired way.
This would be the same for say the site goal executed within the context
of the reactor. The site would be generated for each project, but within
the context of the reactor the top-level would give you something
equivalent to your dashboad automatically.
> Are you saying that everyone has its own remote repo installed?
Why would I assume that?
> Not
> true. For open source project, we use ibiblio for internal projects at
> work, we do. Some projects are built with the multiproject, others are
> built with CC. Why would you want all of them to use the same process?
> They both have pros and cons. I could go on indefinitely.
>
> It's a pure fantasy of the mind to believe that all projects have the
> same build pre-requisites... :-)
I'm not saying project don't differ in their requirements. I'm saying
even with differing requirements the build setup can still manifest
itself in the same way across projects. What I take exception to is the
notion that the masterbuild could be done in any way shape or form.
> Yes, the master build is different for each development group. Some will
> use the multiproject plugin, others will use DamageControl, others
> AntHill, others CC, others the mythical continuum :-), etc...
They may use these different things but that doesn't mean the form of
the masterbuild should be different.
> The needs are different. Each of the strategy above is good in a certain
> context.
Different requirements do not imply a different structure as you
suggest. That is my point.
> You certainly do not want to allow only a single strategy,
> unless it's a superset of all the previously mentioned systems (in which
> case it may become too complex to configure...).
I'm not implying a single strategy, what I'm suggesting is something
akin to what we have with goal decoration on the level of a single
project. You can change what happens in the course of the build to yield
a different path and subsequently different results. You are not
changing the fundamental structure of how the build works.
If a master build was allowed to take any form what we are promoting is
all for naught. This is where maven will become most useful: in the
arena of dealing with multiple projects.
In the lack of any standard practice for a setup like
plexus/geronimo/your stuff you do what's necessary to get things
working. This is the normal course of things, but what I don't want is
to see an "anything goes" stance of what the master build looks like.
The same structure can yield different results is what I'm saying. Just
like we have now on the project level.
I know we are at different extremes here: you use maven1 daily with a
large build and large number of people and I'm pushing the next
generation of maven. So we are naturally have some differences of
opinion which is also perfectly fine. All I ask is that long-term goals
not be sacrificed for the sake of a gain in short-term utility.
Much like many people once said "There is no way you build so many
different projects with the same structure" and that seems not to be the
case. Given what some see as a rigidity structure has still yielded of
enough variation to satisfy the requirements of most projects. The same
I believe is true for reactor builds. From folks like the people in
Geronimo, yourself, folks doing the Plexus build a structure will drop
out in a form that will satisfy the requirements of all those projects.
> That we want to promote one master build/continuous build tool is good
> and I don't mind but we should allow for the diversity as they each have
> pros and cons.
All projects have different requirements and that's a fact, and not one
I deny. All I'm saying is that the satisfaction of those requirements
can be gleaned from same fundamental structure. I'm willing to bet that
aside from the obvious coding differences between your master build and
geronimo's that there really isn't that much fundamentally different.
> -Vincent
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q] Projectproperties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 01 May 2004 18:06
> To: Maven Developers List
> Subject: RE: New build directory structure with RC3 (was RE: [Q]
> Projectproperties inheritance with RC3)
>
> On Sat, 2004-05-01 at 11:51, Vincent Massol wrote:
>
> > Yes, except that:
> >
> > 1/ etc/ does not really mean anything.
> > 2/ more importantly your solution works well when the master build
is
> > simple but less well when it's complex. I'm working on a big project
and
> > our master build is relatively complex (we rely on CC) with lots of
> > configuration files (CC configs mostly) and it warrants a separate
> > project.
>
> I don't agree, with plexus there are only 50-60 builds (not like your
> 300) but I feel that from project type and context everything should
be
> deterministic as far as what you want to build.
>
> > I do agree that for smaller projects with simpler master build (like
> > simply using the multiproject plugin), your solution makes sense.
> >
> > In any case we do not have to promote only a single option. I'd say
we
> > should describe both solution with your solution as preferred and
the
> > one I was proposing as second option.
>
> Why? This is exactly what we strive to avoid as the fundamental tenet
of
> this project: multiple ways of doing the same thing leads to problems.
Are you saying that you're using the same strategy to build a single
project that you are using to build a 50 subproject project? I don't.
Are you saying that everyone has its own remote repo installed? Not
true. For open source project, we use ibiblio for internal projects at
work, we do. Some projects are built with the multiproject, others are
built with CC. Why would you want all of them to use the same process?
They both have pros and cons. I could go on indefinitely.
It's a pure fantasy of the mind to believe that all projects have the
same build pre-requisites... :-)
>
> > The only important part (which we both agree on) is to separate the
> > notion of master project from that of common build
> > definition/properties.
>
> I believe this will lead to massive coherence problems as each
> development group is going to have something entirely different in
their
> master build which is something I believe can be done internally and
> handled in a consistent fashion. Whereas if we contrast what you have
in
> your build and what geronimo has they are probably entirely different
> which is not what we strive for in this project.
Yes, the master build is different for each development group. Some will
use the multiproject plugin, others will use DamageControl, others
AntHill, others CC, others the mythical continuum :-), etc...
The needs are different. Each of the strategy above is good in a certain
context. You certainly do not want to allow only a single strategy,
unless it's a superset of all the previously mentioned systems (in which
case it may become too complex to configure...).
That we want to promote one master build/continuous build tool is good
and I don't mind but we should allow for the diversity as they each have
pros and cons.
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q] Project
properties inheritance with RC3)
Posted by Jason van Zyl <jv...@maven.org>.
On Sat, 2004-05-01 at 11:51, Vincent Massol wrote:
> Yes, except that:
>
> 1/ etc/ does not really mean anything.
> 2/ more importantly your solution works well when the master build is
> simple but less well when it's complex. I'm working on a big project and
> our master build is relatively complex (we rely on CC) with lots of
> configuration files (CC configs mostly) and it warrants a separate
> project.
I don't agree, with plexus there are only 50-60 builds (not like your
300) but I feel that from project type and context everything should be
deterministic as far as what you want to build.
> I do agree that for smaller projects with simpler master build (like
> simply using the multiproject plugin), your solution makes sense.
>
> In any case we do not have to promote only a single option. I'd say we
> should describe both solution with your solution as preferred and the
> one I was proposing as second option.
Why? This is exactly what we strive to avoid as the fundamental tenet of
this project: multiple ways of doing the same thing leads to problems.
> The only important part (which we both agree on) is to separate the
> notion of master project from that of common build
> definition/properties.
I believe this will lead to massive coherence problems as each
development group is going to have something entirely different in their
master build which is something I believe can be done internally and
handled in a consistent fashion. Whereas if we contrast what you have in
your build and what geronimo has they are probably entirely different
which is not what we strive for in this project.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: New build directory structure with RC3 (was RE: [Q] Project properties inheritance with RC3)
Posted by Vincent Massol <vm...@pivolis.com>.
Hi David,
> -----Original Message-----
> From: David Jencks [mailto:david@coredevelopers.net]
> Sent: 01 May 2004 16:48
> To: Maven Developers List
> Subject: Re: New build directory structure with RC3 (was RE: [Q]
Project
> properties inheritance with RC3)
>
> I'd like to propose the geronimo build organization as making more
> sense (at least to me), although having the same division.
>
> We have
>
> toplevel (runs complete project build)
> |-etc (contains maven.xml and project.xml and global.properties)
> |-type1
> -|-subproject1
> -|-subproject2
> |-type2
> -|-subproject3
> -|-subproject4
>
> |-target (contains, in our case, runnable geronimo server)
>
> This is similar in spirit but has the master build and inheritable
> pieces reversed.
> To me it makes more sense to run the master build from the top level
> folder than to have to find a specific subproject, however well named.
Yes, except that:
1/ etc/ does not really mean anything.
2/ more importantly your solution works well when the master build is
simple but less well when it's complex. I'm working on a big project and
our master build is relatively complex (we rely on CC) with lots of
configuration files (CC configs mostly) and it warrants a separate
project.
I do agree that for smaller projects with simpler master build (like
simply using the multiproject plugin), your solution makes sense.
In any case we do not have to promote only a single option. I'd say we
should describe both solution with your solution as preferred and the
one I was proposing as second option.
>
> We have also the idea of "types" of subproject that you can build
> independently
>
> maven -Dtypes=type2
>
> will build only the type2 subprojects
>
> maven -Dmodules=subproject1,subproject3
>
> will build the named subprojects. I don't know how generally useful
> this would be, but we find it extremely convenient.
Yes, this is conveninent. But this is built-in with the
reactor/multiproject, no? We have the same notion, except we use the
maven.multiproject.includes property (actually we have a property named
pattern: maven.multiproject.includes=**/${pattern}. For example:
maven -Dpattern=type1 whatever
[snip]
The only important part (which we both agree on) is to separate the
notion of master project from that of common build
definition/properties.
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: New build directory structure with RC3 (was RE: [Q] Project properties inheritance with RC3)
Posted by David Jencks <da...@coredevelopers.net>.
I'd like to propose the geronimo build organization as making more
sense (at least to me), although having the same division.
We have
toplevel (runs complete project build)
|-etc (contains maven.xml and project.xml and global.properties)
|-type1
-|-subproject1
-|-subproject2
|-type2
-|-subproject3
-|-subproject4
|-target (contains, in our case, runnable geronimo server)
This is similar in spirit but has the master build and inheritable
pieces reversed.
To me it makes more sense to run the master build from the top level
folder than to have to find a specific subproject, however well named.
We have also the idea of "types" of subproject that you can build
independently
maven -Dtypes=type2
will build only the type2 subprojects
maven -Dmodules=subproject1,subproject3
will build the named subprojects. I don't know how generally useful
this would be, but we find it extremely convenient.
thanks
david jencks
On Saturday, May 1, 2004, at 12:37 AM, Vincent Massol wrote:
> Ok thanks. I'll try to reproduce my use case and isolate it.
>
> BTW, although this is a much wanted feature (I was probably one of the
> first to ask for it), it'll break most people's build (I don't mind
> personally but I feel we need to strongly warn users and propose a
> strategy for them - see the directory hierarchy below).
>
> A common build directory architecture so far was:
>
> Topproject
> |_ subproject1
> |_ subprojetN
>
> where topproject was doing 2 things at once:
> - providing project.xml/maven.xml to be reused by subprojects
> - providing global build with properties used only for this gloal build
>
> Thus, we the new directory structure should now be:
>
> Toproject
> |_ masterbuild
> |_ subproject1
> |_ subprojetN
>
> where topproject still contains stuff to be inherited by the different
> projects and masterbuild is from where you run your master build
> (reactor, multiproject, cruisecontrol, etc).
>
> what do you think?
>
> Note: BTW, this is already biting us in maven-plugins (but in a small
> way). There is a property maven.clover.report.xml set to true that we
> use for the master build. I've just noticed strangely yesterday that
> when I was building some maven plugin it would generate 2 clover
> reports: one in HTML format and another in XML format. It took me some
> time to realize that's because the property was inherited. However we
> do not want this. Thus we now need to isolate the master build settings
> so that they are not inherited.
>
> Thanks
> -Vincent
>
>
>> -----Original Message-----
>> From: Brett Porter [mailto:brett@apache.org]
>> Sent: 01 May 2004 02:41
>> To: dev@maven.apache.org
>> Subject: Re: [Q] Project properties inheritance with RC3
>>
>>> What is now supported:
>>> A/ project.properites inheritance
>>> or
>>> B/ inheritance of properties defined in project.xml
>>> ?
>>
>> A
>>
>>> I've also just tried project.properties inheritance in RC3 and it
> wasn't
>>> working for me.
>>
>> Take a look in
> src/test/touchstone-tests/src/reactor-build/inheritence. I
>> thought this covered everything, but if you've got a different use
> case
>> thats
>> failing, add it in and I'll see if I can fix it.
>>
>> - Brett
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org