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