directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: Maven 3 and site generation
Date Thu, 27 Jan 2011 10:32:23 GMT
On Wed, Jan 26, 2011 at 7:47 AM, Felix Knecht <felixk@apache.org> wrote:
>>>>> I don't know if M3 site plugins configuration is
>>>>> inheritable/expandable to
>>>>> add additional reports for specific modules/projects. That's why I
>>>>> wonder if
>>>>> it wouldn't make more sense defining the site plugins configuration
>>>>> rather
>>>>> in each projects pom.xml (studio/shared/apacheds/...) than in the
>>>>> directory/project/pom.xml?
>>>>
>>>> Good point.
>>>>
>>>> It was a weakness of the M2 reporting configuration that it wasn't
>>>> inheritable. I hope(d) that would be fixed in M3, but we can just test
>>>> it.
>>>
>>> Up to now I wasn't successfull. All I got was an error like
>>> "failed to get Reports: Could not find goal 'cim' in plugin" ...
>>
>> This http://jira.codehaus.org/browse/MSITE-484 help a bit. Let's do some
>> more testing ...
>
> IMO it's less complicated and less painfull when dropping the
> maven-site-plugin configuration from the project/pom.xml (parent) and fully
> configure it in each subproject's own pom.xml (studio/shared/apacheds/...).
>
> Using workarounds (like MSITE-484) will not really make things more stable
> and understandable. The KISS principle will make it also easier to
> understand the plugin configuration.

Wow, I got it now: The configurations are merged in the order as
defined, there is no match by groupId/artifactId.

So if the parent POM defines configurations for reporting plugins A,
B, and C. And the child POM defines reporting plugins X, Y, and Z.
Then the configuration of A is merged into X, B's configuration is
merged into Y, etc. That makes no sense at all.

I'll remove the site plugin from the 'project' POM.

Kind Regards,
Stefan

Mime
View raw message