[m2] Reports & DefaultModelInheritanceAssembler

[Peter van de Hoef <pv...@springsite.com>]

Hi all,

If I look at the source of the DefaultModelInheritanceAssembler (m2 alpha-2)
under the comment '// Reports :: aggregate'. It says that reports of the parent pom and the child pom are merged.
This works fine, but if I have no <reports> section at all in the child pom, no reports are generated at all.

Is this the way it should be?
Or stated differently. Are reports inherited from parent pom's? Even if there is no <reports> section in the child pom?

I have worked around this by specifying an empty <reports/> element in the child pom. In that way, all reports from the 
parent are inherited.

Thanks,
Peter van de Hoef

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Reports & DefaultModelInheritanceAssembler

[Peter van de Hoef <pv...@springsite.com>]

Thanks.

Brett Porter wrote:

>On 5/18/05, Peter van de Hoef <pv...@springsite.com> wrote:
>  
>
>>Brett Porter wrote:
>>    
>>
>>>On 5/17/05, Peter van de Hoef <pv...@springsite.com> wrote:
>>>      
>>>
>>These are, in my perception, 'built-in' plugins. They are executed automatically as part of the 'install' goal.
>>    
>>
>
>I see your point, but the default lifecycle (which binds these to
>"install") won't always be the only one - other types might bind
>different things, and there may be alternative cycles.
>
>  
>
>>Well, I can live with the duplicate 4 lines of code in each POM but I'm afraid that when more steps are added to the
>>build sequence, this might become error-prone.
>>    
>>
>
>Yes, after consideration I agree. We are all about reducing
>duplication. I've sent a proposal to the dev@ list.
>
>- Brett
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>For additional commands, e-mail: users-help@maven.apache.org
>
>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Reports & DefaultModelInheritanceAssembler

[Brett Porter <br...@gmail.com>]

On 5/18/05, Peter van de Hoef <pv...@springsite.com> wrote:
> 
> Brett Porter wrote:
> > On 5/17/05, Peter van de Hoef <pv...@springsite.com> wrote:
> These are, in my perception, 'built-in' plugins. They are executed automatically as part of the 'install' goal.

I see your point, but the default lifecycle (which binds these to
"install") won't always be the only one - other types might bind
different things, and there may be alternative cycles.

> Well, I can live with the duplicate 4 lines of code in each POM but I'm afraid that when more steps are added to the
> build sequence, this might become error-prone.

Yes, after consideration I agree. We are all about reducing
duplication. I've sent a proposal to the dev@ list.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Reports & DefaultModelInheritanceAssembler

[Peter van de Hoef <pv...@springsite.com>]

Brett Porter wrote:
> On 5/17/05, Peter van de Hoef <pv...@springsite.com> wrote:
> 
>>Why are built-in plugins inherited and user-defined plugins not? (their usage is not inherited, their configuration is
>>via <pluginManagement> but their usage has to be specified in each project).
> 
> 
> Neither are. There is no such thing as a "built-in" plugin. What does
> happen, is that certain goals are preconfigured, and that discovers
> those plugins... so if you call "aspectj:aspectj", it will work
> immediately.

Agreed, but when I run "m2 install", the following goals are automatically executed:

resources:resources
compiler:compile
resources:testResources
compiler:testCompile
surefire:test
install:install

These are, in my perception, 'built-in' plugins. They are executed automatically as part of the 'install' goal.
I don't know where this is configured and as far as I can see I cannot change it. There is for example, no place where I 
  can remove the 'surefire:test' goal. And there's no place where I can insert the 'aspectj:aspectj' goal or any user 
defined task so that those are the actions that will take place in all of my projects.
(or am I still in an 'Ant-like' mindset where a 'build' is a sequence of 'goals/targets' and have completely missed the 
essence of Maven? :-) )

> But you are going to need to configure it on the projects that use it.
> 
> So what you are saying is that you want to be able to inherit the
> enablement of aspectj on every project inheriting a certain POM. This
> isn't a use case we've considered (again, we want inheritence and
> master build to co-exist in m2, which is why active parts of the pom
> are not inherited, only configuration). I'll keep it in mind.

Yes. We are for example working with the Eclipse Modeling Framework (EMF). We want to automate the generation of java 
sources from EMF models with a Maven plugin so that each time the 'install' or 'deploy' goal is executed, Maven will 
execute the 'emf:generate' task before the 'compiler:compile' task is executed. Much like the 'preGoal' facility of Maven1.

Well, I can live with the duplicate 4 lines of code in each POM but I'm afraid that when more steps are added to the 
build sequence, this might become error-prone.

Thanks for your time!
Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Reports & DefaultModelInheritanceAssembler

[Brett Porter <br...@gmail.com>]

On 5/17/05, Peter van de Hoef <pv...@springsite.com> wrote:
> Why are built-in plugins inherited and user-defined plugins not? (their usage is not inherited, their configuration is
> via <pluginManagement> but their usage has to be specified in each project).

Neither are. There is no such thing as a "built-in" plugin. What does
happen, is that certain goals are preconfigured, and that discovers
those plugins... so if you call "aspectj:aspectj", it will work
immediately.

But you are going to need to configure it on the projects that use it.

So what you are saying is that you want to be able to inherit the
enablement of aspectj on every project inheriting a certain POM. This
isn't a use case we've considered (again, we want inheritence and
master build to co-exist in m2, which is why active parts of the pom
are not inherited, only configuration). I'll keep it in mind.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Reports & DefaultModelInheritanceAssembler

[Peter van de Hoef <pv...@springsite.com>]

I would realy love to have inheritance of <build><plugins> and <reports><plugins>!
In that way Maven becomes much more extensible I think.

For example when I create a new programming language, lets say 'foo'. I only have to create a 
'maven-foo-compiler-plugin' and add it to the parent of all POMs and all 30,000 programmers of my company, working on 
more than 5,000 projects (just kidding ;-)) only have to get the latest version of the parent POM and they can start 
using the the 'foo' programming language which has been preconfigured for them in the base POM.

A more realisitic example might be the compilation of aspects, for which you had the <aspectSourceDirectory> element 
hardcoded in the <build> section of Maven 1. The most natural way to compile aspects in Maven 2 would be a plugin that 
compiles aspects. And since plugins are not inherited, the aspect-compiler plugin has to be specified in each project, 
whereas setting for built-in plugins like the java compiler (<build><sourceDirectory>) and unit tests 
(<build><testSourceDirectory>) will be inherited by derived POM's.
I think there is no principal difference between built-in plugins and user-defined plugins (for me as user at least ;-)) 
Why are built-in plugins inherited and user-defined plugins not? (their usage is not inherited, their configuration is 
via <pluginManagement> but their usage has to be specified in each project).

Hope I this adds a bit to the discussion.
Thanks,
Peter van de Hoef

Brett Porter wrote:
> On 5/16/05, Peter van de Hoef <pv...@springsite.com> wrote:
> 
>>Hi all,
>>
>>If I look at the source of the DefaultModelInheritanceAssembler (m2 alpha-2)
>>under the comment '// Reports :: aggregate'. It says that reports of the parent pom and the child pom are merged.
>>This works fine, but if I have no <reports> section at all in the child pom, no reports are generated at all.
> 
> 
> Ok, it needs to be improved. I'm a bit torn on how to do it.
> 
> For consistency and to allow aggregation as well as inheritence, I'd
> prefer that reports behaved like plugins: not inherited at all, but
> reportManagement is inherited.
> 
> However, unlike plugins, there does seem to be some case for
> inheriting what reports are used. We need to look for an alternative
> there.
> 
> My gut feeling is that the reports should be declared in site.xml, and
> we have some way of managing inheritence for that when a site is built
> as a set of projects (Which we need anyway). We should also have a
> default set of reports like in Maven 1.0 in case nothing is defined.
> 
> I will discuss this with the other developers. For now, you will need
> to declare your reports in every pom (sorry).
> 
> - Brett
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Reports & DefaultModelInheritanceAssembler

[Brett Porter <br...@gmail.com>]

On 5/16/05, Peter van de Hoef <pv...@springsite.com> wrote:
> Hi all,
> 
> If I look at the source of the DefaultModelInheritanceAssembler (m2 alpha-2)
> under the comment '// Reports :: aggregate'. It says that reports of the parent pom and the child pom are merged.
> This works fine, but if I have no <reports> section at all in the child pom, no reports are generated at all.

Ok, it needs to be improved. I'm a bit torn on how to do it.

For consistency and to allow aggregation as well as inheritence, I'd
prefer that reports behaved like plugins: not inherited at all, but
reportManagement is inherited.

However, unlike plugins, there does seem to be some case for
inheriting what reports are used. We need to look for an alternative
there.

My gut feeling is that the reports should be declared in site.xml, and
we have some way of managing inheritence for that when a site is built
as a set of projects (Which we need anyway). We should also have a
default set of reports like in Maven 1.0 in case nothing is defined.

I will discuss this with the other developers. For now, you will need
to declare your reports in every pom (sorry).

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org