> Now, in an amazing magic trick, I'll contradict myself! :)
>
> <contradiction>
> The only potential problem I see is the case where two
> generation tools expect pristine, untweaked sources...then,
> you have a sort of pseudo race condition, where success
> dependends upon the ordering of generator execution...
> </contradiction>
This is the general problem with trying to model generated sources. We have
a project that 1) uses xDoclet to build source, then 2) uses xDoclet to
build more source from the source just generated. It's actually a little
more complicated than that. And it's crazy too.
I also worked on another project where we generated simple source code and I
got around this problem by writing a custom maven goal that generates java
source directly into <sourceDirectory>. Then I wrote another custom maven
goal (a clean preGoal) that deletes that generated source from the
<sourceDirectory>. This works for me, and any concerns about accidently
checking in generated source code into SCM didn't pan out.
The more I develop software I think multiple source directories add needless
complexity but in some cases it's just too hard not to avoid.
What about specifying <sourceDirectory> as a fileset? This would add a lot
more work to retrofit plugins but it really would give developers good
flexibility.
<sourceDirectory>
<include name="dir1" />
<include name="dir2" />
<include name="dir3" />
</sourceDirectory>
As a digression from this thread I think developers, on average, introduce
complexity by building cool things into their software projects. They don't
necessarily take the easiest, simpliest path from A to B. Maven (in some
form or fashion) discourages complex build layouts and strategies and I
think that leads to 1) a greater understanding of how software projects are
structured, 2) increased knowledge communication between developers, project
managers, and business analysts and 3) higher software quality because
developers overall better understand the very nature of what they are doing.
> -john
>
> On Thu, 2004-01-08 at 16:38, Jason van Zyl wrote:
> > On Thu, 2004-01-08 at 16:25, John Casey wrote:
> > > <2cents>
> > > One easy way to get around this duality between single-source and
> > > multiple source directories would be to stage out the
> java sources
> > > to some temporary location under ${basedir}/target for subsequent
> > > generation (back into that same directory) prior to java:compile
> > > execution. Then, these generation tools would look in the
> > > ${basedir}/target/staged-source directory for their
> input, and would
> > > output to the same directory...maybe all in a preGoal of
> > > java:compile or something...
> > >
> > > </2cents>
> >
> > Do you think that could be a standard? Something we could
> add to the
> > POM? I think it might be useful ...
> >
> > <build>
> > <generateSourcesDirectory/>
> > </build>
> >
> > Something all the tools like Antlr, JavaCC, XDoclet, etc. could use.
> >
> > > -john
> > >
> > > On Thu, 2004-01-08 at 14:32, Michal Maczka wrote:
> > > > > -----Original Message-----
> > > > > From: [EMAIL PROTECTED]
> > > > > [mailto:[EMAIL PROTECTED]
> > > > > Sent: Thursday, January 08, 2004 9:43 AM
> > > > > To: 'Maven Users List'
> > > > > Subject: Mutliple source directories in project.xml
> > > > >
> > > > >
> > > > > Hi all
> > > > >
> > > > > I've seen that there has been a discussion regarding
> this before
> > > > > (at least on the mailing list).
> > > > >
> > > > > I gather one can circumvent this by modifying the appropriate
> > > > > property/variable in a preGoal (like
> maven.compile.src.set), but
> > > > > that would add to the maintenance workload and really
> > > > > it'd just be a hack.
> > > > >
> > > > > So my question is; will support for multiple source
> directories
> > > > > in the POM ever be incuded, or
> > > > > is it absolutely out of the question?
> > > > >
> > > >
> > > > Chances for that are very low!
> > > >
> > > >
> > > > [off topic]
> > > > In reality there is quite often more than one java
> source directory.
> > > > Recently I have a "pleasure" to work with a few tools
> which are generating
> > > > java code (e.g. javacc).
> > > > I can perfectly understand the frustration of people
> trying to do the same
> > > > thing and knowing maven worst then me.
> > > >
> > > > Even if generated source become visible for java
> compiler plugin, javadoc
> > > > plugin is not seeing them.
> > > > ( it uses <ant:fileset dir="${pom.build.sourceDirectory}">)
> > > >
> > > > I think we can do and we should do something to make
> those things simpler.
> > > >
> > > > Most of plugins which are generating java source like
> antlr, xdoclet,
> > > > hibernate are changing ant classpath which is processed
> by java:compile
> > > > goal.
> > > > I think that this strategy is not perfect as it's
> breaks encapsulation of
> > > > plugins and exposes their implementation details.
> > > > Such process should be based on some simple contracts
> which give a freedom
> > > > how plugins are implemented (e.g. ant should not be
> necessary for
> > > > javac:compile goal)
> > > > The solution could be very simple: every "source
> generator" can put its
> > > > files into the well known place
> > > > (e.g. target/generated/java ). then javac, javadoc and
> whatever else can do
> > > > simple check if such directory exists and behave appropriately.
> > > >
> > > > Generally every tool is placing its files in almost
> random place in "target"
> > > > directory. It will be nice to changes this "black hole"
> into something more
> > > > structured.
> > > >
> > > > For example repository plugin is supporting only jars
> at the moment. I know
> > > > it's brand new but it's very painful to make it more
> generic (if at all
> > > > possible)
> > > > I imagine that in future it should be possible to (that
> is what repository
> > > > plugin will need)
> > > >
> > > > a) build a main project artifact (consulting) <type>
> property of POM
> > > > b) know where it was stored (no artifact should be put
> to local repository
> > > > during process).
> > > > At the moment this is quite painful even for such basic
> use case.
> > > >
> > > > For that we can probably mimic the layout of local
> repository per project.
> > > > And there is so many other places where standardization
> will make many
> > > > things simpler.
> > > >
> > > >
> > > >
> > > >
> > > > Michal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
