Brian Ewins wrote:
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.
michal.maczka wrote:
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.
so basically B should not update the path.
and in A (when needed)you should use something like:
B:getUpatedOutputPath()
which will
Colin Sampaleanu wrote:
Jason van Zyl wrote:
On Wed, 2003-04-02 at 09:05, Rafal Krzewski wrote:
Jason van Zyl wrote:
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
Colin Sampaleanu wrote:
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
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 03, 2003 6:48 PM
To: Maven Users List
Subject: Re: Why no multiple locations of sources? ( was Re:
inter-projectdependencies for the Eclipse plugin )
On Thu, 2003-04-03 at 04:16, Rafal
On Wed, 2003-04-02 at 03:57, [EMAIL PROTECTED] wrote:
Ben,
So to Colin (I think)
I'm not Colin, but I will try to explain the situation I'm in.
Why do you have multiple source trees?
What is in them?
1) src/java: production source code
2) src/junit: unit test code: component
On Wed, 2003-04-02 at 09:05, Rafal Krzewski wrote:
Jason van Zyl wrote:
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
