On Thu, 2004-01-08 at 16:42, John Casey wrote:
> 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>
The pre/post goals are executed in the order they are registered so
would this really be a problem?
> -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]
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
