inter-project dependencies for the Eclipse plugin

[Mark H. Wilkinson]

I've just done a little hacking on the eclipse plugin. I wanted to be
able to specify that a dependency between two maven projects should
result in a project and classpath reference in the Eclipse project,
rather than an entry for a jar file. This should make things a bit more
natural when working with a number of related projects under Eclipse -
it removes the need to build jar files and install them in the maven
repository outside of Eclipse.

As I said, this is a preliminary hack - I think this is something that
needs addressing, but I'm not sure whether this is the best way to do
it. Comments welcome.

What I've done is allow a dependency to be marked as requiring an

<dependency>
<id>werkflow</id>
<version>1.0-beta-4</version>
<url>http://werkflow.werken.com/</url>
<properties>
<eclipse.dependency>true</eclipse.dependency>
</properties>
</dependency>

If you mark a dependency like this the plugin will assume that you have
the source of the dependent project open in the same workspace as the
project you're creating a .project and .classpath file for. Instead of
putting a jar reference into the classpath it will create a reference to
the project itself.

I thought about using the SNAPSHOT version to indicate things that are
local, but snapshot dependencies don't necessarily indicate that you
have the project open locally.

I'm not sure whether this should really go into project.xml - whether a
given developer has something open in Eclipse is possibly not something
that should be in CVS, for example. On the other hand, such a
declaration indicates that a dependency could be even more volatile than
a snapshot dependency, which might be useful information to have in
project.xml. I'm 50:50 over where this should go.

As I said, comments welcome. I'll update the patch based on feedback,
document it and send a new patch if things seem ok.

-Mark.

[Jeffrey D. Brekke]

This is very interesting. We have 36 projects, all with
interdependencies ( some build, some test, some runtime ) and to have
the reactor/maven maintain the eclipse projects like this would be
cool. Is there a dep heirarchy in eclipse where like a project dep is
used if present before a jar dep? Then we could just put both deps in
the project.

Post by Mark H. Wilkinson
I've just done a little hacking on the eclipse plugin. I wanted to
be able to specify that a dependency between two maven projects
should result in a project and classpath reference in the Eclipse
project, rather than an entry for a jar file. This should make
things a bit more natural when working with a number of related
projects under Eclipse - it removes the need to build jar files and
install them in the maven repository outside of Eclipse.
As I said, this is a preliminary hack - I think this is something
that needs addressing, but I'm not sure whether this is the best way
to do it. Comments welcome.
What I've done is allow a dependency to be marked as requiring an

<dependency> <id>werkflow</id> <version>1.0-beta-4</version>
<url>http://werkflow.werken.com/</url> <properties>
<eclipse.dependency>true</eclipse.dependency> </properties>
</dependency>

If you mark a dependency like this the plugin will assume that you
have the source of the dependent project open in the same workspace
as the project you're creating a .project and .classpath file
for. Instead of putting a jar reference into the classpath it will
create a reference to the project itself.
I thought about using the SNAPSHOT version to indicate things that
are local, but snapshot dependencies don't necessarily indicate that
you have the project open locally.
I'm not sure whether this should really go into project.xml -
whether a given developer has something open in Eclipse is possibly
not something that should be in CVS, for example. On the other hand,
such a declaration indicates that a dependency could be even more
volatile than a snapshot dependency, which might be useful
information to have in project.xml. I'm 50:50 over where this should
go.
As I said, comments welcome. I'll update the patch based on
feedback, document it and send a new patch if things seem ok.
-Mark.
Index: src/plugins-build/eclipse/plugin.jelly
===================================================================
/home/cvspublic/maven/src/plugins-build/eclipse/plugin.jelly,v
retrieving revision 1.9 diff -u -r1.9 plugin.jelly ---
src/plugins-build/eclipse/plugin.jelly 27 Mar 2003 13:16:40 -0000
1.9 +++ src/plugins-build/eclipse/plugin.jelly 28 Mar 2003 18:08:13
<j:set var="outputDir" value="${maven.eclipse.output.dir}"/>
<j:if test="${empty outputDir}"> - <j:set var="outputDir"
value="target\classes"/> + <j:set var="outputDir"
value="target/classes"/> </j:if>
<projects> + <j:forEach var="lib" items="${pom.artifacts}"> + <j:set
var="eclipseDependency" +
value="${lib.dependency.getProperty('eclipse.dependency')}"/> +
<j:if test="${eclipseDependency == 'true'}"> +
<project>${lib.dependency.artifactId}</project> + </j:if> +
@@
<classpathentry kind="var" path="JRE_LIB"
rootpath="JRE_SRCROOT" sourcepath="JRE_SRC"/> <j:forEach var="lib"
items="${pom.artifacts}"> - <classpathentry kind="var"
path="MAVEN_REPO${lib.urlPath}"/> + <j:set var="eclipseDependency" +
value="${lib.dependency.getProperty('eclipse.dependency')}"/> +
<j:choose> + <j:when test="${eclipseDependency == 'true'}"> +
<classpathentry kind="src" path="/${lib.dependency.artifactId}"/> +
</j:when> + <j:otherwise> + <classpathentry kind="var"
path="MAVEN_REPO${lib.urlPath}"/> + </j:otherwise> + </j:choose>
</j:forEach> <classpathentry kind="output" path="${outputDir}"/>
</classpath>
---------------------------------------------------------------------

[Mark H. Wilkinson]

Post by Jeffrey D. Brekke
This is very interesting. We have 36 projects, all with
interdependencies ( some build, some test, some runtime ) and to have
the reactor/maven maintain the eclipse projects like this would be
cool. Is there a dep heirarchy in eclipse where like a project dep is
used if present before a jar dep? Then we could just put both deps in
the project.

In Eclipse if you have a number of separate projects open in your
workspace you can specify dependencies between them, so you can say that
project 'foo' depends on project 'bar' in the same workspace. This
results in bar being on the classpath when foo is compiled. It also
helps to tie together the internal model that Eclipse uses - you can
click on a symbol in the foo project and it'll take you to the source in
the bar project or show you the javadoc for example. If you were
depending on a jar file you'd have to associate a source directory with
the jar file to get this to work.

What I tend to do is break a system down into modules, each of which is
a separate project with (typically) one source tree in each project. I
would then use Eclipse's classpath editor to specify for each project
which other projects were required.

At the moment there doesn't seem to be a way to model this kind of
dependency in the maven project model - dependencies are more-or-less
assumed to be versioned jar files. I think it would be useful to have a
way to model this kind of dependency hierarchy, if only so project files
for IDEs work more cleanly.

I don't know whether this kind of dependency information would be of use
when building multiple projects under reactor - presumably that can work
with jar file dependencies?

-Mark.

[Jeffrey D. Brekke]

Post by Mark H. Wilkinson
In Eclipse if you have a number of separate projects open in your
workspace you can specify dependencies between them, so you can say
that project 'foo' depends on project 'bar' in the same
workspace. This results in bar being on the classpath when foo is
compiled. It also helps to tie together the internal model that
Eclipse uses - you can click on a symbol in the foo project and
it'll take you to the source in the bar project or show you the
javadoc for example. If you were depending on a jar file you'd have
to associate a source directory with the jar file to get this to
work.

Right, I understand that. I was wondering if you had a project
dependency and a jar dependency to the same project defined if eclipse
would use the project classes before going to the jar. It was a real
quick and ugly way of maybe making it work.

Post by Mark H. Wilkinson
What I tend to do is break a system down into modules, each of which
is a separate project with (typically) one source tree in each
project. I would then use Eclipse's classpath editor to specify for
each project which other projects were required.
At the moment there doesn't seem to be a way to model this kind of
dependency in the maven project model - dependencies are
more-or-less assumed to be versioned jar files. I think it would be
useful to have a way to model this kind of dependency hierarchy, if
only so project files for IDEs work more cleanly.

Interesting, I've always thought of maven as a command-line IDE.

There was some talk awhile back, around the time jar override
functionality was added to maven, that we could depend on the classes
of other projects, not just the artifacts. I don't think anything but
talking about happened though.

Post by Mark H. Wilkinson
I don't know whether this kind of dependency information would be of
use when building multiple projects under reactor - presumably that
can work with jar file dependencies?

The jar dependencies are there now in the reactor. Maybe we need pom
dependencies between reactor'd projects.

[Mark H. Wilkinson]

Post by Jeffrey D. Brekke
Right, I understand that. I was wondering if you had a project
dependency and a jar dependency to the same project defined if eclipse
would use the project classes before going to the jar. It was a real
quick and ugly way of maybe making it work.

I guess you could make that work if the classpath ordering was correct,
but you might run into problems if files from the jar version showed
through - for example, classes you've deleted recently but which are
still in the jar file.

Post by Jeffrey D. Brekke
There was some talk awhile back, around the time jar override
functionality was added to maven, that we could depend on the classes
of other projects, not just the artifacts. I don't think anything but
talking about happened though.

I wasn't around when that was discussed (so excuse me if I'm rehashing
old stuff), but had thought about that in the context of my quick hack.
The problem (I think) is that maven would need a fair amount of extra
infrastructure to track the locations of projects' source trees in the
local file system in order to resolve dependencies. It's not that
unreasonable - each time you build a project it would dump some
information about the compiled classes directory into a
$MAVEN_HOME/repository directory instead of installing a jar file. But I
wasn't about to start hacking something like that when I don't know
whether there's an existing design for how people expect this to work in
the future.

My hack depends on Eclipse tying a project name to a classes directory,
which takes the information out of maven's hands. On the other hand, it
doesn't require maven to think about more than one project at once.

Post by Jeffrey D. Brekke

Post by Mark H. Wilkinson
I don't know whether this kind of dependency information would be of
use when building multiple projects under reactor - presumably that
can work with jar file dependencies?

The jar dependencies are there now in the reactor. Maybe we need pom
dependencies between reactor'd projects.

Does this require each reactor'd build to install a copy of the jar into
the repository? i.e. if A depends on B, would the reactor need to be
told to do
compile B
build B.jar
install B.jar in maven repo
compile A with B.jar from maven repo on classpath
build A.jar

or can it manage
compile B
compile A with B/target/classes on classpath

? Or is that what you're suggesting would need pom dependencies?

-Mark.

[Jeffrey D. Brekke]

[SNIP]

Post by Mark H. Wilkinson

Post by Mark H. Wilkinson
I don't know whether this kind of dependency information would be

of > use when building multiple projects under reactor - presumably
that > can work with jar file dependencies?
The jar dependencies are there now in the reactor. Maybe we need
pom dependencies between reactor'd projects.

Does this require each reactor'd build to install a copy of the jar
into the repository? i.e. if A depends on B, would the reactor need
to be told to do compile B build B.jar install B.jar in maven repo
compile A with B.jar from maven repo on classpath build A.jar
or can it manage compile B compile A with B/target/classes on
classpath
? Or is that what you're suggesting would need pom dependencies?

Yes, this is what I meant. I'm not sure if you can currently do this
right now with the jar override. The reactor is still under
development at the moment.

=====================================================================
Jeffrey D. Brekke ***@wi.rr.com
Wisconsin, USA ***@apache.org
***@yahoo.com

[David Zeleznik]

This is interesting for me also because I am trying to tackle a similar
issue for improving how the JBuilder plugin generates JB project files. In
JB, a project can reference dependent "libraries". A library is a
configuration file that can reference classes, jars and optionally source
files. A library can also declare dependencies on other libraries. JBuilder
then builds its project classpath from the entire tree of all referenced
libraries. Any library that defines java source files will be included in
JBuilders symbol completion, etc. Library definitions are stored in the
user's home directory where they can be shared among projects.

So, my first take at solving this is to generate the JB project file and
iterate over each of the project's dependencies. I then convert each
dependency into a reference to a JB library definition of the same name. If
the library has not been defined yet, I create a basic library definition
that just references the jar in the local repo. From the pom dependency
there is no way for me to determine whether the source code for the
dependency/library exists on the local workstation and there is no way to
determine if the library has dependencies of its own. After creating the JB
project file, I then create a library definition file for the maven project
that can be referenced by other projects. This library definition will
overwrite any basic/jar-only library definition and contains all of the
source and dependency info. Therefore, I am hoping that the user will be
able to go to each maven project on their workstation, run the JBuilder
plugin, and result in a full set of JB project and library definitions.
Libraries that they are not building locally will just reference the jar in
the local repo. Libraries that they are building locally will contain full
source and dependency info.

Now, my second idea is to somehow take advantage of the ability to deploy
pom's to the remote repo. I do not see any place these are used in the Maven
code, but I think it is an avenue to obtain full info on a dependency.
Ideally, it would be cool to somehow convert a Dependency object into a full
Project object by downloading the dependency's pom from the repo. Then there
could be a mechanism for traversing the entire tree of Projects, rather than
the current 2-level Project/parent - Dependency/child structure.

--------------------------------------
David Zeleznik
ILOG - Changing the rules of business
mailto:***@ilog.com
http://www.ilog.com
--------------------------------------

-----Original Message-----
Sent: Friday, March 28, 2003 2:37 PM
To: Maven Users List
Subject: Re: inter-project dependencies for the Eclipse plugin

Post by Jeffrey D. Brekke
This is very interesting. We have 36 projects, all with
interdependencies ( some build, some test, some runtime ) and to have
the reactor/maven maintain the eclipse projects like this would be
cool. Is there a dep heirarchy in eclipse where like a project dep is
used if present before a jar dep? Then we could just put both deps in
the project.

In Eclipse if you have a number of separate projects open in your
workspace you can specify dependencies between them, so you can say that
project 'foo' depends on project 'bar' in the same workspace. This
results in bar being on the classpath when foo is compiled. It also
helps to tie together the internal model that Eclipse uses - you can
click on a symbol in the foo project and it'll take you to the source in
the bar project or show you the javadoc for example. If you were
depending on a jar file you'd have to associate a source directory with
the jar file to get this to work.
What I tend to do is break a system down into modules, each of which is
a separate project with (typically) one source tree in each project. I
would then use Eclipse's classpath editor to specify for each project
which other projects were required.
At the moment there doesn't seem to be a way to model this kind of
dependency in the maven project model - dependencies are more-or-less
assumed to be versioned jar files. I think it would be useful to have a
way to model this kind of dependency hierarchy, if only so project files
for IDEs work more cleanly.
I don't know whether this kind of dependency information would be of use
when building multiple projects under reactor - presumably that can work
with jar file dependencies?
-Mark.
---------------------------------------------------------------------

[Mark McBride]

Good idea! This is one of the things that I was hoping would get addressed =)

I'm new to the list so I'm not sure if this has been covered, but has there
been any thoughts to supporting multiple source entries so that when one
runs eclipse:generate-project it will properly set up the src's in the
.classpath. I really have no preference of setting the source folders
through properties or in the project.xml.

It would also be nice to specify the eclipse output entry in the .classpath
(path=bin) separate from maven's build path "target/classes*.

Thanks

-Mark

Post by Mark H. Wilkinson
I've just done a little hacking on the eclipse plugin. I wanted to be
able to specify that a dependency between two maven projects should
result in a project and classpath reference in the Eclipse project,
rather than an entry for a jar file. This should make things a bit more
natural when working with a number of related projects under Eclipse -
it removes the need to build jar files and install them in the maven
repository outside of Eclipse.
As I said, this is a preliminary hack - I think this is something that
needs addressing, but I'm not sure whether this is the best way to do
it. Comments welcome.
What I've done is allow a dependency to be marked as requiring an

<dependency>
<id>werkflow</id>
<version>1.0-beta-4</version>
<url>http://werkflow.werken.com/</url>
<properties>
<eclipse.dependency>true</eclipse.dependency>
</properties>
</dependency>

If you mark a dependency like this the plugin will assume that you have
the source of the dependent project open in the same workspace as the
project you're creating a .project and .classpath file for. Instead of
putting a jar reference into the classpath it will create a reference to
the project itself.
I thought about using the SNAPSHOT version to indicate things that are
local, but snapshot dependencies don't necessarily indicate that you
have the project open locally.
I'm not sure whether this should really go into project.xml - whether a
given developer has something open in Eclipse is possibly not something
that should be in CVS, for example. On the other hand, such a
declaration indicates that a dependency could be even more volatile than
a snapshot dependency, which might be useful information to have in
project.xml. I'm 50:50 over where this should go.
As I said, comments welcome. I'll update the patch based on feedback,
document it and send a new patch if things seem ok.
-Mark.
Index: src/plugins-build/eclipse/plugin.jelly
===================================================================
RCS file: /home/cvspublic/maven/src/plugins-build/eclipse/plugin.jelly,v
retrieving revision 1.9
diff -u -r1.9 plugin.jelly
--- src/plugins-build/eclipse/plugin.jelly 27 Mar 2003 13:16:40
-0000 1.9
+++ src/plugins-build/eclipse/plugin.jelly 28 Mar 2003 18:08:13 -0000
@@ -19,7 +19,7 @@
<j:set var="outputDir" value="${maven.eclipse.output.dir}"/>
<j:if test="${empty outputDir}">
- <j:set var="outputDir" value="target\classes"/>
+ <j:set var="outputDir" value="target/classes"/>
</j:if>
<ant:echo>Creating ${basedir}/.project ...</ant:echo>
@@ -29,6 +29,13 @@
<name>${pom.artifactId}</name>
<comment></comment>
<projects>
+ <j:forEach var="lib" items="${pom.artifacts}">
+ <j:set var="eclipseDependency"
+ value="${lib.dependency.getProperty('eclipse.dependency')}"/>
+ <j:if test="${eclipseDependency == 'true'}">
+ <project>${lib.dependency.artifactId}</project>
+ </j:if>
+ </j:forEach>
</projects>
<buildSpec>
<buildCommand>
@@ -83,7 +90,16 @@
<classpathentry kind="var" path="JRE_LIB" rootpath="JRE_SRCROOT"
sourcepath="JRE_SRC"/>
<j:forEach var="lib" items="${pom.artifacts}">
- <classpathentry kind="var" path="MAVEN_REPO${lib.urlPath}"/>
+ <j:set var="eclipseDependency"
+ value="${lib.dependency.getProperty('eclipse.dependency')}"/>
+ <j:choose>
+ <j:when test="${eclipseDependency == 'true'}">
+ <classpathentry kind="src"
path="/${lib.dependency.artifactId}"/>
+ </j:when>
+ <j:otherwise>
+ <classpathentry kind="var" path="MAVEN_REPO${lib.urlPath}"/>
+ </j:otherwise>
+ </j:choose>
</j:forEach>
<classpathentry kind="output" path="${outputDir}"/>
</classpath>
---------------------------------------------------------------------

[Mark H. Wilkinson]

Post by Mark McBride
I'm new to the list

heh; me too!

Post by Mark McBride
so I'm not sure if this has been covered, but has there
been any thoughts to supporting multiple source entries so that when one
runs eclipse:generate-project it will properly set up the src's in the
.classpath. I really have no preference of setting the source folders
through properties or in the project.xml.
From what I've seen the maven project model assumes one main source tree

per project. Additional source trees have to have specific plugins to
handle them (for example, the unit test source tree is compiled by the
test plugin). The Eclipse plugin will add both the main and unit test
source trees to the .classpath file if they are specified in project.xml

Or did you mean having multiple source directories that all finish up in
the project's resulting jar file?

Post by Mark McBride
It would also be nice to specify the eclipse output entry in the .classpath
(path=bin) separate from maven's build path "target/classes*.

I think you can do this by setting the maven.eclipse.output.dir property

-Mark.

[Mark McBride]

Thanks for the info on the maven.eclipse.output.dir property.

As for the multiple source:
For moving the multiple source directories we've used a jelly script that
copies the mulitple src with the pre-goal:prepare-filesystem goal. The
problem I'm having is when I run the eclipse:generate-project I can not
specify multiple source directories that I've set up in eclipse. We have
one source folder for our jdeveloper/bc4j work and one for our eclipse
workspace. I'd like to specify that I have a src located at "src/java" and
"src/jdev". This would then add the following entries to the .classpath:
<classpathentry kind="src" path="src/java"/>
<classpathentry kind="src" path="src/jdev"/>
I hope that makes sense.

-Mark

Post by Mark H. Wilkinson

Post by Mark McBride
From what I've seen the maven project model assumes one main source tree

per project. Additional source trees have to have specific plugins to
handle them (for example, the unit test source tree is compiled by the
test plugin). The Eclipse plugin will add both the main and unit test
source trees to the .classpath file if they are specified in project.xml
Or did you mean having multiple source directories that all finish up in
the project's resulting jar file?

Mark T. McBride
Computer Scientist
Lawrence Livermore National Laboratory
http://www.llnl.gov

Office: [phone]
Fax: [phone]

[Mark H. Wilkinson]

Post by Mark McBride
For moving the multiple source directories we've used a jelly script that
copies the mulitple src with the pre-goal:prepare-filesystem goal. The
problem I'm having is when I run the eclipse:generate-project I can not
specify multiple source directories that I've set up in eclipse. We have
one source folder for our jdeveloper/bc4j work and one for our eclipse
workspace. I'd like to specify that I have a src located at "src/java" and
<classpathentry kind="src" path="src/java"/>
<classpathentry kind="src" path="src/jdev"/>
I hope that makes sense.

Ahh; see what you mean. I don't think it would be that difficult to add
support for that kind of thing, but it's not there now. You'd need to
solve a couple of problems:
1. You need a standard way to represent multiple Java source trees
in the POM. At the moment the paths to the source trees are
encoded in the jelly script, so aren't easily available to any
plugin. A simple solution that you could start with would be to
put them in <properties> elements in the POM, but there probably
ought to be support for this in the POM itself (IMHO).
2. You'd then hack the eclipse plugin slightly to iterate over the
source trees and add appropriate classpathentry elements.
Shouldn't be too difficult.

-Mark.

[d***@multitask.com.au]

Post by Mark H. Wilkinson
Ahh; see what you mean. I don't think it would be that difficult to add
support for that kind of thing, but it's not there now. You'd need to
1. You need a standard way to represent multiple Java source trees
in the POM. At the moment the paths to the source trees are
encoded in the jelly script, so aren't easily available to any
plugin. A simple solution that you could start with would be to
put them in <properties> elements in the POM, but there probably
ought to be support for this in the POM itself (IMHO).

We've tried having multiple source trees before. It was damn difficult.
I'm happy for someone else to give it a go and get everything working
consistently, but I personally have been down that road and never want to
go back.

--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au

[Jason van Zyl]

Post by Mark H. Wilkinson

Post by Mark H. Wilkinson
Ahh; see what you mean. I don't think it would be that difficult to add
support for that kind of thing, but it's not there now. You'd need to
1. You need a standard way to represent multiple Java source trees
in the POM.

That will never happen. It was fully intentional that there is only one
source directory per project.

Post by Mark H. Wilkinson
At the moment the paths to the source trees are

Post by Mark H. Wilkinson
encoded in the jelly script, so aren't easily available to any
plugin. A simple solution that you could start with would be to
put them in <properties> elements in the POM, but there probably
ought to be support for this in the POM itself (IMHO).

Sorry, I don't understand. Do you mean for multiple source directories
when you add them manually? The addPath tag was made specifically for
generative plugins like antlr where sources are generated. That is the
only intended use.

Post by Mark H. Wilkinson
We've tried having multiple source trees before. It was damn difficult.
I'm happy for someone else to give it a go and get everything working
consistently, but I personally have been down that road and never want to
go back.

+1

There will never, ever, ever be support for more than one source tree
per project.

Post by Mark H. Wilkinson
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
---------------------------------------------------------------------

--
jvz.

Jason van Zyl
***@zenplex.com
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

[Mark H. Wilkinson]

Post by Jason van Zyl

Post by Mark H. Wilkinson
At the moment the paths to the source trees are
encoded in the jelly script, so aren't easily available to any
plugin. A simple solution that you could start with would be to
put them in <properties> elements in the POM, but there probably
ought to be support for this in the POM itself (IMHO).

Sorry, I don't understand.

Mark McBride was saying that he has a jelly script to copy his multiple
source directories into one source tree for building (I think). I was
saying that it would be difficult for a plugin to use this information
because it's part of his jelly script, not part of the POM.

Post by Jason van Zyl
There will never, ever, ever be support for more than one source tree
per project.

Hmm; by that do you mean one source tree compiled by the java plugin?
The unit test source tree is effectively a second source tree, it's just
processed in a different way. As is the source tree that's generated by
the antlr plugin, from what you say.

I think there's a bit of a problem with the model here, because plugins
that would like to know about the various trees that contain Java source
need to have explicit code in them to handle each source tree. The
Eclipse plugin currently knows about the sourceDirectory and the
unitTestSourceDirectory. If another kind of plugin was introduced and it
had its own Java source tree, the Eclipse plugin (for example) would
need to be modified to extract the information from the POM and put it
in the .classpath file; as would any other plugin which needed to know
about source code locations...

I'm happy with one main source tree per project, but it might be useful
to have some way to extract all the source-tree-kind-of-things-that-are-
manipulated-by-plugins from the POM.

-Mark.

[Jason van Zyl]

Post by Mark H. Wilkinson
I think there's a bit of a problem with the model here, because plugins
that would like to know about the various trees that contain Java source
need to have explicit code in them to handle each source tree. The
Eclipse plugin currently knows about the sourceDirectory and the
unitTestSourceDirectory. If another kind of plugin was introduced and it
had its own Java source tree, the Eclipse plugin (for example) would
need to be modified to extract the information from the POM and put it
in the .classpath file; as would any other plugin which needed to know
about source code locations...

So if we use, say, the Antlr plugin that generates sources you're
talking about some non-maven compilation process knowing about the
generated sources? The addPath tag allows any addition path of sources
to be added to the maven.compile.src.set which is what is currently used
to compile the project sources. Take a look at the Antlr plugin for how
this works. If we need a way of external tasks to know where sources are
we could probably add something to the POM that makes this information
available when the addPath tag is executed.

Post by Mark H. Wilkinson
---------------------------------------------------------------------

--
jvz.

Jason van Zyl
***@zenplex.com
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

[Mark H. Wilkinson]

Post by Jason van Zyl
So if we use, say, the Antlr plugin that generates sources you're
talking about some non-maven compilation process knowing about the
generated sources?

Yeah, that's basically it.

Post by Jason van Zyl
The addPath tag allows any addition path of sources
to be added to the maven.compile.src.set which is what is currently used
to compile the project sources. Take a look at the Antlr plugin for how
this works. If we need a way of external tasks to know where sources are
we could probably add something to the POM that makes this information
available when the addPath tag is executed.

I think that might be useful. Would the information from the addPath tag
be available even if the plugin hadn't actually generated it's source
code during that instance of maven? For example, if someone did

maven eclipse:generate-project

the antlr (or whatever) plugin wouldn't (probably) be executed, hence
the addPath data wouldn't be available.

That said, this isn't actually the problem I was trying to fix when I
started this thread :-) _That_ problem is that if you break a system
into a number of maven projects, one source tree in each, it's useful to
be able to say that a dependency actually relates to the current version
of another maven project rather than a jar file in some repository. Any
thoughts on that problem?

-Mark.

[Colin Sampaleanu]

Post by Jason van Zyl

Post by Mark H. Wilkinson

Post by Mark H. Wilkinson
Ahh; see what you mean. I don't think it would be that difficult to add
support for that kind of thing, but it's not there now. You'd need to
1. You need a standard way to represent multiple Java source trees
in the POM.

That will never happen. It was fully intentional that there is only one
source directory per project.

Post by Mark H. Wilkinson
At the moment the paths to the source trees are

Post by Mark H. Wilkinson
encoded in the jelly script, so aren't easily available to any
plugin. A simple solution that you could start with would be to
put them in <properties> elements in the POM, but there probably
ought to be support for this in the POM itself (IMHO).

Sorry, I don't understand. Do you mean for multiple source directories
when you add them manually? The addPath tag was made specifically for
generative plugins like antlr where sources are generated. That is the
only intended use.

Post by Mark H. Wilkinson
We've tried having multiple source trees before. It was damn difficult.
I'm happy for someone else to give it a go and get everything working
consistently, but I personally have been down that road and never want to
go back.

+1
There will never, ever, ever be support for more than one source tree
per project.

Jason, can you clarify what the real issue with multiple source
directories is? I've tried searching through the dev and user archives
I've got (back to last Aug), and couldn't get a good idea of what the
problem is. The best I could find was a statement from you that you
don't consider it good form since it encourages putting together
unrelated source in the same project.

While having Maven encourage good source organization practices is a
laudible goal, are there any real technical issues with supporting
multiple source directories? Given that Maven already does support
multiple source dirs in the only fashion I use them (to separate test
sources from non-test sources), and handles generated sources (from the
like of xdoclet), I don't personally need anything more for my projects.
However this restriction seems like a somewhat arbitrary decision
notheless, which makes it much harder for some projects currently using
Ant or various IDEs like JBuilder or Eclipse, all of which do currently
support multiple source directories (and multiple target directories for
that matter), to switch over to Maven. If existing projects must be
significantly reorganized to use Maven, there is much less chance they
will do so, as opposed to the approach of getting the build going in
some fashion, and then doing a gradual refactoring of the project
layout(s). IMHO, the best tools are flexible enough to support existing
practices, while gently prodding users towards best practices.

Regards,

Colin

[Jason van Zyl]

Post by Colin Sampaleanu
Jason, can you clarify what the real issue with multiple source
directories is?

Separation of concerns. If you have gone to the trouble of separating
your sources into a separate tree then you probably did it for a reason.
When you have multiple sources trees, you usually have multiple
concerns. Testing usually becomes muddled, lots of hacks find their way
into the code because the source trees are mixed up. This is also a
problem on Maven's side because you can't deal with each project
uniformly. Plugins become really ugly when having to look in N places
for sources, what to do if there is more than one, how they relate ...
just gets nasty.

Post by Colin Sampaleanu
While having Maven encourage good source organization practices is a
laudible goal, are there any real technical issues with supporting
multiple source directories?

None. Maven could support N source directories. But just because it's
technically possible doesn't mean it's a good thing or should be
supported.

Post by Colin Sampaleanu
Given that Maven already does support
multiple source dirs in the only fashion I use them (to separate test
sources from non-test sources), and handles generated sources (from the
like of xdoclet), I don't personally need anything more for my projects.

Multiple source directories are not supported. The addPath tag is being
abused if people are not using it in conjunction with some generative
process and it will just eventually bite them in the ass. Make their
projects many fold more complex than they have to be, developer
comprehension will drop an order of magnitude and it's generally a
lose/lose situation.

Post by Colin Sampaleanu
However this restriction seems like a somewhat arbitrary decision
notheless,

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.
--
jvz.

Jason van Zyl
***@zenplex.com
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

[Colin Sampaleanu]

Post by Jason van Zyl

Post by Colin Sampaleanu
Jason, can you clarify what the real issue with multiple source
directories is?

...

Post by Colin Sampaleanu
Given that Maven already does support
multiple source dirs in the only fashion I use them (to separate test
sources from non-test sources), and handles generated sources (from the
like of xdoclet), I don't personally need anything more for my projects.

Multiple source directories are not supported. The addPath tag is being
abused if people are not using it in conjunction with some generative
process and it will just eventually bite them in the ass. Make their
projects many fold more complex than they have to be, developer
comprehension will drop an order of magnitude and it's generally a
lose/lose situation.

Post by Colin Sampaleanu
However this restriction seems like a somewhat arbitrary decision
notheless,

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.

Just my opinion, and I hope I don't come off the wrong way here, I do in
general love Maven and what you've done.

Regards, Colin

[Jeffrey D. Brekke]

{SNIP]

Post by Colin Sampaleanu

Post by Jason van Zyl
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.

[Ben Walding]

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?

Post by Jeffrey D. Brekke
{SNIP]

Post by Colin Sampaleanu

Post by Jason van Zyl
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.

[Raphaël Piéroni]

Hello maven devs and users,

i dunno why splitting a source tree but as said before maven at the
moment as multiple trees : one for tests, one for java, one for
aspects.

but i'll see a new one that can be added : aspect-test because some
aspects are for production execution and some others for tests.

in such a case :
src/aspectj
src/java
src/test
src/aspectjtest

when using :
java:compile : use src/java
aspectj : use src/java+src/aspectj
test : use src/test after java:compile or aspectj
test:aspect : use all for compile as we can have aspects that modify he
"production" code in the aspectjtest directory (eg tracing issues)

do that make sense ?

R

=====
------------------------------------
| Raphaël Piéroni |
| 33+ 223 351 354 |
| mailto:***@dexem.com |
| http://www.dexem.com |
| mailing:***@yahoo.fr |
------------------------------------

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

[Jason van Zyl]

Post by Raphaël Piéroni
Hello maven devs and users,
i dunno why splitting a source tree but as said before maven at the
moment as multiple trees : one for tests, one for java, one for
aspects.

The one for aspects will more than likely be removed and be made the
responsibility of the particular plugin. As aspectj is not the only AOP
type mechanism people use. Happens to be the one I use which is why it
got jammed into the POM but it probably doesn't belong in there.

Post by Raphaël Piéroni
but i'll see a new one that can be added : aspect-test because some
aspects are for production execution and some others for tests.
src/aspectj
src/java
src/test
src/aspectjtest
java:compile : use src/java
aspectj : use src/java+src/aspectj
test : use src/test after java:compile or aspectj
test:aspect : use all for compile as we can have aspects that modify he
"production" code in the aspectjtest directory (eg tracing issues)
do that make sense ?
R
=====
------------------------------------
| Raphaël Piéroni |
| 33+ 223 351 354 |
| http://www.dexem.com |
------------------------------------
___________________________________________________________
Yahoo! Mail : http://fr.mail.yahoo.com
---------------------------------------------------------------------

--
jvz.

Jason van Zyl
***@zenplex.com
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

[v***@pivolis.com]

Post by Raphaël Piéroni
Hello maven devs and users,
i dunno why splitting a source tree but as said before maven at the
moment as multiple trees : one for tests, one for java, one for
aspects.
but i'll see a new one that can be added : aspect-test because some
aspects are for production execution and some others for tests.
src/aspectj
src/java
src/test
src/aspectjtest
java:compile : use src/java
aspectj : use src/java+src/aspectj
test : use src/test after java:compile or aspectj
test:aspect : use all for compile as we can have aspects that modify he
"production" code in the aspectjtest directory (eg tracing issues)
do that make sense ?

Absolutely. Definition of src directories is done qt the plugin level. For
example, the Cactus plugin defines a src/test-cactus directory. The
PatternTestig Maven plugin (http://patterntesting.sf.net) defines a src/test-
aspect directory.

-Vincent

Post by Raphaël Piéroni
R
=====
------------------------------------
| Raphaël Piéroni |
| 33+ 223 351 354 |
| http://www.dexem.com |
------------------------------------
___________________________________________________________
Yahoo! Mail : http://fr.mail.yahoo.com
---------------------------------------------------------------------

[michal.maczka]

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-----
Sent: Wednesday, April 02, 2003 6:23 AM
To: Maven Users List
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?

Post by Jeffrey D. Brekke

Post by Colin Sampaleanu

Post by Jason van Zyl

On Tue, 01 Apr 2003 13:20:56 -0500, Colin Sampaleanu

{SNIP]

Post by Colin Sampaleanu

Post by Jason van Zyl
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.

---------------------------------------------------------------------

[Rafal Krzewski]

<sources>

Post by michal.maczka
<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>src/cpp</path>

Post by michal.maczka
</source>

</sources>

Post by michal.maczka
and then
<resources>
<resource>
<type>java<type>
.....
</resource>
<resource>
<type>test<type>
.....
</resource>
...
<resources>

I like your proposal very much. I think it's clear, orthogonal, has
natural space for extension (with plugins, of course) and translate to
convenient Jelly (applying JAXP exprs on pom) and Java interfaces.

I give my non-commiter + to the idea.

R.

[Mark McBride]

I also like the idea listed in the email below.

As to Ben's email here are my answers:

Why do you have multiple source trees?

We are using two tools for our projects. One tool is a code generation tool
for our o/r mapping layer and we would like to keep it in it's own src
directory to alleviate problems with the tool killing code we produce with
the other tool.

What is in them?

We have our object/relational mapping wizard driven code in one src
directory and we have another src directory that is managed by eclipse
which we write all of our code that uses the object/relational wizard
created code.

Do they build distinct artifacts?
They build one distinct war/ear for our projects.


Currently we use a jelly script to move the to src's into a "build/src"
directory used by Maven as it's individual src directory. So each project
needs this jelly script and it starts to look more like ant projects. It
would be nice if Maven did this copy for us.

My other concern was somewhat separate from the pom issue of multiple
sources. I would like a way to define multiple sources so that plug-ins
like eclipse:generate-project could take them into account and include the
appropriate src entries in the eclipse specific classpath file. Maybe I
should start a separate thread on that subject sense it is somewhat
different then the multiple src pom issue.

I do think that whatever decision is made about multiple source directories
there should be some documentation stating how maven uses source
directories, why it does it that way, etc. I haven't worked on projects
with multiple source directories before so it would be nice to see
documentation on the downfalls of multiple source directory projects.

-Mark

Post by Rafal Krzewski
<sources>

Post by michal.maczka
<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>src/cpp</path>

Post by michal.maczka
</source>

</sources>

Post by michal.maczka
and then
<resources>
<resource>
<type>java<type>
.....
</resource>
<resource>
<type>test<type>
.....
</resource>
...
<resources>

I like your proposal very much. I think it's clear, orthogonal, has
natural space for extension (with plugins, of course) and translate to
convenient Jelly (applying JAXP exprs on pom) and Java interfaces.
I give my non-commiter + to the idea.
R.
---------------------------------------------------------------------

Mark T. McBride
Computer Scientist
Lawrence Livermore National Laboratory
http://www.llnl.gov

Office: [phone]
Fax: [phone]

[D***@emc.com]

Ben,

Post by Ben Walding
So to Colin (I think)

I'm not Colin, but I will try to explain the situation I'm in.

Post by Ben Walding
Why do you have multiple source trees?
What is in them?

1) src/java: production source code
2) src/junit: unit test code: component white box tests
3) src/integration: integration unit test code: component black box tests
3) src/mocks: mock objects
4) src/functional: test code used by our own functional test system

Post by Ben Walding
Do they build distinct artifacts?

Yes! src/java is the input to my production jar, while src/mocks is the
input to a jar containing the mocks that can be used by the unit tests of
this component and by the integration unit tests of higher level components
as the stub for this component.

I could however split the interfaces from the production implementation as
two Maven projects and add a third for the mocks. Do I want to do this? NO,
since these interfaces, implemenation and test code is what makes up my
component! I still have one production deliverable, but I also want to
deliver a test artifact that can be used as a stub for this component by
other components. When the production code changes, the tests as well as the
mocks have to be kept in sync by the developer who changes something. If I
had to split all the code, people would definitely forget about some of
these parts.

I agree with Jason van Zyl to have only one source folder to define the
*production* code! But I would like to rephrase it as "The java plugin will
only accept 1 input source folder, always!". If you don't change the
statement, it's confusing for people since they see references to unit &
integration unit tests in the POM. Do these references belong there? In my
opinion, they do. I think of the POM as the container keeping all the
configuration details for plugins of Maven I use to process my project.

I would like to state that it's up to the plugin writer to define what it
needs as input and what as output. Look at the following example:

java plugin:
- input: sourceDirectory
- output: hardcoded to targets\classes?

aspectj plugin:
- input: aspectSourceDirectory
- input: srcDirectory (re-use the tag of the java plugin here?)
- output: generated sources with aspects woven into it. (re-use the
sourceDirectory value of the Java-plugin here?)

It's been a while since I used AspectJ, but if I remember well, you write
your source code, you write your aspects and then weave all together.
Doesn't this mean that that the AspectJ plugin needs two inputs? I need two
source folders, no?

If you standardize this, then the documentation for each plugin would not
only list the goals and properties, but also a description of what you
should write in the POM to configure the plugin. The documentation of the
aspectj:compile goal is a good example of this: it defines an additional
source folder within the build tag!

Maven has been very valuable so far, but this source folder thing must be
resolved before a 1.0 release in my opinion. It's not a black or white
thing, we have to cover the gray area and cover it consistently!

Ringo

[Jason van Zyl]

Post by D***@emc.com
Ben,

Post by Ben Walding
So to Colin (I think)

I'm not Colin, but I will try to explain the situation I'm in.

Post by Ben Walding
Why do you have multiple source trees?
What is in them?

1) src/java: production source code
2) src/junit: unit test code: component white box tests
3) src/integration: integration unit test code: component black box tests
3) src/mocks: mock objects
4) src/functional: test code used by our own functional test system

That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these requirements and scale
by letting the plugins deal with these different requirements instead of
trying to jam everything into the POM.

Post by D***@emc.com

Post by Ben Walding
Do they build distinct artifacts?

Yes! src/java is the input to my production jar, while src/mocks is the
input to a jar containing the mocks that can be used by the unit tests of
this component and by the integration unit tests of higher level components
as the stub for this component.
I could however split the interfaces from the production implementation as
two Maven projects and add a third for the mocks. Do I want to do this? NO,
since these interfaces, implemenation and test code is what makes up my
component! I still have one production deliverable, but I also want to
deliver a test artifact that can be used as a stub for this component by
other components. When the production code changes, the tests as well as the
mocks have to be kept in sync by the developer who changes something. If I
had to split all the code, people would definitely forget about some of
these parts.
I agree with Jason van Zyl to have only one source folder to define the
*production* code! But I would like to rephrase it as "The java plugin will
only accept 1 input source folder, always!". If you don't change the
statement, it's confusing for people since they see references to unit &
integration unit tests in the POM. Do these references belong there? In my
opinion, they do. I think of the POM as the container keeping all the
configuration details for plugins of Maven I use to process my project.
I would like to state that it's up to the plugin writer to define what it
- input: sourceDirectory
- output: hardcoded to targets\classes?
- input: aspectSourceDirectory
- input: srcDirectory (re-use the tag of the java plugin here?)
- output: generated sources with aspects woven into it. (re-use the
sourceDirectory value of the Java-plugin here?)
It's been a while since I used AspectJ, but if I remember well, you write
your source code, you write your aspects and then weave all together.
Doesn't this mean that that the AspectJ plugin needs two inputs? I need two
source folders, no?
If you standardize this, then the documentation for each plugin would not
only list the goals and properties, but also a description of what you
should write in the POM to configure the plugin. The documentation of the
aspectj:compile goal is a good example of this: it defines an additional
source folder within the build tag!
Maven has been very valuable so far, but this source folder thing must be
resolved before a 1.0 release in my opinion. It's not a black or white
thing, we have to cover the gray area and cover it consistently!
Ringo
---------------------------------------------------------------------

--
jvz.

Jason van Zyl
***@zenplex.com
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

[Rafal Krzewski]

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these requirements and scale
by letting the plugins deal with these different requirements instead of
trying 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. Right 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.

I think this kind of change that it's really worth pursuing.

R.

[Jason van Zyl]

Post by Rafal Krzewski

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these requirements and scale
by letting the plugins deal with these different requirements instead of
trying 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 Krzewski
Right 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 Krzewski
I 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 Krzewski
R.
---------------------------------------------------------------------

--
jvz.

Jason van Zyl
***@zenplex.com
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

[Colin Sampaleanu]

Post by Jason van Zyl

Post by Rafal Krzewski

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these requirements and scale
by letting the plugins deal with these different requirements instead of
trying 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 Krzewski
Right 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 Krzewski
I 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.

I completely agree with you about having plugins actually be the ones
doing their stuff with the sources. However, maven has to provide basic
facilities to plugins for dealing with source directories, and for
expressing these in the POM (in a section specific to that plugin is
fine). What feels inherently wrong about the present setup is that the
POM specifically knows about 4 different source directory types, and
stops there. It should really only know about 'source directories', and
stop there. What is done with the directories is a function of metadata
(not expressed as xml elements, as presently done) attached to those
entries, or the fact thay they are in a plugin specific section, and
various plugins which act on that. Something similar to Michal's
proposal is actually a lot cleaner than the present setup.

Regards, Colin

[Rafal Krzewski]

Post by Colin Sampaleanu

Post by Jason van Zyl

Post by Rafal Krzewski

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these requirements and scale
by letting the plugins deal with these different requirements instead of
trying 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 Krzewski
Right 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.

Adding this abstraction would allow us to remve specific support for
sourceDirectory, unitTestDirectory, integrationUnitTestDirectory
resources (i.e. jar resources), testResources and
itegrationUnitTestResources in favor of support for abstract 'sources'
(tha you process somehow) and 'resources' (that you copy someplace).
Specific 'somehows' and 'someplaces' are defined by plugins.
I think this would make core smaller & simpler.

Post by Colin Sampaleanu

Post by Jason van Zyl
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.

This made me think... Maybe the <sources> section of the POM is
completly redundant? Maven recommended project layout defines where
the sources of specific type be located. The plugin that processes that
type of sources lets you override the location through
project.properties to make mavenizing existing projects earlier,
and possibly defines a dyna-tag that lets interested parties add
more source paths if they need to. This makes sense for the java plugin,
and possibly other plugins too. Does that sound better, Jason?

Post by Colin Sampaleanu
I completely agree with you about having plugins actually be the ones
doing their stuff with the sources. However, maven has to provide basic
facilities to plugins for dealing with source directories, and for
expressing these in the POM (in a section specific to that plugin is
fine). What feels inherently wrong about the present setup is that the
POM specifically knows about 4 different source directory types, and
stops there. It should really only know about 'source directories', and
stop there. What is done with the directories is a function of metadata
(not expressed as xml elements, as presently done) attached to those
entries, or the fact thay they are in a plugin specific section, and
various plugins which act on that. Something similar to Michal's
proposal is actually a lot cleaner than the present setup.

Well, I agree fully with Collin here.

R.

[Jason van Zyl]

Post by Rafal Krzewski

Post by Jason van Zyl
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.

This made me think... Maybe the <sources> section of the POM is
completly redundant?

Yes, I've always chatted with people whether this should be completely
removed or left for 'visibility' reasons. It's not readily apparent
what's going on if those elements are removed from the POM. The idea
being making an exception for ease of comprehension.
--
jvz.

Jason van Zyl
***@zenplex.com
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

[Michal Maczka]

-----Original Message-----
Sent: Thursday, April 03, 2003 6:48 PM
To: Maven Users List
inter-projectdependencies for the Eclipse plugin )

Post by Rafal Krzewski

Post by Jason van Zyl
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

Post by Rafal Krzewski

Post by Jason van Zyl
and replaced with a place where you can define plugin

settings if they

Post by Rafal Krzewski

Post by Jason van Zyl
are required. We started this a long time ago and there was

a proposal

Post by Rafal Krzewski

Post by Jason van Zyl
that just never got implemented.

This made me think... Maybe the <sources> section of the POM is
completly redundant?

Yes, I've always chatted with people whether this should be completely
removed or left for 'visibility' reasons. It's not readily apparent
what's going on if those elements are removed from the POM. The idea
being making an exception for ease of comprehension.

Jason!

Just stupid question.

Once you mentioned that you are planning to have also other representaions
of POM and not to be limited to XML file. If I remember you have mentioned
something about keeping
a POM in a database? How does it fit into this idea?


Second question: what are you going to do then with such nontrivial things
like <sourceModifications> section. Do you see the possibility of removing
it from the POM.
Are you going to deprecate it?

Java Property files are really poor when it comes to representing a
hierarchical structure.
Do you see a possibility of having then more XML files for controlling build
process?

BTW: I think that in the POM just <dependency> section is untouchable.


I can agree that might be that we don't need <build> with all child nodes in
the POM.
But if it is going to stay I really see a place for improvements and the
ways to
making it more consistent (hence easier to document and to understand)


Michal



----------------------------------------------------------------------
Muzyczny portal INTERIA.PL >>> http://link.interia.pl/f1708

[Brian Ewins]

Post by Colin Sampaleanu
I completely agree with you about having plugins actually be the ones
doing their stuff with the sources. However, maven has to provide basic
facilities to plugins for dealing with source directories, and for
expressing these in the POM (in a section specific to that plugin is
fine). What feels inherently wrong about the present setup is that the
POM specifically knows about 4 different source directory types, and
stops there. It should really only know about 'source directories', and
stop there. What is done with the directories is a function of metadata
(not expressed as xml elements, as presently done) attached to those
entries, or the fact thay they are in a plugin specific section, and
various plugins which act on that. Something similar to Michal's
proposal is actually a lot cleaner than the present setup.

Very well put.

One other thing worth mentioning: source directories are not just source
directories. The build tools maven uses 'fan-in' source directories to
output directories, and the output directories may appear as one of the
source directories in the next stage in a pipeline. I think maven may
well be missing a something because the piplelines aren't explicit.

Maven currently describes a 'best practice' build network through goal
dependencies, but the notion of what is being passed /through/ the
network - something like ant FileSets - is missing or obscured, and each
plugin to some extent has to 'rediscover' what that data was.

Suppose maven was designed so that we could say "goal A's input is the
output of goals B, C, and D", instead of just "goal A depends on B, C,
D". <source>s would appear as input-less goals, and most plugins would
require utput path properties, not input path properties. Just a thought.

-Baz

[Michal Maczka]

-----Original Message-----
Sent: Wednesday, April 02, 2003 5:10 PM
To: Maven Users List
inter-projectdependencies for the Eclipse plugin )

Post by Rafal Krzewski

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these

requirements and scale

Post by Rafal Krzewski

Post by Jason van Zyl
by letting the plugins deal with these different requirements

instead of

Post by Rafal Krzewski

Post by Jason van Zyl
trying 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.

Jason!

I had this idae even before this discussion started.
Forget about the context in which I have presented it.

I did not mean anything else just to make POM simpler and more consisted.
I know that this idea has a side effects (e.g. places for extension)

but it is then up to you what type of sources will be allowed in POM.
Smart XML schema which allow only

<type>java</type>, <type>test</type>, <type>iutest</type>
<type>aspect</type>

et voila we are 100% compatible with current limitations
which are in POM for forcing best practices.

But POM is simpler.

Post by Rafal Krzewski
Right now many plugins rely on project.properties file
rather than POM, which I think is not right.
Of course we should always use our best judgment 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.

But look what is in POM.

What kind of information is more importand for project:

company logo, project contributors or information about project sources?

company logo, project contributors as I know are used only by one
plugin (site) and can be as well just controlled at plugin level.
As anything else which is not hierarchical set of properties as
e.g. dependencies.

But I strongly believe the sources should be 1st class citizen in the POM.

Post by Rafal Krzewski
I 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.

Look:
<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>

It is hard to make include/exclude in project.properties.
So I doubt if it will be easy switch to kick out <build> section from POM.



BTH: I had _REALLY_ no intention to have a support for multiple source
directories
for the same type of sources or to provide a cure for the problem which
disused before
in this thread and which is solvable in the way like it is ANTLR plugin.
This is different subject. Maybe even related to my proposition.
But this is definitely not an issue about which I wanted to discuss.


regards

Michal

Post by Rafal Krzewski
R.
---------------------------------------------------------------------

--
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
---------------------------------------------------------------------
----------------------------------------------------------------------
Nie chcesz wyrzucac pieniedzy w bloto?
Zapoznaj sie z ofertą nootebookow Actina,
sponsora serwisu Nowe Technologie http://nt.interia.pl/. Zapraszamy!

----------------------------------------------------------------------
KLIKNIJ 2 razy TAK >>> http://link.interia.pl/f170d

[michal.maczka]

-----Original Message-----
Sent: Wednesday, April 02, 2003 5:10 PM
To: Maven Users List
inter-projectdependencies for the Eclipse plugin )

Post by Rafal Krzewski

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these

requirements and scale

Post by Rafal Krzewski

Post by Jason van Zyl
by letting the plugins deal with these different requirements

instead of

Post by Rafal Krzewski

Post by Jason van Zyl
trying 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 Krzewski
Right 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 Krzewski
I 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 Krzewski
R.
---------------------------------------------------------------------

--
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
---------------------------------------------------------------------

[Bert van Brakel]

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 Krzewski

Post by Jason van Zyl
That is distinctly different than multiple source directories for your
application. And here we are trying satisfy these

requirements and scale

Post by Rafal Krzewski

Post by Jason van Zyl
by letting the plugins deal with these different requirements

instead of

Post by Rafal Krzewski

Post by Jason van Zyl
trying 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 Krzewski
Right 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 Krzewski
I 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 Krzewski
R.
---------------------------------------------------------------------

--
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
---------------------------------------------------------------------

---------------------------------------------------------------------

[michal.maczka]

-----Original Message-----
Sent: Thursday, April 24, 2003 5:40 AM
To: Maven Developers List; Maven Users List
Subject: RE: Why no multiple locations of sources? - proposal
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
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.
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.

Well. You can always do things which will destroy your sources
and nothing can stop you from doing that.

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.

[..]


I am personally for changing a bit the situation of sources (I described my
idea some times ago)
But I am also for simplicity and I think that what you are proposing
is too complicated and I see easier ways to go.

Once we will be able to have artifacts like "java sources", "javadocs" etc,
(it's my wishful thinking) you will be able to explicitly express such
things using
dependencies. If we have a way of defining the artifact handlers for
different type
of artifacts + give a way to extend it ... this in my opinion will be much
better.
I really think that components/project should exchange information
through artifacts/dependicies/repositories and should not use other projects
sources directly.

regards

Michal

[Konstantin Priblouda]

Post by Bert van Brakel

Post by Bert van Brakel
2.1.a) to put auto generated code in a different

directory than the hand

Post by Bert van Brakel
written stuff, which took us hours to write and we

don't want to

Post by Bert van Brakel
accidently lose it.

If you look at xdoclet module, you will see that it
places generated code outside of main source tree...

so this is possible with current maven behaviour...

regards,

=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >

__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com

[Bert van Brakel]

Post by Konstantin Priblouda

Post by Bert van Brakel

Post by Bert van Brakel
2.1.a) to put auto generated code in a different

directory than the hand

Post by Bert van Brakel
written stuff, which took us hours to write and we

don't want to

Post by Bert van Brakel
accidently lose it.

If you look at xdoclet module, you will see that it
places generated code outside of main source tree...
so this is possible with current maven behaviour...

sure, not saying it's not. It's all about how easy it is. Do we have to
mangle maven to do what we want, or decide that since people are
violating 'maven guidelines' anyway, we allow them to atleast do it in
as tidy a manner as possible?.


-Bert

Post by Konstantin Priblouda
regards,
=====
Konstantin Priblouda ( ko5tik ) Freelance Software developer
< http://www.pribluda.de > < play java games -> http://www.yook.de >
< render charts online -> http://www.pribluda.de/povray/ >
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
---------------------------------------------------------------------

--
Bert van Brakel
IT/Programming/Webdesign

AEL IT Ltd
Unit 1, 5 Tanner St
Woolston Industrial Estate
PO Box 4658, Christchurch
Phone: [phone] (ext 703)
Fax: [phone]
Mobile: [phone]
www.aeldirect.com
Accounting | Finance | Marketing | Property | Webdesign

[Rafal Krzewski]

Post by michal.maczka

Post by Bert van Brakel
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.

Well. You can always do things which will destroy your sources
and nothing can stop you from doing that.

You could also try using CVS ;-)

Post by michal.maczka

Post by Bert van Brakel
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.

Maybe, maybe not. Some projects may be even messed up so much that it's
easier to start everthing over with well defined structure than try to
glue all the stuff together.

Post by michal.maczka

Post by Bert van Brakel
2.1.c) seperate 'demo code' or 'code examples' from the main production
code. ditto above.

Reactored subprojects are the Maven way of solving this problem.

Post by michal.maczka

Post by Bert van Brakel
2.1.d) be really cool if a derived source could include a master source
location from another project.

This kind of inter-project binding is useful in an IDE (BTW. I *love*
Eclipse auto-building feature), but for ordinary builds (distributions/
nightlies/continuous integration) I don't think it's a good idea.

Post by michal.maczka
I am personally for changing a bit the situation of sources (I described my
idea some times ago)
But I am also for simplicity and I think that what you are proposing
is too complicated and I see easier ways to go.

Ditto.

Post by michal.maczka
Once we will be able to have artifacts like "java sources", "javadocs" etc,
(it's my wishful thinking) you will be able to explicitly express such
things using
dependencies. If we have a way of defining the artifact handlers for
different type
of artifacts + give a way to extend it ... this in my opinion will be much
better.
I really think that components/project should exchange information
through artifacts/dependicies/repositories and should not use other projects
sources directly.

I really like your way of thinking. It's very much along my own thoughts
on the issue. I'm looking forward to your work in this area for
maven-new!

R.

[Bert van Brakel]

Post by Rafal Krzewski

Post by michal.maczka

Post by Bert van Brakel
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.

Well. You can always do things which will destroy your sources
and nothing can stop you from doing that.

You could also try using CVS ;-)

already do, just don't want to have to update to cvs before running a
tool. The safer the better.

Post by Rafal Krzewski

Post by michal.maczka

Post by Bert van Brakel
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.

Maybe, maybe not. Some projects may be even messed up so much that it's
easier to start everthing over with well defined structure than try to
glue all the stuff together.

I agree, but in some cases it's designed like that for a reason. Can you
anticipate all project scenarios? Better have a flexible tool which can
handle the most number of scenarios (traded ofcourse against complexity)
and enforce *configureable* guidelines (ie project leads decide), than
to have these constraints programmatically hardcoded.

Post by Rafal Krzewski

Post by michal.maczka

Post by Bert van Brakel
2.1.c) seperate 'demo code' or 'code examples' from the main production
code. ditto above.

Reactored subprojects are the Maven way of solving this problem.

Sure, many problems can be solved this way but should we be forced into
a particular solution becasue of our tools?. Tools are to do our
bidding, not the other way round. Sometimes things don't fit into the
little boxes we would like . The only constant is change, and to force
yourself into a solution which seems right now doesn't mean it'll be
right tommorow when something comes along which is slightly out of the
ordinary. If we can't use our tools to cope with them, then in my
opinion that's a pretty poor tool

Post by Rafal Krzewski

Post by michal.maczka

Post by Bert van Brakel
2.1.d) be really cool if a derived source could include a master source
location from another project.

This kind of inter-project binding is useful in an IDE (BTW. I *love*
Eclipse auto-building feature), but for ordinary builds (distributions/
nightlies/continuous integration) I don't think it's a good idea.

thinking about it some more I agree with you. That was a bad idea. sorry
:)

... however it does allow maven to download a dependencies source code
into another folder, setup your ide environment and you're away
laughing. I guess though that's getting outside the scope of mavens
goals. But hey, what tool is used only for the purpose it was supposed
to? A good tool is flexible to work outside the box.

Post by Rafal Krzewski

Post by michal.maczka
I am personally for changing a bit the situation of sources (I described my
idea some times ago)
But I am also for simplicity and I think that what you are proposing
is too complicated and I see easier ways to go.

Ditto.

Not sure if I entirely agree. It's similiar to your proposed artifact
idea. The master source are like the input to the artifact handlers
(resource repo's), the derived sources are the generated artifact, the
compilation plugin which generates the derived sources is like your
artifact handler. One difference is that I was thinking of using one
compilation plugin to generate all the derived sources ('artifacts'),
you are proposing a seperate one for each. I see your approach is even
more flexible but I think also *more* complicated, but also more inline
with the rest of the maven design patterns.

Post by Rafal Krzewski

Post by michal.maczka
Once we will be able to have artifacts like "java sources", "javadocs" etc,
(it's my wishful thinking) you will be able to explicitly express such
things using
dependencies. If we have a way of defining the artifact handlers for
different type
of artifacts + give a way to extend it ... this in my opinion will be much
better.
I really think that components/project should exchange information
through artifacts/dependicies/repositories and should not use other projects
sources directly.

I really like your way of thinking. It's very much along my own thoughts
on the issue. I'm looking forward to your work in this area for
maven-new!

ditto on that! instead of specifying goals which are the 'how', we
should specify the 'what'. So we say "to do this I need 'this'" and
maven works out how to get the 'this'.

Guess it's like going to the shop. You say 'I need a such and such'.
They then run all their 'goals'
(charge,order,package,ship,unpack,deliver) and give you your 'need'. You
don't say, I need you to run your charge,order,package... processes. You
don't know about them, and they change from shop to shop.


cool

-Bert

Post by Rafal Krzewski
R.
---------------------------------------------------------------------

[Rafal Krzewski]

Post by Bert van Brakel

Post by Rafal Krzewski

Post by Bert van Brakel
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.

Maybe, maybe not. Some projects may be even messed up so much that it's
easier to start everthing over with well defined structure than try to
glue all the stuff together.

I agree, but in some cases it's designed like that for a reason. Can you
anticipate all project scenarios? Better have a flexible tool which can
handle the most number of scenarios (traded ofcourse against complexity)
and enforce *configureable* guidelines (ie project leads decide), than
to have these constraints programmatically hardcoded.

Well, Maven project's ambition is providing guidelines for software
projects development. The existing guidelines may not be well suited
for a range of projects. In this situation, we should work on creating
better guidelines, and then improve the tools to support these, not
alter existing tools to work outside existing guidelines. These are
two distinct paths to reaching one point -- that Maven does what you
want, but I think that if you follow the first one, more people can
benefit from that, and as a side effect you mach change your opinion
on 'what you want' too :-)

Post by Bert van Brakel
Sure, many problems can be solved this way but should we be forced into
a particular solution becasue of our tools?. Tools are to do our
bidding, not the other way round. Sometimes things don't fit into the
little boxes we would like . The only constant is change, and to force
yourself into a solution which seems right now doesn't mean it'll be
right tommorow when something comes along which is slightly out of the
ordinary. If we can't use our tools to cope with them, then in my
opinion that's a pretty poor tool

True, but you must decide for a solution, right? And you don't know if it
will work for you in the future no matter how good it looks today?
Both rigid and flexible guidelines have their advantages, and finding
a balance is the most challenging part of the work.
In a some sense, rigid guidelines force you to solve design problems
before they can bite you, flexible gidelines allow you move on after
you get bitten.

Post by Bert van Brakel
... however it does allow maven to download a dependencies source code
into another folder, setup your ide environment and you're away
laughing. I guess though that's getting outside the scope of mavens
goals. But hey, what tool is used only for the purpose it was supposed
to? A good tool is flexible to work outside the box.

When POMs are deployed into the repository, this will be trivial to do
maven -Dpull.project=org.apache.commons/jelly-core
-Dpull.dir=./jelly-core pull
And the yet-to-be written pull plugin will download the POM, and use
the sourceRepository property to checkout the project into the given
directory.

Post by Bert van Brakel
Not sure if I entirely agree. It's similiar to your proposed artifact
idea. The master source are like the input to the artifact handlers
(resource repo's), the derived sources are the generated artifact, the
compilation plugin which generates the derived sources is like your
artifact handler. One difference is that I was thinking of using one
compilation plugin to generate all the derived sources ('artifacts'),
you are proposing a seperate one for each. I see your approach is even
more flexible but I think also *more* complicated, but also more inline
with the rest of the maven design patterns.

It is more complex, and it requires changes in the infrastructure, but
it's modular and easily extensible. I don't like the idea of a bulky
monolythic compilation plugin that routes stuff around. It's also
aligned better with existing patters.

Post by Bert van Brakel
ditto on that! instead of specifying goals which are the 'how', we
should specify the 'what'. So we say "to do this I need 'this'" and
maven works out how to get the 'this'.
Guess it's like going to the shop. You say 'I need a such and such'.
They then run all their 'goals'
(charge,order,package,ship,unpack,deliver) and give you your 'need'.
You don't say, I need you to run your charge,order,package...
processes. You don't know about them, and they change from shop to
shop.

It sounds exactly like the way unix make works! You generally ask it
to make a target, which may be either a file (->artifact) or a 'dummy'
target. Makefiles are recipes for generating specific targets, or
meta recipes for generating one kind of file from another.
You can sort of align it to what Maven does, but it's not very clear.
I think that we could leverage better on 20+ years of make experience...

R.

[Bert van Brakel]

Guess I'll wait and see if the artifact stuff gets included and see how
that pans out. I'll stick to my wish for multiple source locations as I
see a need for it. If down the track someone successfully convinces me
of the error of my ways I *may* change my mind if I haven't turned into
a stubborn fool by then :)

-Bert

Post by Rafal Krzewski

Post by Bert van Brakel

Post by Rafal Krzewski

Post by Bert van Brakel
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.

Maybe, maybe not. Some projects may be even messed up so much that it's
easier to start everthing over with well defined structure than try to
glue all the stuff together.

I agree, but in some cases it's designed like that for a reason. Can you
anticipate all project scenarios? Better have a flexible tool which can
handle the most number of scenarios (traded ofcourse against complexity)
and enforce *configureable* guidelines (ie project leads decide), than
to have these constraints programmatically hardcoded.

Well, Maven project's ambition is providing guidelines for software
projects development. The existing guidelines may not be well suited
for a range of projects. In this situation, we should work on creating
better guidelines, and then improve the tools to support these, not
alter existing tools to work outside existing guidelines. These are
two distinct paths to reaching one point -- that Maven does what you
want, but I think that if you follow the first one, more people can
benefit from that, and as a side effect you mach change your opinion
on 'what you want' too :-)

Post by Bert van Brakel
Sure, many problems can be solved this way but should we be forced into
a particular solution becasue of our tools?. Tools are to do our
bidding, not the other way round. Sometimes things don't fit into the
little boxes we would like . The only constant is change, and to force
yourself into a solution which seems right now doesn't mean it'll be
right tommorow when something comes along which is slightly out of the
ordinary. If we can't use our tools to cope with them, then in my
opinion that's a pretty poor tool

True, but you must decide for a solution, right? And you don't know if it
will work for you in the future no matter how good it looks today?
Both rigid and flexible guidelines have their advantages, and finding
a balance is the most challenging part of the work.
In a some sense, rigid guidelines force you to solve design problems
before they can bite you, flexible gidelines allow you move on after
you get bitten.

Post by Bert van Brakel
... however it does allow maven to download a dependencies source code
into another folder, setup your ide environment and you're away
laughing. I guess though that's getting outside the scope of mavens
goals. But hey, what tool is used only for the purpose it was supposed
to? A good tool is flexible to work outside the box.

When POMs are deployed into the repository, this will be trivial to do
maven -Dpull.project=org.apache.commons/jelly-core
-Dpull.dir=./jelly-core pull
And the yet-to-be written pull plugin will download the POM, and use
the sourceRepository property to checkout the project into the given
directory.

Post by Bert van Brakel
Not sure if I entirely agree. It's similiar to your proposed artifact
idea. The master source are like the input to the artifact handlers
(resource repo's), the derived sources are the generated artifact, the
compilation plugin which generates the derived sources is like your
artifact handler. One difference is that I was thinking of using one
compilation plugin to generate all the derived sources ('artifacts'),
you are proposing a seperate one for each. I see your approach is even
more flexible but I think also *more* complicated, but also more inline
with the rest of the maven design patterns.

It is more complex, and it requires changes in the infrastructure, but
it's modular and easily extensible. I don't like the idea of a bulky
monolythic compilation plugin that routes stuff around. It's also
aligned better with existing patters.

Post by Bert van Brakel
ditto on that! instead of specifying goals which are the 'how', we
should specify the 'what'. So we say "to do this I need 'this'" and
maven works out how to get the 'this'.
Guess it's like going to the shop. You say 'I need a such and such'.
They then run all their 'goals'
(charge,order,package,ship,unpack,deliver) and give you your 'need'.
You don't say, I need you to run your charge,order,package...
processes. You don't know about them, and they change from shop to
shop.

It sounds exactly like the way unix make works! You generally ask it
to make a target, which may be either a file (->artifact) or a 'dummy'
target. Makefiles are recipes for generating specific targets, or
meta recipes for generating one kind of file from another.
You can sort of align it to what Maven does, but it's not very clear.
I think that we could leverage better on 20+ years of make experience...
R.
---------------------------------------------------------------------

--
Bert van Brakel
IT/Programming/Webdesign

AEL IT Ltd
Unit 1, 5 Tanner St
Woolston Industrial Estate
PO Box 4658, Christchurch
Phone: [phone] (ext 703)
Fax: [phone]
Mobile: [phone]
www.aeldirect.com
Accounting | Finance | Marketing | Property | Webdesign

[michal.maczka]

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 to have:

<source>
<type>java</type>
<path>src/java</path>
</source>

<source>
<type>iutest</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/ascpectj</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 more open and consistent then
current XML structure of POM.





Michal

P.S.

Sorry if I sent this email twice, but my previous message did not appear in
mailing list after two hours..

-----Original Message-----
Sent: Wednesday, April 02, 2003 6:23 AM
To: Maven Users List
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?

Post by Jeffrey D. Brekke

Post by Colin Sampaleanu

Post by Jason van Zyl

On Tue, 01 Apr 2003 13:20:56 -0500, Colin Sampaleanu

{SNIP]

Post by Colin Sampaleanu

Post by Jason van Zyl
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.

---------------------------------------------------------------------

[D***@emc.com]

Post by Brian Ewins
Suppose maven was designed so that we could say "goal A's
input is the output of goals B, C, and D", instead of just "goal
A depends on B, C, D". <source>s would appear as input-less
goals, and most plugins would require output path properties,
not input path properties. Just a thought.

Make it a bit more explicit. A pipeline is not always a straight line, but
can have a junction. Take AspectJ for example: it has two inputs and one
output. The inputs are the sources and the aspects and the output is the
folder with the aspects woven in the sources. Define for every plugin the
inputs and the outputs, document a standard location, but give the
opportunity to override these. For the rest, nothing but applause for the
pipeline proposal.

Ringo

[Michal Maczka]

-----Original Message-----
Sent: Thursday, April 03, 2003 3:52 PM
inter-project dependencies for the Eclipse plugin )

Post by Brian Ewins
Suppose maven was designed so that we could say "goal A's
input is the output of goals B, C, and D", instead of just "goal
A depends on B, C, D". <source>s would appear as input-less
goals, and most plugins would require output path properties,
not input path properties. Just a thought.

Make it a bit more explicit. A pipeline is not always a straight line, but
can have a junction. Take AspectJ for example: it has two inputs and one
output. The inputs are the sources and the aspects and the output is the
folder with the aspects woven in the sources. Define for every plugin the
inputs and the outputs, document a standard location, but give the
opportunity to override these. For the rest, nothing but applause for the
pipeline proposal.
Ringo

I think that this is already covered in Maven and not much more should be
done

But there are even worst cases when pipelining is useless.

E.g. consider following use case

1) First run of Maven :
I start XDoclet it creates some classes and updates java path for the rest
of plugins (e.g. javac)

2) Second/Third etc.. run of Maven
I don't want to regenerate one more time XDoclet stuff .. but I want to have
the source previously generated visible in my path.


The only way it can be handled properly is to make it on plugin level.
So plugins like XDoclet should be equipped with some hooks for making such
things
and hide some details into which directories they will put their sources.


Michal








----------------------------------------------------------------------
Pilkarski portal INTERIA.PL >>> http://link.interia.pl/f1703

[Brian Ewins]

Post by Michal Maczka
But there are even worst cases when pipelining is useless.
E.g. consider following use case
I start XDoclet it creates some classes and updates java path for the rest
of plugins (e.g. javac)
2) Second/Third etc.. run of Maven
I don't want to regenerate one more time XDoclet stuff .. but I want to have
the source previously generated visible in my path.

That would be handled exactly as it is now, I'm not sure I see your
point? i.e., each plugin in a pipeline invokes its dependents, which end
up doing nothing because their output already exists? The pipeline is
not passing the file contents (I guess this might be what you're
thinking?), only data structures (eg FileSets) which allow you to get
access to the files.

Post by Michal Maczka
The only way it can be handled properly is to make it on plugin level.
So plugins like XDoclet should be equipped with some hooks for making such
things
and hide some details into which directories they will put their sources.

All I am suggesting is that saying 'goal A depends on goal B' generally
means 'goal A depends on the /output of/ goal B'. At the moment, B knows
where its output went, but A is just guessing. So we require A to have
knowledge of how B works in order to get hold of B's data. That hides
/less/ about which directories B uses than my suggestion.

The 'official' way to deal with code generators is to chuck their output
into the 'global list of sources'. Are we suggesting global variables
are a good thing? Also, this mechanism only deals with .java files -
there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
can also be seen as inverting the problem in the previous para - now B
knows how A works and is pushing its data at A)

There also seems to be a clash with the Inversion of Control
principle[1] here: either A is pulling data from B, or B is pushing data
at A (or equivalently, A pulls from a global, B pushes to a global). It
should be the framework telling A what files to process, which happens
to include the output of B because the current 'flow' declares that
dependency.

To some extent I'm echoing Bob McWhirter here, and suggesting that
"everything is workflow"[2] - including maven.

-Baz

[1] http://avalon.apache.org/framework/guide-patterns-ioc.html
[2] http://blogs.werken.com/people/bob/archives/000160.html

[michal.maczka]

-----Original Message-----
Sent: Friday, April 04, 2003 11:36 AM
To: Maven Users List
inter-project dependencies for the Eclipse plugin )

Post by Michal Maczka
But there are even worst cases when pipelining is useless.
E.g. consider following use case
I start XDoclet it creates some classes and updates java path

for the rest

Post by Michal Maczka
of plugins (e.g. javac)
2) Second/Third etc.. run of Maven
I don't want to regenerate one more time XDoclet stuff .. but I

want to have

Post by Michal Maczka
the source previously generated visible in my path.

That would be handled exactly as it is now, I'm not sure I see your
point? i.e., each plugin in a pipeline invokes its dependents, which end
up doing nothing because their output already exists? The pipeline is
not passing the file contents (I guess this might be what you're
thinking?), only data structures (eg FileSets) which allow you to get
access to the files.

Yeap you right.
And I guess that I am right too ... becouse I believe that,
we alredy have a workflow of goals in Maven.

The problem I see is that Maven is in a big part implemented in scripting
language.
This is hugh adavatange for a lot of things,
but this is also is a cause of many weeknesess of Maven.
You want to have goals which are formaly declaring what thay return/modify
etc.
I think that such things are getting too be to complicated to be really
maintanable.

Post by Michal Maczka
The only way it can be handled properly is to make it on plugin level.
So plugins like XDoclet should be equipped with some hooks for

making such

Post by Michal Maczka
things
and hide some details into which directories they will put

their sources.
All I am suggesting is that saying 'goal A depends on goal B' generally
means 'goal A depends on the /output of/ goal B'. At the moment, B knows
where its output went, but A is just guessing. So we require A to have
knowledge of how B works in order to get hold of B's data. That hides
/less/ about which directories B uses than my suggestion.

so basically B should not update the path.

and in A (when needed)you should use something like:

B:getUpatedOutputPath()

which will "black-box" what B does to the output

The 'official' way to deal with code generators is to chuck their output
into the 'global list of sources'. Are we suggesting global variables
are a good thing?
Also, this mechanism only deals with .java files -
there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
can also be seen as inverting the problem in the previous para - now B
knows how A works and is pushing its data at A)

There are always some global variables. E.g worflow information are globals

I think that you are just speaking about making the same sort of things in
a diferent
way - e.g through more formal set of APIs.

But I think that those things really are alredy in Maven!
My idea of reorganizing the sources' meta information was aiming at exactly
the same
goal: unification of the workflow.
It is usually easier to work with one common abstraction then with couple
simmilar things (like now we have 4 types of different sources, javaclass
path
and probably other things)

There also seems to be a clash with the Inversion of Control
principle[1] here: either A is pulling data from B, or B is pushing data
at A (or equivalently, A pulls from a global, B pushes to a global). It
should be the framework telling A what files to process, which happens
to include the output of B because the current 'flow' declares that
dependency.
To some extent I'm echoing Bob McWhirter here, and suggesting that
"everything is workflow"[2] - including maven.
-Baz

Cool sentence!

regards (also to Bob!)

Michal

[Brian Ewins]

Post by michal.maczka
Yeap you right.
And I guess that I am right too ... becouse I believe that,
we alredy have a workflow of goals in Maven.

Yup, I agree.

Post by michal.maczka
so basically B should not update the path.
B:getUpatedOutputPath()
which will "black-box" what B does to the output

Well, yes and no. This means that A /explicitly/ knows that it depends
on B (which is where we are at now). I mean something more like, A does
not know it depends on B, the framework does. The framework takes care
of adding the output of B to the input of A.

This might sound like I'm suggesting a central file which describes the
dependency of A on B - I'm not, I see the plugin.jelly as declaring two
things - the processes for each goal, and the default connections
between goals. So you can override the inputs, outputs (ie dependencies)
without overriding the goal processing - this is pretty much what
pregoal and postgoals do now.

This is partly my answer to Rafal as well - I mention 'the framework'
above and mean pretty much the same as you do when talking about 'the
session'. The difference is you're describing a passive session
manipulated by the goals (roughly speaking - when they lookup/store
data), I'm describing passive goals manipulated by the framework.

I totally agree with both of you that most of this is already there.

Anyway - if Jason had a penny for every time someone argued for changing
how maven works....he'd say, "here's your penny back, give me a patch
instead". I'll shut up.

-Baz

[Rafal Krzewski]

Post by Brian Ewins
The 'official' way to deal with code generators is to chuck their output
into the 'global list of sources'. Are we suggesting global variables
are a good thing? Also, this mechanism only deals with .java files -
there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
can also be seen as inverting the problem in the previous para - now B
knows how A works and is pushing its data at A)

Instead of 'global' think about 'valid during a session'. Suppose you
have Maven embedded in an IDE, with your project loaded and all goal
dependency information in place. You click a toolbar icon that invokes
a pre-configured goal on the current project. This starts a new Maven
session for your project. Maven uses the loaded goal dependency
information to build of a graph of goals that need to be attained to
achieve the goal you requested. Then the order in which the goals will
be attained is computed (with the possible outcome of cirular dependency
error message). At this point we have a pipeline formed. The goals that
run at the beginning of the pipeline are usually producers of ... well,
let's call'em 'interim artifacts'. For example, 'java:init' goal would
check for existence of ${basedir}/src/java, and if it's present, would
create a FileSet interim artifact named 'java.source.set' and pass it
down the pipeline. How would that be done? The object would be injected
into the Maven session context. How further elements of the pipeline
know where to look for that interim artifact? The key in the session
context is a part of public API of the plugin that produces it.

I think that most, if not all of the infrastructure needed to implement
that kind of pipelining operation is already present in Maven. All we
need is defining that this is how things should be done, and documenting
the contracts of all plugins -- what 'interim artifacts' they produce
and consume.

Post by Brian Ewins
There also seems to be a clash with the Inversion of Control
principle[1] here: either A is pulling data from B, or B is pushing data
at A (or equivalently, A pulls from a global, B pushes to a global). It
should be the framework telling A what files to process, which happens
to include the output of B because the current 'flow' declares that
dependency.

I'm no expert at the theory behind frameworks, but what I've described
above seems reasonably well strucured to me. A and B need to agree on
a contract (names of the passed artifacts) and the framework does the
storage/lookup for them.

R.

[michal.maczka]

-----Original Message-----
Sent: Friday, April 04, 2003 1:37 PM
To: Maven Users List
inter-project dependencies for the Eclipse plugin )

Post by Brian Ewins
The 'official' way to deal with code generators is to chuck their output
into the 'global list of sources'. Are we suggesting global variables
are a good thing? Also, this mechanism only deals with .java files -
there is no equivalent fat pipe for documentation etc AFAIK. (BTW this
can also be seen as inverting the problem in the previous para - now B
knows how A works and is pushing its data at A)

Instead of 'global' think about 'valid during a session'. Suppose you
have Maven embedded in an IDE, with your project loaded and all goal
dependency information in place. You click a toolbar icon that invokes
a pre-configured goal on the current project. This starts a new Maven
session for your project. Maven uses the loaded goal dependency
information to build of a graph of goals that need to be attained to
achieve the goal you requested. Then the order in which the goals will
be attained is computed (with the possible outcome of cirular dependency
error message). At this point we have a pipeline formed. The goals that
run at the beginning of the pipeline are usually producers of ... well,
let's call'em 'interim artifacts'. For example, 'java:init' goal would
check for existence of ${basedir}/src/java, and if it's present, would
create a FileSet interim artifact named 'java.source.set' and pass it
down the pipeline. How would that be done? The object would be injected
into the Maven session context. How further elements of the pipeline
know where to look for that interim artifact? The key in the session
context is a part of public API of the plugin that produces it.
I think that most, if not all of the infrastructure needed to implement
that kind of pipelining operation is already present in Maven. All we
need is defining that this is how things should be done, and documenting
the contracts of all plugins -- what 'interim artifacts' they produce
and consume.

Do you think that such things should be legal then?

I have in my POM:

<projetct>
<id>my_stupid_question</id>
<version>1.0</version>
..
<dependency>
<groupId>my_stupid_question</groupId>
<artifactId>my_stupid_question<</artifactId>
<version>${pom.version}</version>
<properties>
<ear.bundle>true</ear.bundle>
</properties>
<type>war</type>
</dependency>
<dependecy>

..
</project>


I type "maven ear" and war pluging is invoked first in order to deliver
needed artifact:
my_stupid_question-1.0.war

So I mean a sort of "inner" reactor.

Such things would be nice but f... complex.

greets

Michal

[Bert van Brakel]

my apologies...

-bert

Please don't crosspost to the dev & user lists. Many people are
subscribed to both, and they'll get your message twice.
Regards,
R.