You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <jv...@maven.org> on 2004/05/01 18:13:24 UTC

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


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