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/23 22:13:15 UTC
[Strategy] How to manage several subprojects as one project?
Hi guys,
I'm still trying to slowly convert the Cactus build (which uses Ant)
into a Maven build. Here's a use case I have. Currently I have the
following:
framework/
|_ src
|_ share-12-13-14
|_ share-13-14
|_ j2ee-12
|_ j2ee-13
|_ j2ee-14
|_ build.xml
|_ [...]
Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
respectively). The share directories contain common classes for the
different API versions. Of course the build for the different APIs have
different dependencies.
To transform this into a Maven 1.x build, it seems that what makes most
sense is to have the following:
framework/
|_ share-12-13-14
|_ src
|_ share-13-14
|_ src
|_ j2ee-12
|_ src
|_ j2ee-13
|_ src
|_ j2ee-14
|- src
(i.e. a project per src directory).
However, there are several issues:
1- I don't want to publicly expose the share-12-13-14 jar artifact for
example. Thus it would be best to have some interproject "channel" that
do not go into the local Maven repo.
2- I still to only deliver 3 jars (one for each API), thus I need to
regroup the different jars. For example for J2EE API 1.3, I need to
regroup the share-12-13-14 + share-13-14 + j2ee-13 jars. I don't think
that uberjar does exactly this. Of course it should be possible to
develop a plugin for this if there is no other solution. It's a bit of a
pain to have to jar the output from subprojects to then have to unjar
jar to again rejar everything a main framework jar. It would be nice to
be able to exchange classes artifact between the different subprojects.
3- More generally, I'd like to consider the framework project as one
virtual project, i.e. have only a single site, single javadoc, etc.
In light of this, it seems to me that the only reason to have different
subprojects is to have the ability to define different dependencies for
the different J2EE APIs. Thus maybe there is another solution using
dynamic dependencies (not sure how that would work though).
Any take on this use case for Maven 1.x?
Is that a known use case for m2?
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Strategy] How to manage several subprojects as one project?
Posted by Jerome Lacoste <je...@coffeebreaks.org>.
On Sun, 2004-05-23 at 16:13, Vincent Massol wrote:
> Hi guys,
>
> I'm still trying to slowly convert the Cactus build (which uses Ant)
> into a Maven build. Here's a use case I have. Currently I have the
> following:
[...]
I am wondering if the notion of module, being a sub-part of a project, should be brought to maven one day.
IDEs, such as IDEA, allow for a project to contain several modules (web module, J2EE module, ...). These modules can be made so they have no significance outside the project, like the modules Vincent wants to see in cactus.
I understand the requirements. It's like basic encapsulation. Sometimes you don't want to expose every component, otherwise someone might create dependencies on them, making them more costly to change.
So I could see the notion of modules as a sub-part of a project appear one day in maven.
The idea would then be how to make this implementation. Reuse project inheritance sounds great, but maybe some things are missing in order to make them more user friendly. Adding a tag to a project to disable some of the operations, like jar might help.
Allowing to reference and reuse/merge the build artifacts (classes, documentation...) would be a requirement.
Finally, maybe something helping to define the type of a module is needed. That would help to have things like automatic building of a web module for us. More code reuse for more projects.
How do requirements like that fit with maven or maven2?
I am currently trying to make project inheritance work. Didn't find much info in the doc to see how it actually works. Will have to look at the examples in the test code.
Cheers,
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [Strategy] How to manage several subprojects as one project?
Posted by Vincent Massol <vm...@pivolis.com>.
Jerome,
Thank you for your answers. However my goal is to use Maven and to
discuss a possible strategy within Maven to support this use case. The
Cactus project already has a build and it works fine. I'm trying to
figure out the best possible strategy with Maven.
So far you're the only one to have provided your view. I was hoping to
get other Maven developer's feedback too.
Thanks
-Vincent
> -----Original Message-----
> From: Jerome Lacoste [mailto:jerome@coffeebreaks.org]
> Sent: 25 May 2004 14:05
> To: Maven Developers List
> Subject: RE: [Strategy] How to manage several subprojects as one
project?
>
> On Mon, 2004-05-24 at 08:09, Vincent Massol wrote:
> > Hi Jerome,
> >
> > > -----Original Message-----
> > > From: Jerome Lacoste [mailto:jerome@coffeebreaks.org]
> > > Sent: 24 May 2004 06:48
> > > To: Maven Developers List
> > > Subject: Re: [Strategy] How to manage several subprojects as one
> > project?
> > >
> > > On Sun, 2004-05-23 at 16:13, Vincent Massol wrote:
> > > > Hi guys,
> > > >
> > > > I'm still trying to slowly convert the Cactus build (which uses
Ant)
> > > > into a Maven build. Here's a use case I have. Currently I have
the
> > > > following:
> > > >
> > > > framework/
> > > > |_ src
> > > > |_ share-12-13-14
> > > > |_ share-13-14
> > > > |_ j2ee-12
> > > > |_ j2ee-13
> > > > |_ j2ee-14
> > > > |_ build.xml
> > > > |_ [...]
> > > >
> > > > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > > > respectively). The share directories contain common classes for
the
> > > > different API versions. Of course the build for the different
APIs
> > have
> > > > different dependencies.
> > > >
> > > > To transform this into a Maven 1.x build, it seems that what
makes
> > most
> > > > sense is to have the following:
> > > >
> > > > framework/
> > > > |_ share-12-13-14
> > > > |_ src
> > > > |_ share-13-14
> > > > |_ src
> > > > |_ j2ee-12
> > > > |_ src
> > > > |_ j2ee-13
> > > > |_ src
> > > > |_ j2ee-14
> > > > |- src
> > > >
> > > > (i.e. a project per src directory).
> > > >
> > > > However, there are several issues:
> > > > 1- I don't want to publicly expose the share-12-13-14 jar
artifact
> > for
> > > > example. Thus it would be best to have some interproject
"channel"
> > that
> > > > do not go into the local Maven repo.
> > > > 2- I still to only deliver 3 jars (one for each API), thus I
need to
> > > > regroup the different jars. For example for J2EE API 1.3, I need
to
> > > > regroup the share-12-13-14 + share-13-14 + j2ee-13 jars. I don't
> > think
> > > > that uberjar does exactly this. Of course it should be possible
to
> > > > develop a plugin for this if there is no other solution. It's a
bit
> > of a
> > > > pain to have to jar the output from subprojects to then have to
> > unjar
> > > > jar to again rejar everything a main framework jar. It would be
nice
> > to
> > > > be able to exchange classes artifact between the different
> > subprojects.
> > > > 3- More generally, I'd like to consider the framework project as
one
> > > > virtual project, i.e. have only a single site, single javadoc,
etc.
> > > >
> > > > In light of this, it seems to me that the only reason to have
> > different
> > > > subprojects is to have the ability to define different
dependencies
> > for
> > > > the different J2EE APIs. Thus maybe there is another solution
using
> > > > dynamic dependencies (not sure how that would work though).
> > > >
> > > > Any take on this use case for Maven 1.x?
> > > >
> > > > Is that a known use case for m2?
> > > >
> > > > Thanks
> > > > -Vincent
> > >
> > > I am not a maven expert at all, but with regards to not exposing
your
> > > shared jars, what about the following:
> > >
> > > - your build is a 2 stage process where you first build the
required
> > > dependencies and place them in a local repository
> > > - the second phase uses your built jar files to finish the work
and
> > > publish
> > >
> > > e.g.
> > >
> > > target/tmp-repos/share-12-13-14/jars
> > > target/tmp-repos/share-13-14/jars
> > > etc...
> > >
> > > project.properties=...
> > > manve.remote.repos=[ibiblio...],./target/tmp-repos/
> >
> > Is that something you've done in practice?
>
> No....
>
> > How do you deploy your jars
> > to the local repository (will jar:install work with several
> > repositories?)
>
> copying manually ?
>
> > How do you manage (in term of time-consumption) the fact
> > that Maven will try looking first on ibiblio, display some error
message
> > and then only try the second repos?
>
> this I can answer because I don't use ibiblio on my personnal
projects.
> I always have ibiblio first and local repos after and it's not slow
(on
> Linux)
>
> > How do you solve the other issues I have listed above, namely points
2
> > and 3?
>
> don't know!
>
> > > You may need to make a split into your dependencies & your
project,
> > using
> > > sub-projects. But I think this should work with the.
> > >
> > > Would that work?
> > > I think it solves 1.
> >
> > In theory yes. In practice I don't think so :-)
> >
> > I still need to get a solution for the other points though.
>
> Maybe that doesn't cut it...
>
> Are you sure you want to use your own sub projects?
> What about handling the problem in a simpler way. Keep something
similar
> to the original layout and try to make the compilation, the jars
yourself?
>
> It's not cute but if it works....
>
> Jerome
>
>
> ---------------------------------------------------------------------
> 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: [Strategy] How to manage several subprojects as one project?
Posted by Jerome Lacoste <je...@coffeebreaks.org>.
On Mon, 2004-05-24 at 08:09, Vincent Massol wrote:
> Hi Jerome,
>
> > -----Original Message-----
> > From: Jerome Lacoste [mailto:jerome@coffeebreaks.org]
> > Sent: 24 May 2004 06:48
> > To: Maven Developers List
> > Subject: Re: [Strategy] How to manage several subprojects as one
> project?
> >
> > On Sun, 2004-05-23 at 16:13, Vincent Massol wrote:
> > > Hi guys,
> > >
> > > I'm still trying to slowly convert the Cactus build (which uses Ant)
> > > into a Maven build. Here's a use case I have. Currently I have the
> > > following:
> > >
> > > framework/
> > > |_ src
> > > |_ share-12-13-14
> > > |_ share-13-14
> > > |_ j2ee-12
> > > |_ j2ee-13
> > > |_ j2ee-14
> > > |_ build.xml
> > > |_ [...]
> > >
> > > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > > respectively). The share directories contain common classes for the
> > > different API versions. Of course the build for the different APIs
> have
> > > different dependencies.
> > >
> > > To transform this into a Maven 1.x build, it seems that what makes
> most
> > > sense is to have the following:
> > >
> > > framework/
> > > |_ share-12-13-14
> > > |_ src
> > > |_ share-13-14
> > > |_ src
> > > |_ j2ee-12
> > > |_ src
> > > |_ j2ee-13
> > > |_ src
> > > |_ j2ee-14
> > > |- src
> > >
> > > (i.e. a project per src directory).
> > >
> > > However, there are several issues:
> > > 1- I don't want to publicly expose the share-12-13-14 jar artifact
> for
> > > example. Thus it would be best to have some interproject "channel"
> that
> > > do not go into the local Maven repo.
> > > 2- I still to only deliver 3 jars (one for each API), thus I need to
> > > regroup the different jars. For example for J2EE API 1.3, I need to
> > > regroup the share-12-13-14 + share-13-14 + j2ee-13 jars. I don't
> think
> > > that uberjar does exactly this. Of course it should be possible to
> > > develop a plugin for this if there is no other solution. It's a bit
> of a
> > > pain to have to jar the output from subprojects to then have to
> unjar
> > > jar to again rejar everything a main framework jar. It would be nice
> to
> > > be able to exchange classes artifact between the different
> subprojects.
> > > 3- More generally, I'd like to consider the framework project as one
> > > virtual project, i.e. have only a single site, single javadoc, etc.
> > >
> > > In light of this, it seems to me that the only reason to have
> different
> > > subprojects is to have the ability to define different dependencies
> for
> > > the different J2EE APIs. Thus maybe there is another solution using
> > > dynamic dependencies (not sure how that would work though).
> > >
> > > Any take on this use case for Maven 1.x?
> > >
> > > Is that a known use case for m2?
> > >
> > > Thanks
> > > -Vincent
> >
> > I am not a maven expert at all, but with regards to not exposing your
> > shared jars, what about the following:
> >
> > - your build is a 2 stage process where you first build the required
> > dependencies and place them in a local repository
> > - the second phase uses your built jar files to finish the work and
> > publish
> >
> > e.g.
> >
> > target/tmp-repos/share-12-13-14/jars
> > target/tmp-repos/share-13-14/jars
> > etc...
> >
> > project.properties=...
> > manve.remote.repos=[ibiblio...],./target/tmp-repos/
>
> Is that something you've done in practice?
No....
> How do you deploy your jars
> to the local repository (will jar:install work with several
> repositories?)
copying manually ?
> How do you manage (in term of time-consumption) the fact
> that Maven will try looking first on ibiblio, display some error message
> and then only try the second repos?
this I can answer because I don't use ibiblio on my personnal projects.
I always have ibiblio first and local repos after and it's not slow (on
Linux)
> How do you solve the other issues I have listed above, namely points 2
> and 3?
don't know!
> > You may need to make a split into your dependencies & your project,
> using
> > sub-projects. But I think this should work with the.
> >
> > Would that work?
> > I think it solves 1.
>
> In theory yes. In practice I don't think so :-)
>
> I still need to get a solution for the other points though.
Maybe that doesn't cut it...
Are you sure you want to use your own sub projects?
What about handling the problem in a simpler way. Keep something similar to the original layout and try to make the compilation, the jars yourself?
It's not cute but if it works....
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [Strategy] How to manage several subprojects as one project?
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Jerome,
> -----Original Message-----
> From: Jerome Lacoste [mailto:jerome@coffeebreaks.org]
> Sent: 24 May 2004 06:48
> To: Maven Developers List
> Subject: Re: [Strategy] How to manage several subprojects as one
project?
>
> On Sun, 2004-05-23 at 16:13, Vincent Massol wrote:
> > Hi guys,
> >
> > I'm still trying to slowly convert the Cactus build (which uses Ant)
> > into a Maven build. Here's a use case I have. Currently I have the
> > following:
> >
> > framework/
> > |_ src
> > |_ share-12-13-14
> > |_ share-13-14
> > |_ j2ee-12
> > |_ j2ee-13
> > |_ j2ee-14
> > |_ build.xml
> > |_ [...]
> >
> > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > respectively). The share directories contain common classes for the
> > different API versions. Of course the build for the different APIs
have
> > different dependencies.
> >
> > To transform this into a Maven 1.x build, it seems that what makes
most
> > sense is to have the following:
> >
> > framework/
> > |_ share-12-13-14
> > |_ src
> > |_ share-13-14
> > |_ src
> > |_ j2ee-12
> > |_ src
> > |_ j2ee-13
> > |_ src
> > |_ j2ee-14
> > |- src
> >
> > (i.e. a project per src directory).
> >
> > However, there are several issues:
> > 1- I don't want to publicly expose the share-12-13-14 jar artifact
for
> > example. Thus it would be best to have some interproject "channel"
that
> > do not go into the local Maven repo.
> > 2- I still to only deliver 3 jars (one for each API), thus I need to
> > regroup the different jars. For example for J2EE API 1.3, I need to
> > regroup the share-12-13-14 + share-13-14 + j2ee-13 jars. I don't
think
> > that uberjar does exactly this. Of course it should be possible to
> > develop a plugin for this if there is no other solution. It's a bit
of a
> > pain to have to jar the output from subprojects to then have to
unjar
> > jar to again rejar everything a main framework jar. It would be nice
to
> > be able to exchange classes artifact between the different
subprojects.
> > 3- More generally, I'd like to consider the framework project as one
> > virtual project, i.e. have only a single site, single javadoc, etc.
> >
> > In light of this, it seems to me that the only reason to have
different
> > subprojects is to have the ability to define different dependencies
for
> > the different J2EE APIs. Thus maybe there is another solution using
> > dynamic dependencies (not sure how that would work though).
> >
> > Any take on this use case for Maven 1.x?
> >
> > Is that a known use case for m2?
> >
> > Thanks
> > -Vincent
>
> I am not a maven expert at all, but with regards to not exposing your
> shared jars, what about the following:
>
> - your build is a 2 stage process where you first build the required
> dependencies and place them in a local repository
> - the second phase uses your built jar files to finish the work and
> publish
>
> e.g.
>
> target/tmp-repos/share-12-13-14/jars
> target/tmp-repos/share-13-14/jars
> etc...
>
> project.properties=...
> manve.remote.repos=[ibiblio...],./target/tmp-repos/
Is that something you've done in practice? How do you deploy your jars
to the local repository (will jar:install work with several
repositories?) How do you manage (in term of time-consumption) the fact
that Maven will try looking first on ibiblio, display some error message
and then only try the second repos?
How do you solve the other issues I have listed above, namely points 2
and 3?
>
> You may need to make a split into your dependencies & your project,
using
> sub-projects. But I think this should work with the.
>
> Would that work?
> I think it solves 1.
In theory yes. In practice I don't think so :-)
I still need to get a solution for the other points though.
>
> Can you work from there to satisfy the other requirements?
How? :-)
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Strategy] How to manage several subprojects as one project?
Posted by Jerome Lacoste <je...@coffeebreaks.org>.
On Sun, 2004-05-23 at 16:13, Vincent Massol wrote:
> Hi guys,
>
> I'm still trying to slowly convert the Cactus build (which uses Ant)
> into a Maven build. Here's a use case I have. Currently I have the
> following:
>
> framework/
> |_ src
> |_ share-12-13-14
> |_ share-13-14
> |_ j2ee-12
> |_ j2ee-13
> |_ j2ee-14
> |_ build.xml
> |_ [...]
>
> Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> respectively). The share directories contain common classes for the
> different API versions. Of course the build for the different APIs have
> different dependencies.
>
> To transform this into a Maven 1.x build, it seems that what makes most
> sense is to have the following:
>
> framework/
> |_ share-12-13-14
> |_ src
> |_ share-13-14
> |_ src
> |_ j2ee-12
> |_ src
> |_ j2ee-13
> |_ src
> |_ j2ee-14
> |- src
>
> (i.e. a project per src directory).
>
> However, there are several issues:
> 1- I don't want to publicly expose the share-12-13-14 jar artifact for
> example. Thus it would be best to have some interproject "channel" that
> do not go into the local Maven repo.
> 2- I still to only deliver 3 jars (one for each API), thus I need to
> regroup the different jars. For example for J2EE API 1.3, I need to
> regroup the share-12-13-14 + share-13-14 + j2ee-13 jars. I don't think
> that uberjar does exactly this. Of course it should be possible to
> develop a plugin for this if there is no other solution. It's a bit of a
> pain to have to jar the output from subprojects to then have to unjar
> jar to again rejar everything a main framework jar. It would be nice to
> be able to exchange classes artifact between the different subprojects.
> 3- More generally, I'd like to consider the framework project as one
> virtual project, i.e. have only a single site, single javadoc, etc.
>
> In light of this, it seems to me that the only reason to have different
> subprojects is to have the ability to define different dependencies for
> the different J2EE APIs. Thus maybe there is another solution using
> dynamic dependencies (not sure how that would work though).
>
> Any take on this use case for Maven 1.x?
>
> Is that a known use case for m2?
>
> Thanks
> -Vincent
I am not a maven expert at all, but with regards to not exposing your shared jars, what about the following:
- your build is a 2 stage process where you first build the required dependencies and place them in a local repository
- the second phase uses your built jar files to finish the work and publish
e.g.
target/tmp-repos/share-12-13-14/jars
target/tmp-repos/share-13-14/jars
etc...
project.properties=...
manve.remote.repos=[ibiblio...],./target/tmp-repos/
You may need to make a split into your dependencies & your project, using sub-projects. But I think this should work with the.
Would that work?
I think it solves 1.
Can you work from there to satisfy the other requirements?
Jerome
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [Strategy] How to manage several subprojects as one project?
Posted by Emmanuel Venisse <em...@venisse.net>.
----- Original Message -----
From: "Vincent Massol" <vm...@pivolis.com>
To: "'Maven Developers List'" <de...@maven.apache.org>
Sent: Wednesday, May 26, 2004 8:53 AM
Subject: RE: [Strategy] How to manage several subprojects as one project?
> Hi Rafal,
>
> Thanks for your good feedback. I have 2 comments:
>
> 1/ Performing a jar then an unjar and again a jar is time consuming.
> There is really no need to do this. It is forced on us by Maven which is
> not so good. It's the same situation if you're doing code generation.
> ATM you have to pass the source jar to a second project that will unjar
> them to generate code from the source.
>
> Maybe a solution would be to have a new artifact type of "classes" which
> would point to the top level of package directories. That was there is
> no need to jar and unjar.
>
> Or more generically an artifact type of "directory" structure where you
> can put anything expanded in there (source code, class files, etc)?
You can already do it with resources tag in pom.
>
> 2/ These share-12-13-14 and share-13-14 subprojects have no functional
> meaning and I'd like to have a single javadoc report, a single site, a
> single checkstyle errors, etc.
>
> I think this point 2 is my main problem. It's fine to have several
> subprojects when they have a functional meaning but I don't feel this is
> the case. This problem is all the more evident in that Cactus already
> has an existing build which does this and it's hard to justify to users
> that we have something "less" good because of a technical problem. If we
> don't have a single site, looking at reports is harder because you have
> to navigate to different location to get a full vision (which is BTW the
> reason for the dashboard plugin I have started).
>
> Any other ideas?
>
> Thanks for your help
> -Vincent
>
> > -----Original Message-----
> > From: Rafal Krzewski [mailto:Rafal.Krzewski@caltha.pl]
> > Sent: 26 May 2004 00:08
> > To: Maven Developers List
> > Subject: Re: [Strategy] How to manage several subprojects as one
> project?
> >
> > Jason van Zyl wrote:
> > > On Tue, 2004-05-25 at 12:05, Vincent Massol wrote:
> > >
> > >>Hi Carlos,
> > >
> > >
> > >>I still believe we're missing a "local/private" repository kind of
> stuff
> > >>to share non-public data between projects. Or something equivalent.
> > >
> > >
> > > I honestly don't understand this requirement. What is really the
> > > difference between referencing the generated artifact from the local
> > > repository or the target directory of the build in question. Which
> you
> > > can do with a JAR override:
> > >
> > > maven.jar.foo = ${basedir}../other-project/target/whatever.jar
> >
> > I think it's a bad practice. I always put this setting in my
> > build.properties:
> >
> maven.buil.dir=/home/rafal/maven-targets/${pom.groupId}/${pom.artifactId
> }
> > This is to avoid swamping my eclipse workspace with thousands of
> > generated files. Boosts search performance a great deal, eliminating
> > false positives at the same time. This is probably useful with other
> > IDEs too!
> > So, I would recommend pulling the artifact from the local repo in such
> > situations.
> >
> > > Or with the unified source directory in m2 this will also be easy.
> > >
> > > But what do you really see as the problem with deploying JARs to the
> > > local repo for use amongst your projects?
> >
> > Jason is right. Everthing that shows up in your local repo during
> build
> > process through *:install[-snapshot] can be considered your project's
> > private data. Only artifacts that you *:deploy[-snapshot] are the
> public
> > stuff. Excuse me if I missed something important in the earlier
> > discussion, but I think you could build your private partial jars in
> > separate projects, and then combine them together in other agregator
> > projects. You could specify explicit dependencies among all of these,
> so
> > that reactor built them in the correct order. The aggregator projects
> > would have to use a bit of custom jelly scripting to pull the required
> > jars from the local repo, unzip them and zip the whole thing together
> > again. You would probably need a custom goal for doing the deployment,
> > you don't want to just run multiproject:deploy, because it would
> publish
> > your internal jars. You could override jar:deploy and
> > jar:deploy-install goals in the partial jar projects to fail in order
> to
> > prevent deploying them accidentally.
> > I think this strategy if pretty straightforward, follows Maven's
> single
> > project - single artifact philosophy, and can be easily layed out in a
> > flat (no project nesting) Eclipse friendly way.
> >
> > cactus-parent (parent POM for all projects)
> > cactus-build (multiproject driver)
> > cactus-partial-12-13-14
> > cactus-partial-13-14 (dep. -12-13-14)
> > cactus-partial-12 (dep. -12-13-14)
> > cactus-partial-13 (dep. -12-13-14 -13-14)
> > cactus-partial-14 (dep. -12-13-14 -13-14)
> > cactus-jdk12 (dep. -12-13-14 -12)
> > cactus-jdk13 (dep. -12-13-14 -13-14 -13)
> > cactus-jdk14 (dep. -12-13-14 -13-14 -14)
> >
> > hope this helps.
> >
> > R.
> >
> > ---------------------------------------------------------------------
> > 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: [Strategy] How to manage several subprojects as one project?
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Rafal,
Thanks for your good feedback. I have 2 comments:
1/ Performing a jar then an unjar and again a jar is time consuming.
There is really no need to do this. It is forced on us by Maven which is
not so good. It's the same situation if you're doing code generation.
ATM you have to pass the source jar to a second project that will unjar
them to generate code from the source.
Maybe a solution would be to have a new artifact type of "classes" which
would point to the top level of package directories. That was there is
no need to jar and unjar.
Or more generically an artifact type of "directory" structure where you
can put anything expanded in there (source code, class files, etc)?
2/ These share-12-13-14 and share-13-14 subprojects have no functional
meaning and I'd like to have a single javadoc report, a single site, a
single checkstyle errors, etc.
I think this point 2 is my main problem. It's fine to have several
subprojects when they have a functional meaning but I don't feel this is
the case. This problem is all the more evident in that Cactus already
has an existing build which does this and it's hard to justify to users
that we have something "less" good because of a technical problem. If we
don't have a single site, looking at reports is harder because you have
to navigate to different location to get a full vision (which is BTW the
reason for the dashboard plugin I have started).
Any other ideas?
Thanks for your help
-Vincent
> -----Original Message-----
> From: Rafal Krzewski [mailto:Rafal.Krzewski@caltha.pl]
> Sent: 26 May 2004 00:08
> To: Maven Developers List
> Subject: Re: [Strategy] How to manage several subprojects as one
project?
>
> Jason van Zyl wrote:
> > On Tue, 2004-05-25 at 12:05, Vincent Massol wrote:
> >
> >>Hi Carlos,
> >
> >
> >>I still believe we're missing a "local/private" repository kind of
stuff
> >>to share non-public data between projects. Or something equivalent.
> >
> >
> > I honestly don't understand this requirement. What is really the
> > difference between referencing the generated artifact from the local
> > repository or the target directory of the build in question. Which
you
> > can do with a JAR override:
> >
> > maven.jar.foo = ${basedir}../other-project/target/whatever.jar
>
> I think it's a bad practice. I always put this setting in my
> build.properties:
>
maven.buil.dir=/home/rafal/maven-targets/${pom.groupId}/${pom.artifactId
}
> This is to avoid swamping my eclipse workspace with thousands of
> generated files. Boosts search performance a great deal, eliminating
> false positives at the same time. This is probably useful with other
> IDEs too!
> So, I would recommend pulling the artifact from the local repo in such
> situations.
>
> > Or with the unified source directory in m2 this will also be easy.
> >
> > But what do you really see as the problem with deploying JARs to the
> > local repo for use amongst your projects?
>
> Jason is right. Everthing that shows up in your local repo during
build
> process through *:install[-snapshot] can be considered your project's
> private data. Only artifacts that you *:deploy[-snapshot] are the
public
> stuff. Excuse me if I missed something important in the earlier
> discussion, but I think you could build your private partial jars in
> separate projects, and then combine them together in other agregator
> projects. You could specify explicit dependencies among all of these,
so
> that reactor built them in the correct order. The aggregator projects
> would have to use a bit of custom jelly scripting to pull the required
> jars from the local repo, unzip them and zip the whole thing together
> again. You would probably need a custom goal for doing the deployment,
> you don't want to just run multiproject:deploy, because it would
publish
> your internal jars. You could override jar:deploy and
> jar:deploy-install goals in the partial jar projects to fail in order
to
> prevent deploying them accidentally.
> I think this strategy if pretty straightforward, follows Maven's
single
> project - single artifact philosophy, and can be easily layed out in a
> flat (no project nesting) Eclipse friendly way.
>
> cactus-parent (parent POM for all projects)
> cactus-build (multiproject driver)
> cactus-partial-12-13-14
> cactus-partial-13-14 (dep. -12-13-14)
> cactus-partial-12 (dep. -12-13-14)
> cactus-partial-13 (dep. -12-13-14 -13-14)
> cactus-partial-14 (dep. -12-13-14 -13-14)
> cactus-jdk12 (dep. -12-13-14 -12)
> cactus-jdk13 (dep. -12-13-14 -13-14 -13)
> cactus-jdk14 (dep. -12-13-14 -13-14 -14)
>
> hope this helps.
>
> R.
>
> ---------------------------------------------------------------------
> 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: [Strategy] How to manage several subprojects as one project?
Posted by Rafal Krzewski <Ra...@caltha.pl>.
Jason van Zyl wrote:
> On Tue, 2004-05-25 at 12:05, Vincent Massol wrote:
>
>>Hi Carlos,
>
>
>>I still believe we're missing a "local/private" repository kind of stuff
>>to share non-public data between projects. Or something equivalent.
>
>
> I honestly don't understand this requirement. What is really the
> difference between referencing the generated artifact from the local
> repository or the target directory of the build in question. Which you
> can do with a JAR override:
>
> maven.jar.foo = ${basedir}../other-project/target/whatever.jar
I think it's a bad practice. I always put this setting in my
build.properties:
maven.buil.dir=/home/rafal/maven-targets/${pom.groupId}/${pom.artifactId}
This is to avoid swamping my eclipse workspace with thousands of
generated files. Boosts search performance a great deal, eliminating
false positives at the same time. This is probably useful with other
IDEs too!
So, I would recommend pulling the artifact from the local repo in such
situations.
> Or with the unified source directory in m2 this will also be easy.
>
> But what do you really see as the problem with deploying JARs to the
> local repo for use amongst your projects?
Jason is right. Everthing that shows up in your local repo during build
process through *:install[-snapshot] can be considered your project's
private data. Only artifacts that you *:deploy[-snapshot] are the public
stuff. Excuse me if I missed something important in the earlier
discussion, but I think you could build your private partial jars in
separate projects, and then combine them together in other agregator
projects. You could specify explicit dependencies among all of these, so
that reactor built them in the correct order. The aggregator projects
would have to use a bit of custom jelly scripting to pull the required
jars from the local repo, unzip them and zip the whole thing together
again. You would probably need a custom goal for doing the deployment,
you don't want to just run multiproject:deploy, because it would publish
your internal jars. You could override jar:deploy and
jar:deploy-install goals in the partial jar projects to fail in order to
prevent deploying them accidentally.
I think this strategy if pretty straightforward, follows Maven's single
project - single artifact philosophy, and can be easily layed out in a
flat (no project nesting) Eclipse friendly way.
cactus-parent (parent POM for all projects)
cactus-build (multiproject driver)
cactus-partial-12-13-14
cactus-partial-13-14 (dep. -12-13-14)
cactus-partial-12 (dep. -12-13-14)
cactus-partial-13 (dep. -12-13-14 -13-14)
cactus-partial-14 (dep. -12-13-14 -13-14)
cactus-jdk12 (dep. -12-13-14 -12)
cactus-jdk13 (dep. -12-13-14 -13-14 -13)
cactus-jdk14 (dep. -12-13-14 -13-14 -14)
hope this helps.
R.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [Strategy] How to manage several subprojects as one project?
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@maven.org]
> Sent: 25 May 2004 19:38
> To: Maven Developers List
> Subject: RE: [Strategy] How to manage several subprojects as one
project?
>
> On Tue, 2004-05-25 at 12:05, Vincent Massol wrote:
> > Hi Carlos,
>
> > I still believe we're missing a "local/private" repository kind of
stuff
> > to share non-public data between projects. Or something equivalent.
>
> I honestly don't understand this requirement. What is really the
> difference between referencing the generated artifact from the local
> repository or the target directory of the build in question. Which you
> can do with a JAR override:
>
> maven.jar.foo = ${basedir}../other-project/target/whatever.jar
>
> Or with the unified source directory in m2 this will also be easy.
>
> But what do you really see as the problem with deploying JARs to the
> local repo for use amongst your projects?
There is really no real functional requirement for building a jar for
share-12-13-14 and share-13-14 as these jars do not have any meaning at
all. Creating a jar of them and then unjarring them to rejar them all
together seems like a waste of time. It doesn't seem a sound practice.
Jason, I dont know how to solve my general use case today with Maven. I
need to transform the following Ant build:
> > > > framework/
> > > > |_ src
> > > > |_ share-12-13-14
> > > > |_ share-13-14
> > > > |_ j2ee-12
> > > > |_ j2ee-13
> > > > |_ j2ee-14
> > > > |_ build.xml
> > > > |_ [...]
> > > >
> > > > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > > > respectively). The share directories contain common classes
> > > > for the different API versions. Of course the build for the
> > > > different APIs have different dependencies.
In the end depending on which J2EE API the framework/ project is built
against, it should deliver a cactus-j2ee-<api>.jar.
share-12-13-14 and share-13-14 have no functional meaning. They just
contain classes that are common.
Ideally I'd also like to have a single site for the framework/ project,
a single clover report, a single javadoc report, etc.
How would you transform that into a Maven build?
Thanks!
-Vincent
PS: Where can I find more information on the "unified source directory"?
It looks interesting.
>
> > Thanks
> > -Vincent
> >
> > > -----Original Message-----
> > > From: Carlos Sanchez [mailto:apache@carlos.cousas.net]
> > > Sent: 25 May 2004 17:35
> > > To: 'Maven Developers List'
> > > Cc: 'Vincent Massol'
> > > Subject: RE: [Strategy] How to manage several subprojects as one
> > project?
> > >
> > > Hi Vincent,
> > >
> > > IMHO points 1 and 2 seem to break Maven "philosophy". The Cactus
> > > distribution should comprise more than one jar, and that shouldn't
be
> > a
> > > problem.
> > > I thinked about using files from a dependency jar in order to
share
> > > information between different projects, for example Spring
database
> > > configuration parameters common to many webapps, it's defined in a
> > common
> > > project and extracted to target/webapp/WEB-INF before building a
war
> > > archive. This is similar to what you say, you can extract classes
from
> > a
> > > dependency jar to build/classes before calling jar goal.
> > >
> > > About point 3 I'm currently using multiproject:site but I suppose
this
> > > doesn't suit your needs.
> > >
> > >
> > > Carlos Sanchez
> > > A Coruña, Spain
> > >
> > > Oness Project
> > > http://oness.sourceforge.net
> > >
> > >
> > >
> > > > -----Mensaje original-----
> > > > De: Vincent Massol [mailto:vmassol@pivolis.com]
> > > > Enviado el: domingo, 23 de mayo de 2004 22:13
> > > > Para: 'Maven Developers List'
> > > > Asunto: [Strategy] How to manage several subprojects as one
project?
> > > >
> > > > Hi guys,
> > > >
> > > > I'm still trying to slowly convert the Cactus build (which
> > > > uses Ant) into a Maven build. Here's a use case I have.
> > > > Currently I have the
> > > > following:
> > > >
> > > > framework/
> > > > |_ src
> > > > |_ share-12-13-14
> > > > |_ share-13-14
> > > > |_ j2ee-12
> > > > |_ j2ee-13
> > > > |_ j2ee-14
> > > > |_ build.xml
> > > > |_ [...]
> > > >
> > > > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > > > respectively). The share directories contain common classes
> > > > for the different API versions. Of course the build for the
> > > > different APIs have different dependencies.
> > > >
> > > > To transform this into a Maven 1.x build, it seems that what
> > > > makes most sense is to have the following:
> > > >
> > > > framework/
> > > > |_ share-12-13-14
> > > > |_ src
> > > > |_ share-13-14
> > > > |_ src
> > > > |_ j2ee-12
> > > > |_ src
> > > > |_ j2ee-13
> > > > |_ src
> > > > |_ j2ee-14
> > > > |- src
> > > >
> > > > (i.e. a project per src directory).
> > > >
> > > > However, there are several issues:
> > > > 1- I don't want to publicly expose the share-12-13-14 jar
> > > > artifact for example. Thus it would be best to have some
> > > > interproject "channel" that do not go into the local Maven repo.
> > > > 2- I still to only deliver 3 jars (one for each API), thus I
> > > > need to regroup the different jars. For example for J2EE API
> > > > 1.3, I need to regroup the share-12-13-14 + share-13-14 +
> > > > j2ee-13 jars. I don't think that uberjar does exactly this.
> > > > Of course it should be possible to develop a plugin for this
> > > > if there is no other solution. It's a bit of a pain to have
> > > > to jar the output from subprojects to then have to unjar jar
> > > > to again rejar everything a main framework jar. It would be
> > > > nice to be able to exchange classes artifact between the
> > > > different subprojects.
> > > > 3- More generally, I'd like to consider the framework project
> > > > as one virtual project, i.e. have only a single site, single
> > > > javadoc, etc.
> > > >
> > > > In light of this, it seems to me that the only reason to have
> > > > different subprojects is to have the ability to define
> > > > different dependencies for the different J2EE APIs. Thus
> > > > maybe there is another solution using dynamic dependencies
> > > > (not sure how that would work though).
> > > >
> > > > Any take on this use case for Maven 1.x?
> > > >
> > > > Is that a known use case for m2?
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > 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
>
> --
> 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: [Strategy] How to manage several subprojects as one project?
Posted by Jason van Zyl <jv...@maven.org>.
On Tue, 2004-05-25 at 12:05, Vincent Massol wrote:
> Hi Carlos,
> I still believe we're missing a "local/private" repository kind of stuff
> to share non-public data between projects. Or something equivalent.
I honestly don't understand this requirement. What is really the
difference between referencing the generated artifact from the local
repository or the target directory of the build in question. Which you
can do with a JAR override:
maven.jar.foo = ${basedir}../other-project/target/whatever.jar
Or with the unified source directory in m2 this will also be easy.
But what do you really see as the problem with deploying JARs to the
local repo for use amongst your projects?
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Carlos Sanchez [mailto:apache@carlos.cousas.net]
> > Sent: 25 May 2004 17:35
> > To: 'Maven Developers List'
> > Cc: 'Vincent Massol'
> > Subject: RE: [Strategy] How to manage several subprojects as one
> project?
> >
> > Hi Vincent,
> >
> > IMHO points 1 and 2 seem to break Maven "philosophy". The Cactus
> > distribution should comprise more than one jar, and that shouldn't be
> a
> > problem.
> > I thinked about using files from a dependency jar in order to share
> > information between different projects, for example Spring database
> > configuration parameters common to many webapps, it's defined in a
> common
> > project and extracted to target/webapp/WEB-INF before building a war
> > archive. This is similar to what you say, you can extract classes from
> a
> > dependency jar to build/classes before calling jar goal.
> >
> > About point 3 I'm currently using multiproject:site but I suppose this
> > doesn't suit your needs.
> >
> >
> > Carlos Sanchez
> > A Coruña, Spain
> >
> > Oness Project
> > http://oness.sourceforge.net
> >
> >
> >
> > > -----Mensaje original-----
> > > De: Vincent Massol [mailto:vmassol@pivolis.com]
> > > Enviado el: domingo, 23 de mayo de 2004 22:13
> > > Para: 'Maven Developers List'
> > > Asunto: [Strategy] How to manage several subprojects as one project?
> > >
> > > Hi guys,
> > >
> > > I'm still trying to slowly convert the Cactus build (which
> > > uses Ant) into a Maven build. Here's a use case I have.
> > > Currently I have the
> > > following:
> > >
> > > framework/
> > > |_ src
> > > |_ share-12-13-14
> > > |_ share-13-14
> > > |_ j2ee-12
> > > |_ j2ee-13
> > > |_ j2ee-14
> > > |_ build.xml
> > > |_ [...]
> > >
> > > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > > respectively). The share directories contain common classes
> > > for the different API versions. Of course the build for the
> > > different APIs have different dependencies.
> > >
> > > To transform this into a Maven 1.x build, it seems that what
> > > makes most sense is to have the following:
> > >
> > > framework/
> > > |_ share-12-13-14
> > > |_ src
> > > |_ share-13-14
> > > |_ src
> > > |_ j2ee-12
> > > |_ src
> > > |_ j2ee-13
> > > |_ src
> > > |_ j2ee-14
> > > |- src
> > >
> > > (i.e. a project per src directory).
> > >
> > > However, there are several issues:
> > > 1- I don't want to publicly expose the share-12-13-14 jar
> > > artifact for example. Thus it would be best to have some
> > > interproject "channel" that do not go into the local Maven repo.
> > > 2- I still to only deliver 3 jars (one for each API), thus I
> > > need to regroup the different jars. For example for J2EE API
> > > 1.3, I need to regroup the share-12-13-14 + share-13-14 +
> > > j2ee-13 jars. I don't think that uberjar does exactly this.
> > > Of course it should be possible to develop a plugin for this
> > > if there is no other solution. It's a bit of a pain to have
> > > to jar the output from subprojects to then have to unjar jar
> > > to again rejar everything a main framework jar. It would be
> > > nice to be able to exchange classes artifact between the
> > > different subprojects.
> > > 3- More generally, I'd like to consider the framework project
> > > as one virtual project, i.e. have only a single site, single
> > > javadoc, etc.
> > >
> > > In light of this, it seems to me that the only reason to have
> > > different subprojects is to have the ability to define
> > > different dependencies for the different J2EE APIs. Thus
> > > maybe there is another solution using dynamic dependencies
> > > (not sure how that would work though).
> > >
> > > Any take on this use case for Maven 1.x?
> > >
> > > Is that a known use case for m2?
> > >
> > > Thanks
> > > -Vincent
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > 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
--
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: [Strategy] How to manage several subprojects as one project?
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Carlos,
The requirement to have a single Cactus framework jar is a *MUST* have
(like a business requirement). It doesn't make sense to deliver 3 jars:
cactus-share-12-13-14.jar, cactus-share-13-14, cactus-j2ee-<api
version>.jar. These jars have no functional meaning at all. That
wouldn't do for users.
I still believe we're missing a "local/private" repository kind of stuff
to share non-public data between projects. Or something equivalent.
Thanks
-Vincent
> -----Original Message-----
> From: Carlos Sanchez [mailto:apache@carlos.cousas.net]
> Sent: 25 May 2004 17:35
> To: 'Maven Developers List'
> Cc: 'Vincent Massol'
> Subject: RE: [Strategy] How to manage several subprojects as one
project?
>
> Hi Vincent,
>
> IMHO points 1 and 2 seem to break Maven "philosophy". The Cactus
> distribution should comprise more than one jar, and that shouldn't be
a
> problem.
> I thinked about using files from a dependency jar in order to share
> information between different projects, for example Spring database
> configuration parameters common to many webapps, it's defined in a
common
> project and extracted to target/webapp/WEB-INF before building a war
> archive. This is similar to what you say, you can extract classes from
a
> dependency jar to build/classes before calling jar goal.
>
> About point 3 I'm currently using multiproject:site but I suppose this
> doesn't suit your needs.
>
>
> Carlos Sanchez
> A Coruña, Spain
>
> Oness Project
> http://oness.sourceforge.net
>
>
>
> > -----Mensaje original-----
> > De: Vincent Massol [mailto:vmassol@pivolis.com]
> > Enviado el: domingo, 23 de mayo de 2004 22:13
> > Para: 'Maven Developers List'
> > Asunto: [Strategy] How to manage several subprojects as one project?
> >
> > Hi guys,
> >
> > I'm still trying to slowly convert the Cactus build (which
> > uses Ant) into a Maven build. Here's a use case I have.
> > Currently I have the
> > following:
> >
> > framework/
> > |_ src
> > |_ share-12-13-14
> > |_ share-13-14
> > |_ j2ee-12
> > |_ j2ee-13
> > |_ j2ee-14
> > |_ build.xml
> > |_ [...]
> >
> > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> > respectively). The share directories contain common classes
> > for the different API versions. Of course the build for the
> > different APIs have different dependencies.
> >
> > To transform this into a Maven 1.x build, it seems that what
> > makes most sense is to have the following:
> >
> > framework/
> > |_ share-12-13-14
> > |_ src
> > |_ share-13-14
> > |_ src
> > |_ j2ee-12
> > |_ src
> > |_ j2ee-13
> > |_ src
> > |_ j2ee-14
> > |- src
> >
> > (i.e. a project per src directory).
> >
> > However, there are several issues:
> > 1- I don't want to publicly expose the share-12-13-14 jar
> > artifact for example. Thus it would be best to have some
> > interproject "channel" that do not go into the local Maven repo.
> > 2- I still to only deliver 3 jars (one for each API), thus I
> > need to regroup the different jars. For example for J2EE API
> > 1.3, I need to regroup the share-12-13-14 + share-13-14 +
> > j2ee-13 jars. I don't think that uberjar does exactly this.
> > Of course it should be possible to develop a plugin for this
> > if there is no other solution. It's a bit of a pain to have
> > to jar the output from subprojects to then have to unjar jar
> > to again rejar everything a main framework jar. It would be
> > nice to be able to exchange classes artifact between the
> > different subprojects.
> > 3- More generally, I'd like to consider the framework project
> > as one virtual project, i.e. have only a single site, single
> > javadoc, etc.
> >
> > In light of this, it seems to me that the only reason to have
> > different subprojects is to have the ability to define
> > different dependencies for the different J2EE APIs. Thus
> > maybe there is another solution using dynamic dependencies
> > (not sure how that would work though).
> >
> > Any take on this use case for Maven 1.x?
> >
> > Is that a known use case for m2?
> >
> > Thanks
> > -Vincent
> >
> >
> >
> >
---------------------------------------------------------------------
> > 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: [Strategy] How to manage several subprojects as one project?
Posted by Carlos Sanchez <ap...@carlos.cousas.net>.
Hi Vincent,
IMHO points 1 and 2 seem to break Maven "philosophy". The Cactus
distribution should comprise more than one jar, and that shouldn't be a
problem.
I thinked about using files from a dependency jar in order to share
information between different projects, for example Spring database
configuration parameters common to many webapps, it's defined in a common
project and extracted to target/webapp/WEB-INF before building a war
archive. This is similar to what you say, you can extract classes from a
dependency jar to build/classes before calling jar goal.
About point 3 I'm currently using multiproject:site but I suppose this
doesn't suit your needs.
Carlos Sanchez
A Coruña, Spain
Oness Project
http://oness.sourceforge.net
> -----Mensaje original-----
> De: Vincent Massol [mailto:vmassol@pivolis.com]
> Enviado el: domingo, 23 de mayo de 2004 22:13
> Para: 'Maven Developers List'
> Asunto: [Strategy] How to manage several subprojects as one project?
>
> Hi guys,
>
> I'm still trying to slowly convert the Cactus build (which
> uses Ant) into a Maven build. Here's a use case I have.
> Currently I have the
> following:
>
> framework/
> |_ src
> |_ share-12-13-14
> |_ share-13-14
> |_ j2ee-12
> |_ j2ee-13
> |_ j2ee-14
> |_ build.xml
> |_ [...]
>
> Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4
> respectively). The share directories contain common classes
> for the different API versions. Of course the build for the
> different APIs have different dependencies.
>
> To transform this into a Maven 1.x build, it seems that what
> makes most sense is to have the following:
>
> framework/
> |_ share-12-13-14
> |_ src
> |_ share-13-14
> |_ src
> |_ j2ee-12
> |_ src
> |_ j2ee-13
> |_ src
> |_ j2ee-14
> |- src
>
> (i.e. a project per src directory).
>
> However, there are several issues:
> 1- I don't want to publicly expose the share-12-13-14 jar
> artifact for example. Thus it would be best to have some
> interproject "channel" that do not go into the local Maven repo.
> 2- I still to only deliver 3 jars (one for each API), thus I
> need to regroup the different jars. For example for J2EE API
> 1.3, I need to regroup the share-12-13-14 + share-13-14 +
> j2ee-13 jars. I don't think that uberjar does exactly this.
> Of course it should be possible to develop a plugin for this
> if there is no other solution. It's a bit of a pain to have
> to jar the output from subprojects to then have to unjar jar
> to again rejar everything a main framework jar. It would be
> nice to be able to exchange classes artifact between the
> different subprojects.
> 3- More generally, I'd like to consider the framework project
> as one virtual project, i.e. have only a single site, single
> javadoc, etc.
>
> In light of this, it seems to me that the only reason to have
> different subprojects is to have the ability to define
> different dependencies for the different J2EE APIs. Thus
> maybe there is another solution using dynamic dependencies
> (not sure how that would work though).
>
> Any take on this use case for Maven 1.x?
>
> Is that a known use case for m2?
>
> Thanks
> -Vincent
>
>
>
> ---------------------------------------------------------------------
> 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