If I can add me 2 cents:
I agree with Jason - the multiple location of the sources are evil...but
I also agree with Colin that if you want or not they are already present in
Maven.
I think that maybe better assumption which is closer to current reality
will be to have just one source location per type (java, test, aspect,
iutest) etc.
but make this process more plugable and easier then it is now, so new types
can be added more easily.
Why do we need things like:
<sourceDirectory>src/java</sourceDirectory>
<unitTestSourceDirectory>src/test/java</unitTestSourceDirectory>
and then two separate ways of processing resources for "java" sources
and for "test" resources
won't it be simple just to have:
<source>
<type>java</type>
<path>src/java</path>
</source>
<source>
<type>cactus</type>
<path>src/cactus</path>
</source>
<source>
<type>test</type>
<path>src/test/java</path>
<includes>
<include>**/*Test.java</include>
</includes>
<excludes>
<exclude>**/RepositoryTest.java</exclude>
<exclude>**/JAXPTest.java</exclude>
</excludes>
</source>
<source>
<type>aspect</type>
<path>src/ascpects</path>
</source>
<source>
<type>native</type>
<path>cpp</path>
</source>
and then
<resources>
<resource>
<type>java<type>
.....
</resource>
<resource>
<type>test<type>
.....
</resource>
...
<resources>
And still Maven can refuse to work when there are two <source> entries for
the same
type. Even it then display ERROR MESSAGE:
"WE MADE CHOICE FOR YOU - TWO SOURCE LOCATIONS OF THE SAME TYPE ARE STRICTLY
FORBIDEN (tm)"
I see some obvious profits of such representation as I presented above:
For (stupid) example we can have:
<source>
<type>xml</type>
<path>src/xml</path>
</source>
and there can be maven plugin which will pretty print and validate XML,
exactly in the same way Jalopy is able to format java sources.
or
<source>
<type>jelly</type>
<path>src/jelly</path>
</source>
and there can be check if jelly scripts are gramaticaly correct etc..
I believe that this structure is cleaner and more open then current POM's
XML structure.
Michal
> -----Original Message-----
> From: Ben Walding [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 02, 2003 6:23 AM
> To: Maven Users List
> Subject: Re: Why no multiple locations of sources? ( was Re:
> inter-project dependencies for the Eclipse plugin )
>
>
> Maybe if we understood the "why" of multiple trees, we would be better
> able to describe the "why not" and the "how to work without them"
>
> So to Colin (I think)
>
> Why do you have multiple source trees?
> What is in them?
> Do they build distinct artifacts?
> Would other disparate projects have a requirement to also split code up
> the way you have (which explains unit test / aspect etc)
>
> The fact that your project may be legacy and you just want to shoe-horn
> it into Maven quickly is a legitimate requirement, however there are a
> bazillion ways to skin that cat and maybe you're approaching it from the
> wrong angle?
>
>
> Jeffrey D. Brekke wrote:
>
> >>>>>>On Tue, 01 Apr 2003 13:20:56 -0500, Colin Sampaleanu
> <[EMAIL PROTECTED]> said:
> >>>>>>
> >>>>>>
> >
> >
> >
> >>Jason van Zyl wrote:
> >>
> >>
> >{SNIP]
> >
> >
> >
> >>>Far from arbitrary. People can use the addPath tag to work around
> >>>it and to migrate projects but I certainly don't recommend it
> >>>ever. At least in the POM more than one source directory will never
> >>>be supported.
> >>>
> >>>
> >>>
> >>I don't understand how you can say Maven doesn't support multiple
> >>source directories, what about sourceDirectory,
> >>unitTestSourceDirectory, integrationUnitTestSourceDirectory,
> >>aspectSourceDirectory? These are all different source directories
> >>that are handled by various parts of Maven. To draw the line there
> >>seems awfully presumptious. With all due respect to your opinion
> >>(that this handles most cases and results in good practices, which I
> >>agree), I've been around the block enough to know that I don't know
> >>everything. If somebody/an organization has a need to add another
> >>source dir that is on an equal basis to the ones above (to be used
> >>by a plugin, or whatever), and feel that in their usage this results
> >>in a cleaner/better setup, power to them. Unfortunately there is no
> >>way to do it. Is Maven development driven by the needs of the users,
> >>or the need to enforce your (and in this case mine) idea of best
> >>practices at the exclusion of others. If it were a matter of
> >>compromising the best way to do it, or introducing large amounts of
> >>additional complexity to the setup/build process, I would understand
> >>it, but that is not the case here. This attittude should apply in
> >>general, not just to this feature.
> >>
> >>
> >
> >Features of Maven are influenced and sometimes defined by users. I
> >held fast to the idea that unit tests should not be skipped when
> >building an artifact, but code was eventually introduced to 'turn off'
> >that dependency. This multiple source tree thing is sort of reminding
> >me of that and I'm +1 to Jason's stand on not introducing changes to
> >the POM for multiple source trees.
> >
> >I like Maven to be about best practices and each and every time I've (
> >or others I've worked with ) ever worked with a project that has
> >multiple source trees for production code it is a pain and each time
> >it is easier to treat the trees as seperate projects.
> >
> >Maven provides a way to build projects, using one source tree for
> >project code. I don't think Maven should become a tool to build
> >anything, anyway. Maven provides a way for projects to migrate if
> >they choose Maven: make them into two projects as they want to be.
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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]
