Let me propose another solution. For the impatient skip to the middle of
the email for the xml stuff.
If we first list the reasons for both single and multiple source
directories:
Single Source:
1.1. code maintenance is easier (we don't forget to change stuff in
other locations)
1.2. minimise the chance of file conflicts. Don't want to have different
locations refering to the same package with each containing a file with
the same name
1.3. multiple locations make it a nightmare if everyone uses different
locations, as each plugin will have to be made aware of it, and which
one does it use?
1.4 we really don't want to put multiple source locations in the main
project descriptor and clutter it up, and we don't want to have to
obscure properties to point to source locations
1.5 don't want maven core to have todo anything special and cause it to
become to big. we want to hand everything off to plugins.
Multiple sources:
2.1. our unique situation warrants that separating the source to
multiple directories within tha same project is a good thing because.
2.1.a) to put auto generated code in a different directory than the hand
written stuff, which took us hours to write and we don't want to
accidently lose it.
2.1.b) our product is divided up into a number of 'modules', but
splitting it over multiple projects makes code maintainance even harder
than multiple source directories. Unfortunately its a hack to make it
all work with maven. Life sucks.
2.1.c) seperate 'demo code' or 'code examples' from the main production
code. ditto above.
2.1.d) be really cool if a derived source could include a master source
location from another project.
So both camps have valid reasons. The question is how do we ensure
everyone has their wish forfilled?. A possible solution could be to have
your cake and eat it to.
I propose 'derived single sources'. We define where the single source
resides, then build it from the true source locations. All this requires
is a plugin which copies files from the true locations to the derived
directory, throwing an error if there's a conflict (ERROR!: DUPLICATE
FILES FOR DERIVED SOURCE :x). No special changes to maven core.
Once maven can be run in the background as a long lived process it could
continuosly copy and compile the derived sources to ensure there are no
conflicts. All it has to do is keep the plugin running. I don't imagine
it'll be hard (tell me if I'm wrong!) since the new maven is likely to
use plexus.
If we put all this info in another file called sources.xml, it's kept
out of the project.xml file where it doesn't belong, but is included in
the pom by maven, so is available to plugins. The current project.xml
won't need to change much as all the resulting source directories are
the same as is now. The build section will look like this:
.
Say like this:
<build>
<unitTest>
<includes>
<include>**/*Test.java</include>
</includes>
</unitTest>
</build>
and all the source stuff will be in in another file called sources.xml,
which maven automatically looks up (like maven.xml). Having a seperate
file keeps the project.xml clean and dealing only with meta info, and
the sources.xml only with sources. I guess moving the build stuff into
this file would also be a good idea.
<sources>
<derived-sources>
<source>
<id>java</id>
<dir>${maven.java.src}</dir>
<master>src.tools</master>
<master>src.demos</master>
<master>src.code-gen</master>
</source>
<source>
<id>unittest</id>
<dir>${maven.test.src}</dir>
<master>src.custom-tests</master>
<master>src.code-gen-tests</master>
</source>
</derived-sources>
<master-sources>
<source>
<id>src.tools</id>
<dir>${basedir}/src/tools</dir>
<description>Tools to convert poms</description>
<source>
<source>
<id>src.demos</id>
<dir>${basedir}/src/demos</dir>
<description>Demo stuff for new developers</description>
<source>
<source>
<id>src.custom-tests</id>
<dir>${basedir}/src/custom-tests</dir>
<source>
<source>
<id>src.code-gen</id>
<dir>${basedir}/src/code-gen</dir>
<description>Auto code generated stuff</description>
<source>
<source>
<id>src.code-gen-tests</id>
<dir>${basedir}/src/code-gen-tests</dir>
<source>
</master-sources>
</sources>
If defined master sources don't exist then they are ignored.
Maybe maven could enforce that only a set of predefined derived id's
exist(java,unittest,aspectj?) but shouldn't have a limit on master
locations. Better still if a set of common ids is defined, with clear
documentation on their meaning, then there seems no reason why no other
derived sources could exist. Maybe non-standard derived ids could just
generate a clear warning that this practise is not recommended.like
(WARNING! MAVEN DESIGN GUIDELINES ARE BEING IGNORED. NONE-STANDARD
DERIVED SOURCE TREES!). May even be a requirement that all jakarta
projects follow this guideline which is enforceable (by ignoring these).
In my view this would meet all the requirements more or less.
Custom plugins which deal with your master directories wouldn't need the
stuff in the sources.xml file as they work independtly, just like now,
but this setup does allow other plugins to capture this output through
derived sources without knowing squat about the master sources. Standard
maven plugins use only derived sources, custom plugins write use
whatever.
Using the description tags these sources can be automatically
documented,telling new developers what each source directory does.
The master source locations may even be wildcard expressions like
"${basedir}/src/master/*" indicating all directories under master are to
be top level master locations. I could live with dropping this idea
though, however it allows writing plugins which drop their output in an
arbitrary directory and still have it picked up by other plugins,
Only your ide setup (like eclipse:generate-project) plugin must be
modified to be aware of the master sources but that should be easy. Not
sure how your ide can be notified of non java conflicts without making a
maven plugin for your ide, but the ide should do most of this itself
with the java code (in eclipse that's true, I imagine idea and others
are similiar)
That's my thoughts on the matter. Feel free to comment.
-Bert
Post by Mark H. Wilkinson-----Original Message-----
Sent: Wednesday, April 02, 2003 5:10 PM
To: Maven Users List
inter-projectdependencies for the Eclipse plugin )
Post by Rafal KrzewskiPost by Jason van ZylThat is distinctly different than multiple source directories for your
application. And here we are trying satisfy these
requirements and scale
Post by Rafal KrzewskiPost by Jason van Zylby letting the plugins deal with these different requirements
instead of
Post by Rafal KrzewskiPost by Jason van Zyltrying to jam everything into the POM.
I believe that the POM is the proper place for defining what goes in
your project. Plugins should retrieve information from there and proceed
with their work.
I've pondered this many a time. I really do not like the idea of having
to augment your POM when you choose to use a plugin. I very much like
the way the antlr plugin works in that it just kicks in when certain
resources are present.
Post by Rafal KrzewskiRight now many plugins rely on project.properties file
rather than POM, wich I think is not right.
Of course we should always use our best judgement to avoid cluttering
the POM, but I thing that the source directories (java, aspect, unit
test, and others that arise) are crucial for defining the project, and
therefore they should be in the POM.
I really like Michal's proposal with sources/source/type elements.
It puts the emphasis on the plugins undestating a specific type of
sources, and allows us remove funcitonality from Maven core -
it only manages information on abstract source sets.
Sorry but I'm not sure I follow. Adding this abstraction adds to maven's
core. Offloading all processing and definition to the plugin is the way
I want to move.
Post by Rafal KrzewskiI think this kind of change that it's really worth pursuing.
I'm not really in favour of this and much prefer the way the antlr
plugin works. I would like to see most of the <build/> element removed
and replaced with a place where you can define plugin settings if they
are required. We started this a long time ago and there was a proposal
that just never got implemented.
Post by Rafal KrzewskiR.
---------------------------------------------------------------------
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
---------------------------------------------------------------------