Maybe if we understood the "why" of multiple trees, we would be better
able to describe the "why not" and the "how to work without them"
So to Colin (I think)
Why do you have multiple source trees?
What is in them?
Do they build distinct artifacts?
Would other disparate projects have a requireme
On Wed, 2003-04-02 at 03:02, Raphaël Piéroni wrote:
> Hello maven devs and users,
>
> i dunno why splitting a source tree but as said before maven at the
> moment as multiple trees : one for tests, one for java, one for
> aspects.
The one for aspects will more than likely be removed and be made t
michal.maczka wrote:
> won't it be simple just to have:
>
>
>java
>src/java
>
>
>
>cactus
>src/cactus
>
>
>
>test
>src/test/java
>
> **/*Test.java
>
>
> **/RepositoryTest.java
> **/JAXPTest.java
>
>
>
>
>aspect
>sr
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: c
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
> trying to jam everything into the POM.
I believe th
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 inst
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 deal with these different requirem
> -Original Message-
> From: Jason van Zyl [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 02, 2003 5:10 PM
> To: Maven Users List
> Subject: Re: Why no multiple locations of sources? ( was Re:
> inter-projectdependencies for the Eclipse plugin )
>
>
>
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
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 plug
On Thu, 2003-04-03 at 04:16, Rafal Krzewski wrote:
> Colin Sampaleanu wrote:
> >> I'm not really in favour of this and much prefer the way the antlr
> >> plugin works. I would like to see most of the element removed
> >> and replaced with a place where you can define plugin settings if they
> >>
> -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 )
>
>
>
Michal Maczka wrote:
But there are even worst cases when pipelining is useless.
E.g. consider following use case
1) First run of Maven :
I start XDoclet it creates some classes and updates java path for the rest
of plugins (e.g. javac)
2) Second/Third etc.. run of Maven
I don't want to regenerate
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 "black-
15 matches
Mail list logo
