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