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 deal with these different requirements
>>>> instead of
>>>> trying to jam everything into the POM.
>>>>     
>>>
>>> I believe that the POM is the proper place for defining what goes in
>>> your project. Plugins should retrieve information from there and proceed
>>> with their work.   
>>
>> I've pondered this many a time. I really do not like the idea of having
>> to augment your POM when you choose to use a plugin. I very much like
>> the way the antlr plugin works in that it just kicks in when certain
>> resources are present.
>>
>>> Right now many plugins rely on project.properties file
>>> rather than POM, wich I think is not right.
>>> Of course we should always use our best judgement to avoid cluttering
>>> the POM, but I thing that the source directories (java, aspect, unit
>>> test, and others that arise) are crucial for defining the project, and
>>> therefore they should be in the POM.
>>>
>>> I really like Michal's proposal with sources/source/type elements.
>>> It puts the emphasis on the plugins undestating a specific type of
>>> sources, and allows us remove funcitonality from Maven core -
>>> it only manages information on abstract source sets.
>>>   
>>
>> Sorry but I'm not sure I follow. Adding this abstraction adds to maven's
>> core. Offloading all processing and definition to the plugin is the way
>> I want to move.

Adding this abstraction would allow us to remve specific support for
sourceDirectory, unitTestDirectory, integrationUnitTestDirectory
resources (i.e. jar resources), testResources and
itegrationUnitTestResources in favor of support for abstract 'sources'
(tha you process somehow) and 'resources' (that you copy someplace).
Specific 'somehows' and 'someplaces' are defined by plugins.
I think this would make core smaller & simpler.

>> 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 <build/> element removed
>> and replaced with a place where you can define plugin settings if they
>> are required. We started this a long time ago and there was a proposal
>> that just never got implemented.

This made me think... Maybe the <sources> section of the POM is
completly redundant? Maven recommended project layout defines where
the sources of specific type be located. The plugin that processes that
type of sources lets you override the location through
project.properties to make mavenizing existing projects earlier,
and possibly defines a dyna-tag that lets interested parties add
more source paths if they need to. This makes sense for the java plugin,
and possibly other plugins too. Does that sound better, Jason?

> 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 plugin is
> fine). What feels inherently wrong about the present setup is that the
> POM specifically knows about 4 different source directory types, and
> stops there.  It should really only know about 'source directories', and
> stop there. What is done with the directories is a function of metadata
> (not expressed as xml elements, as presently done) attached to those
> entries, or the fact thay they are in a plugin specific section, and
> various plugins which act on that. Something similar to Michal's
> proposal is actually a lot cleaner than the present setup.

Well, I agree fully with Collin here.

R.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to