You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Scott Stirling <sc...@rcn.com> on 2003/06/02 10:17:39 UTC
multiple sourceDirectory elements in a build
Hi,
Just joined the mailing list after a quick search on the archives turned up
nothing on this.
I would like to be able to have either multiple <sourceDirectory> elements
per <build>, or multiple <build> elements per project (ideally, both), which
should generate multiple <javac> targets in the output build file if I do
"maven ant" and should output multiple <classpathentry kind="src"
path="src/codebaseN"> if I do "maven eclipse."
More to the point, what's the Maven way to do a compile of two codebases in
the same project, where all the dependencies are the same (for the sake of
argument), but classes and testcases are separated by codebase? We rely on
codebases for JAAS testing purposes and IDE test running, where we want to
compile two source codebases in one ClearCase component (a mini-project) to
two different classfile codebases, such as system and user (which also
become separately named jar files). I'm getting the intuition that Maven
would like this to be two separate projects because they are separate
codebases.
Any thoughts?
Thank you,
Scott Stirling
Framingham, MA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple sourceDirectory elements & local jar dependencies
Posted by Brian Ewins <Br...@btinternet.com>.
There should be a serious health warning on this stuff. A bunch of the
plugins iterate over dependencies, not artifacts. This means they don't
"know" the path to the dependency, and guess at
${maven.repo.local}/blah/blah. Jar overrides won't work for plugins that
have done this.
$ find . -name '*.jelly' | xargs grep -l maven.repo.local
./ant/plugin.jelly
./deploy/plugin.jelly
./ear/plugin.jelly
./eclipse/plugin.jelly
./ejb/plugin.jelly
./idea/plugin.jelly
./jar/plugin.jelly
./jbuilder/plugin.jelly
./jdee/plugin.jelly
./jnlp/plugin.jelly
./native/plugin.jelly
./plexus/plugin.jelly
./plugin/plugin.jelly
./pom/plugin.jelly
./runner/plugin.jelly
./uberjar/plugin.jelly
./war/plugin.jelly
Some of the plugins listed above are ok, eg 'jar' uses maven.repo.local
in its 'install' target in a legal way, but this will bite you
eventually if you use jar overrides. I can't think of an example above
where the iteration over artifacts is necessary, its something that
should be fixed...
-Baz
Joe Germuska wrote:
> You can override the location of dependency jars (or just the version)
> using properties -- see
> http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Dependencies
>
>
> A local repository which supplements iBiblio is indeed a cool idea, as
> it lets you solve the problem you just pointed out more easily than
> setting maven properties, and it gives you a place to store locally
> developed JARs for other projects and to store JARs that can't be on
> iBiblio (like everything you use from Sun). Plus you don't have to wait
> for iBiblio to get updated.
>
> Joe
>
>
>> Another question: if you have a dependency on a jar that doesn't have
>> a neat
>> external place to get it, and you want to pick up that jar from the local
>> file system, what do you do? I manually created the necessary directory
>> structure under maven-1.0-beta-9\repository to make like it had been
>> downloaded. Is there another way? I think it would be cool to just say:
>>
>> <dependency>
>> <id>myjar</id>
>> <uri>./lib</uri>
>> </dependency>
>>
>> Where it defaults to looking in ./lib for myjar.jar (no version, but
>> version
>> could be optionally specified), or the URI could specify the protocol
>> like
>> file:./lib, or be a variable like ${maven.repo.local}. Or again, an
>> optional attribute on the dependency, like <dependency
>> repository="local"/>.
>>
>> Current common solution (in mail archives) is to set maven.repo.remote
>> to a
>> local repository (either local file system or an internal server).
>> This is
>> also a cool idea. A local repository (supplemental to ibiblio) on our
>> own
>> server seems like a cool idea.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multiple sourceDirectory elements & local jar dependencies
Posted by Brian Ewins <Br...@btinternet.com>.
You can do a similar trick using file shares and listing *every* users
repo in your build.properties as a remote repo, or using a repo webapp
like the one I posted a while back. There is no need to copy to a
central server.
Later this week (hopefully) I plan to do a UI-less plugin version of my
repo webapp that uses Rendezvous[1] to discover repository peers, making
this kind of thing a snap; you'll just type eg
maven rendezvous
and it will lauch jetty + a repo webapp and advertise itself on your
LAN. You add that one repo into your build.properties, and it will make
appropriate download requests to all of your peers. This way, as soon
as one person in your group downloads or builds a jar, you all see it.
Very cool.
- Baz
[1] http://www.strangeberry.com/java_rendevous.htm . Anyone know an
ASL/BSD rendezvous implementation? This is LGPL so can't join the maven
core.
Eelco Hillenius wrote:
> Why not just set up a local webserver? That's what we do; works great.
> Another reason for doing this as that you can use Maven for combining your
> internal projects as well.
>
> Here's how we do it:
>
> Every developper has build.properties in his {user-home}. In this file:
>
> maven.repo.remote = http://your-webserver-address
>
> your can use all the repos you want using a comma seperated list.
>
> To make our lives easier for now (we haven't set up a ssh server yet), we
> also wrote two custom targets like this:
>
> <project
> xmlns:j="jelly:core"
> xmlns:ant="jelly:ant"
> xmlns:license="license"
> xmlns:maven="jelly:maven"
> xmlns:deploy="deploy"
> xmlns:resources="resources"
> xmlns:util="jelly:util"
> xmlns:doc="doc"
> xmlns:m="maven">
>
> <goal name="jar:fsdeploy" prereqs="jar:jar"
> description="Install the jar in the local repository">
>
> <ant:property name="maven.jar.to.deploy"
> value="${maven.final.name}.jar"/>
>
> <ant:property name="jardir__"
> value="${maven.repo.central.fileserver}/${pom.artifactDirectory}/jars"/>
> <ant:mkdir dir="${jardir__}"/>
> <ant:echo>copy ${maven.jar.to.deploy} to ${jardir__}</ant:echo>
> <ant:copy
> file="${maven.build.dir}/${maven.jar.to.deploy}"
> todir="${jardir__}"
> overwrite="true"
> />
> </goal>
>
> <goal name="jar:fsdeploy-snapshot"
> description="Install the snapshot jar in the local repository">
>
> <maven:snapshot project="${pom}"/>
> <j:set var="maven.final.name" value="${snapshotSignature}"/>
> <j:set var="maven.jar.to.deploy" value="${maven.final.name}.jar"/>
> <ant:echo>Building snapshot JAR: ${maven.final.name}</ant:echo>
> <attainGoal name="jar:jar"/>
>
> <ant:property name="jardir__"
> value="${maven.repo.central.fileserver}/${pom.artifactDirectory}/jars"/>
> <ant:mkdir dir="${jardir__}"/>
> <ant:echo>copy ${maven.jar.to.deploy} as ${pom.artifactId}-SNAPSHOT.jar
> to ${jardir__}</ant:echo>
> <ant:copy
> file="${maven.build.dir}/${maven.jar.to.deploy}"
> tofile="${jardir__}/${pom.artifactId}-SNAPSHOT.jar"
> overwrite="true"
> />
> </goal>
>
> </project>
>
> using (in build.properties):
>
> maven.repo.central.fileserver = E:/
>
> where E:/ is a local share to the webserver dir.
>
> I know it's better to use ssh, but this works today, where setting up ssh
> (on Win) is a bit of a pain right now.
>
>
> Hope this helps,
>
> Eelco
>
>
>
>>-----Original Message-----
>>From: Joe Germuska [mailto:Joe@Germuska.com]
>>Sent: maandag 2 juni 2003 16:16
>>To: Maven Users List
>>Subject: RE: multiple sourceDirectory elements & local jar dependencies
>>
>>
>>You can override the location of dependency jars (or just the
>>version) using properties -- see
>>http://maven.apache.org/reference/user-guide.html#Overriding%20Sta
>>ted%20Dependencies
>>
>>A local repository which supplements iBiblio is indeed a cool idea,
>>as it lets you solve the problem you just pointed out more easily
>>than setting maven properties, and it gives you a place to store
>>locally developed JARs for other projects and to store JARs that
>>can't be on iBiblio (like everything you use from Sun). Plus you
>>don't have to wait for iBiblio to get updated.
>>
>>Joe
>>
>>
>>
>>>Another question: if you have a dependency on a jar that doesn't
>>
>>have a neat
>>
>>>external place to get it, and you want to pick up that jar from the local
>>>file system, what do you do? I manually created the necessary directory
>>>structure under maven-1.0-beta-9\repository to make like it had been
>>>downloaded. Is there another way? I think it would be cool to just say:
>>>
>>><dependency>
>>> <id>myjar</id>
>>> <uri>./lib</uri>
>>></dependency>
>>>
>>>Where it defaults to looking in ./lib for myjar.jar (no version,
>>
>>but version
>>
>>>could be optionally specified), or the URI could specify the
>>
>>protocol like
>>
>>>file:./lib, or be a variable like ${maven.repo.local}. Or again, an
>>>optional attribute on the dependency, like <dependency
>>
>>repository="local"/>.
>>
>>>Current common solution (in mail archives) is to set
>>
>>maven.repo.remote to a
>>
>>>local repository (either local file system or an internal
>>
>>server). This is
>>
>>>also a cool idea. A local repository (supplemental to ibiblio)
>>
>>on our own
>>
>>>server seems like a cool idea.
>>
>>
>>--
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"If nature worked that way, the universe would crash all the time."
>> --Jaron Lanier
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements & local jar dependencies
Posted by di...@multitask.com.au.
Patches and bug reports are always welcome. Otherwise it gets hard to work
out what users really want....
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
"Mark H. Wilkinson" <mh...@kremvax.net> wrote on 03/06/2003
01:31:11 AM:
> On Mon, 2003-06-02 at 15:46, Eelco Hillenius wrote:
> >
> > To make our lives easier for now (we haven't set up a ssh server yet),
we
> > also wrote two custom targets like this:
> >
> > [snip]
>
> > using (in build.properties):
> >
> > maven.repo.central.fileserver = E:/
> >
> > where E:/ is a local share to the webserver dir.
>
> I was going to tell you that maven can already do that, but having just
> investigated it'd implemented only for the site plugin. You can set
> maven.site.deploy.method=fs and it'll copy files into the location
> specified by the <siteDirectory> element.
>
> Shame it hasn't been generalised into the deploy plugin...
>
> -Mark.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements & local jar dependencies
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Mon, 2003-06-02 at 15:46, Eelco Hillenius wrote:
>
> To make our lives easier for now (we haven't set up a ssh server yet), we
> also wrote two custom targets like this:
>
> [snip]
> using (in build.properties):
>
> maven.repo.central.fileserver = E:/
>
> where E:/ is a local share to the webserver dir.
I was going to tell you that maven can already do that, but having just
investigated it'd implemented only for the site plugin. You can set
maven.site.deploy.method=fs and it'll copy files into the location
specified by the <siteDirectory> element.
Shame it hasn't been generalised into the deploy plugin...
-Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements & local jar dependencies
Posted by Eelco Hillenius <ee...@topicus.nl>.
Why not just set up a local webserver? That's what we do; works great.
Another reason for doing this as that you can use Maven for combining your
internal projects as well.
Here's how we do it:
Every developper has build.properties in his {user-home}. In this file:
maven.repo.remote = http://your-webserver-address
your can use all the repos you want using a comma seperated list.
To make our lives easier for now (we haven't set up a ssh server yet), we
also wrote two custom targets like this:
<project
xmlns:j="jelly:core"
xmlns:ant="jelly:ant"
xmlns:license="license"
xmlns:maven="jelly:maven"
xmlns:deploy="deploy"
xmlns:resources="resources"
xmlns:util="jelly:util"
xmlns:doc="doc"
xmlns:m="maven">
<goal name="jar:fsdeploy" prereqs="jar:jar"
description="Install the jar in the local repository">
<ant:property name="maven.jar.to.deploy"
value="${maven.final.name}.jar"/>
<ant:property name="jardir__"
value="${maven.repo.central.fileserver}/${pom.artifactDirectory}/jars"/>
<ant:mkdir dir="${jardir__}"/>
<ant:echo>copy ${maven.jar.to.deploy} to ${jardir__}</ant:echo>
<ant:copy
file="${maven.build.dir}/${maven.jar.to.deploy}"
todir="${jardir__}"
overwrite="true"
/>
</goal>
<goal name="jar:fsdeploy-snapshot"
description="Install the snapshot jar in the local repository">
<maven:snapshot project="${pom}"/>
<j:set var="maven.final.name" value="${snapshotSignature}"/>
<j:set var="maven.jar.to.deploy" value="${maven.final.name}.jar"/>
<ant:echo>Building snapshot JAR: ${maven.final.name}</ant:echo>
<attainGoal name="jar:jar"/>
<ant:property name="jardir__"
value="${maven.repo.central.fileserver}/${pom.artifactDirectory}/jars"/>
<ant:mkdir dir="${jardir__}"/>
<ant:echo>copy ${maven.jar.to.deploy} as ${pom.artifactId}-SNAPSHOT.jar
to ${jardir__}</ant:echo>
<ant:copy
file="${maven.build.dir}/${maven.jar.to.deploy}"
tofile="${jardir__}/${pom.artifactId}-SNAPSHOT.jar"
overwrite="true"
/>
</goal>
</project>
using (in build.properties):
maven.repo.central.fileserver = E:/
where E:/ is a local share to the webserver dir.
I know it's better to use ssh, but this works today, where setting up ssh
(on Win) is a bit of a pain right now.
Hope this helps,
Eelco
> -----Original Message-----
> From: Joe Germuska [mailto:Joe@Germuska.com]
> Sent: maandag 2 juni 2003 16:16
> To: Maven Users List
> Subject: RE: multiple sourceDirectory elements & local jar dependencies
>
>
> You can override the location of dependency jars (or just the
> version) using properties -- see
> http://maven.apache.org/reference/user-guide.html#Overriding%20Sta
> ted%20Dependencies
>
> A local repository which supplements iBiblio is indeed a cool idea,
> as it lets you solve the problem you just pointed out more easily
> than setting maven properties, and it gives you a place to store
> locally developed JARs for other projects and to store JARs that
> can't be on iBiblio (like everything you use from Sun). Plus you
> don't have to wait for iBiblio to get updated.
>
> Joe
>
>
> >Another question: if you have a dependency on a jar that doesn't
> have a neat
> >external place to get it, and you want to pick up that jar from the local
> >file system, what do you do? I manually created the necessary directory
> >structure under maven-1.0-beta-9\repository to make like it had been
> >downloaded. Is there another way? I think it would be cool to just say:
> >
> ><dependency>
> > <id>myjar</id>
> > <uri>./lib</uri>
> ></dependency>
> >
> >Where it defaults to looking in ./lib for myjar.jar (no version,
> but version
> >could be optionally specified), or the URI could specify the
> protocol like
> >file:./lib, or be a variable like ${maven.repo.local}. Or again, an
> >optional attribute on the dependency, like <dependency
> repository="local"/>.
> >
> >Current common solution (in mail archives) is to set
> maven.repo.remote to a
> >local repository (either local file system or an internal
> server). This is
> >also a cool idea. A local repository (supplemental to ibiblio)
> on our own
> >server seems like a cool idea.
>
>
> --
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "If nature worked that way, the universe would crash all the time."
> --Jaron Lanier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements & local jar dependencies
Posted by Joe Germuska <Jo...@Germuska.com>.
You can override the location of dependency jars (or just the
version) using properties -- see
http://maven.apache.org/reference/user-guide.html#Overriding%20Stated%20Dependencies
A local repository which supplements iBiblio is indeed a cool idea,
as it lets you solve the problem you just pointed out more easily
than setting maven properties, and it gives you a place to store
locally developed JARs for other projects and to store JARs that
can't be on iBiblio (like everything you use from Sun). Plus you
don't have to wait for iBiblio to get updated.
Joe
>Another question: if you have a dependency on a jar that doesn't have a neat
>external place to get it, and you want to pick up that jar from the local
>file system, what do you do? I manually created the necessary directory
>structure under maven-1.0-beta-9\repository to make like it had been
>downloaded. Is there another way? I think it would be cool to just say:
>
><dependency>
> <id>myjar</id>
> <uri>./lib</uri>
></dependency>
>
>Where it defaults to looking in ./lib for myjar.jar (no version, but version
>could be optionally specified), or the URI could specify the protocol like
>file:./lib, or be a variable like ${maven.repo.local}. Or again, an
>optional attribute on the dependency, like <dependency repository="local"/>.
>
>Current common solution (in mail archives) is to set maven.repo.remote to a
>local repository (either local file system or an internal server). This is
>also a cool idea. A local repository (supplemental to ibiblio) on our own
>server seems like a cool idea.
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements & local jar dependencies
Posted by Vincent Massol <vm...@pivolis.com>.
> -----Original Message-----
> From: Scott Stirling [mailto:scottstirling@rcn.com]
> Sent: 02 June 2003 11:13
> To: 'Maven Users List'
> Subject: RE: multiple sourceDirectory elements & local jar
dependencies
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@pivolis.com]
> [...]
>
> Hi Vince,
>
> Thanks for the reply!
>
> > The Maven philosophy is to have a single source tree per project. If
you
> > need several then simply split into several projects. Creating a
project
> > in Maven simply consists in creating a project.xml file.
>
> There's no escaping that Maven enforces its philosophy on my team's
> project
> unnecessarily (it seems to me).
>
> It's nice that project's can inherit, which should ameliorate the
change
> in
> perspective for the team as to what constitutes a "project." We
already
> have at least 3 different uses of "project" in our current tool set of
> Eclipse, ClearCase and management's use(s) (along which we have
organized
> code in ClearCase UCM). It may not be that big of a deal, although we
> don't
> want too many Eclipse projects, and this is going to encourage two
> everywhere we had one before.
You only need several Eclipse project if you wish to use the
Eclipse/Maven plugin. Otherwise you can still have a single Eclipse
project (not a big deal - That's what I do).
>
> Another question: if you have a dependency on a jar that doesn't have
a
> neat
> external place to get it, and you want to pick up that jar from the
local
> file system, what do you do? I manually created the necessary
directory
> structure under maven-1.0-beta-9\repository to make like it had been
> downloaded. Is there another way? I think it would be cool to just
say:
>
> <dependency>
> <id>myjar</id>
> <uri>./lib</uri>
> </dependency>
>
> Where it defaults to looking in ./lib for myjar.jar (no version, but
> version
> could be optionally specified), or the URI could specify the protocol
like
> file:./lib, or be a variable like ${maven.repo.local}. Or again, an
> optional attribute on the dependency, like <dependency
> repository="local"/>.
It's possible with the <jar> tag (replace <uri> by <jar> :-)). However,
the correct solution is that any project artfifact (jars are a project
artifact) go through the maven repository.
Thus, for example, a "maven jar:deploy" will deploy the jar to the local
repository, making it accessible to any other project.
This is a different philosophy from "traditional" ant scripts which were
sharing artifacts through a dist/, target/ or release/ directory. The
Maven approach is much cleaner IMO.
>
> Current common solution (in mail archives) is to set maven.repo.remote
to
> a
> local repository (either local file system or an internal server).
This
> is
> also a cool idea. A local repository (supplemental to ibiblio) on our
own
> server seems like a cool idea.
Yep, it works real well here (we have 300+ maven projects). We have an
automated build which runs on the maven remote repository machine and
publishes the artifacts after each build, making them available to the
whole team.
>
> Anyway, Maven is really cool, as I am getting sick of writing the same
> build
> files again and again. I hope I can convince some other folks on the
team
> to buy into it.
Excellent! Once you start understanding and using it, there's not
running back :-)
-Vincent
>
> Thank you,
>
> Scott Stirling
> Framingham, MA
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements & local jar dependencies
Posted by Scott Stirling <sc...@rcn.com>.
> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com]
[...]
Hi Vince,
Thanks for the reply!
> The Maven philosophy is to have a single source tree per project. If you
> need several then simply split into several projects. Creating a project
> in Maven simply consists in creating a project.xml file.
There's no escaping that Maven enforces its philosophy on my team's project
unnecessarily (it seems to me).
It's nice that project's can inherit, which should ameliorate the change in
perspective for the team as to what constitutes a "project." We already
have at least 3 different uses of "project" in our current tool set of
Eclipse, ClearCase and management's use(s) (along which we have organized
code in ClearCase UCM). It may not be that big of a deal, although we don't
want too many Eclipse projects, and this is going to encourage two
everywhere we had one before.
Another question: if you have a dependency on a jar that doesn't have a neat
external place to get it, and you want to pick up that jar from the local
file system, what do you do? I manually created the necessary directory
structure under maven-1.0-beta-9\repository to make like it had been
downloaded. Is there another way? I think it would be cool to just say:
<dependency>
<id>myjar</id>
<uri>./lib</uri>
</dependency>
Where it defaults to looking in ./lib for myjar.jar (no version, but version
could be optionally specified), or the URI could specify the protocol like
file:./lib, or be a variable like ${maven.repo.local}. Or again, an
optional attribute on the dependency, like <dependency repository="local"/>.
Current common solution (in mail archives) is to set maven.repo.remote to a
local repository (either local file system or an internal server). This is
also a cool idea. A local repository (supplemental to ibiblio) on our own
server seems like a cool idea.
Anyway, Maven is really cool, as I am getting sick of writing the same build
files again and again. I hope I can convince some other folks on the team
to buy into it.
Thank you,
Scott Stirling
Framingham, MA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: multiple sourceDirectory elements in a build
Posted by Vincent Massol <vm...@pivolis.com>.
Hi Scott,
> -----Original Message-----
> From: Scott Stirling [mailto:scottstirling@rcn.com]
> Sent: 02 June 2003 10:18
> To: users@maven.apache.org
> Subject: multiple sourceDirectory elements in a build
>
> Hi,
>
> Just joined the mailing list after a quick search on the archives
turned
> up
> nothing on this.
Humm.. strange as this is a hot FAQ! :-)
(BTW, I've just noticed we don't a FAQ entry for this... hum...)
>
> I would like to be able to have either multiple <sourceDirectory>
elements
> per <build>, or multiple <build> elements per project (ideally, both),
> which
> should generate multiple <javac> targets in the output build file if I
do
> "maven ant"
The Maven philosophy is to have a single source tree per project. If you
need several then simply split into several projects. Creating a project
in Maven simply consists in creating a project.xml file.
Myoverallproject
|_ project1
|_ src/java
|_ project.xml (can inherit from ../project.xml)
|_ project2
|_ src/java
|_ project.xml (can inherit from ../project.xml)
|_ project.xml
|_ maven.xml
The maven.xml file can use the <reactor> tag to automatically build
project1 and project2.
> and should output multiple <classpathentry kind="src"
> path="src/codebaseN"> if I do "maven eclipse."
>
> More to the point, what's the Maven way to do a compile of two
codebases
> in
> the same project, where all the dependencies are the same (for the
sake of
> argument), but classes and testcases are separated by codebase? We
rely on
> codebases for JAAS testing purposes and IDE test running, where we
want to
> compile two source codebases in one ClearCase component (a
mini-project)
> to
> two different classfile codebases, such as system and user (which also
> become separately named jar files). I'm getting the intuition that
Maven
> would like this to be two separate projects because they are separate
> codebases.
Yep. See above.
-Vincent
>
> Any thoughts?
>
> Thank you,
>
> Scott Stirling
> Framingham, MA
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org