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:[EMAIL PROTECTED]
> > 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:[EMAIL PROTECTED]
> > > 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: [EMAIL PROTECTED] For
> > > additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
