'build' section of POM does not appears to be inherited

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.0-alpha-1
  • Fix Version/s: None
  • Component/s: Plugins and Lifecycle
  • Labels:
    None

Description

It appears that the <build> section is (completely) inherited if it is not present in the derived POM, but if a <build> section is specified in the derived POM, everything from the base POM is thrown away and only the settings of the derived POM are used.

In my parent POM I have a <build> section which specifies the source directory and some parameters for the java compiler:

<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>1.0-alpha-2-SNAPSHOT</version>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
</plugins>
</build>

In a derived POM, the source directory is different, so a new <build> section is specified:

<build>
<sourceDirectory>module/src</sourceDirectory>
</build>

The overridden source directory is effectuated in this second POM, but it appears that the java compiler settings have disappeared (it starts e.g. complaining about JDK 1.4 features like assertions). If I do not specify a <build> section in the derived POM, the settings of the base POM are inherited.

Issue Links

is superceded by

Bug - A problem which impairs or prevents the functions of the product. MNG-362 <pluginManagement> inheritance problem

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

plugin configuration is not inherited; it is managed, so that only the child projects that need a particular plugin will get that plugin's goals injected into its lifecycle.

To use plugin management, add a <pluginManagement/> stanza to your parent POM.

See http://maven.apache.org/maven2/project-descriptor.html for more info.

Show
John Casey added a comment - plugin configuration is not inherited; it is managed, so that only the child projects that need a particular plugin will get that plugin's goals injected into its lifecycle. To use plugin management, add a <pluginManagement/> stanza to your parent POM. See http://maven.apache.org/maven2/project-descriptor.html for more info.
Hide
Permalink
John Casey added a comment -

There appears to be a bug in the handling of pluginManagement inheritance and also in the merging of pluginManagement-based data with the local-POM's plugin specification. I'm reopening this in order to track the fix...

Show
John Casey added a comment - There appears to be a bug in the handling of pluginManagement inheritance and also in the merging of pluginManagement-based data with the local-POM's plugin specification. I'm reopening this in order to track the fix...
Hide
Permalink
John Casey added a comment -

From an email I sent to the users@ list regarding plugin configuration, local overrides, and the pluginManagement section:

I'm looking at:

  • org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler
  • org.apache.maven.project.injection.DefaultModelDefaultsInjector

and here's what I see:

  • Combination of inherited <pluginManagement/> sections (both parent and
    child have <pluginManagement/> stuff defined):
    ----------------------------------------------------------------------

Everything is merged, with locally specified elements overriding
ancestor-specified elements in the event of a tie.

NOTE: There was a problem with the <configuration/> of a plugin not
being merged. I'm fixing this as we speak, although it's not going to be
in alpha-1 obviously...

  • Combination of local POM's <plugins/> with [inherited]
    <pluginManagement/> section:
    ----------------------------------------------------------------------

HOW IT WORKS: <configuration/> elements (both on <goal/> and on
<plugin/>) are combined, with ties going to the local configuration (if
the elements collide, the local specification wins). The list of goals
is accumulated, with the previous note applying to collisions of goals.
That is, if the <pluginManagement/> section specifies some goals and
their configuration for a given plugin, and the <plugin/> section
specifies some goals, the goal definitions from the <pluginManagement/>
section are merged into the one from the plugin specification itself.

NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm).
For instance, how would I suppress a goal that was declared in
<pluginManagement/> but allow other goals from that plugin to run? How
would I suppress plugin configuration declared similarly?

HOW I'M FIXING IT TO WORK: Any <configuration/> or <goals/> element
specified within a plugin in a local POM will negate the usage of the
corresponding element in the <pluginManagement/> section for that
plugin. This allows users to specify local overrides without having to
deal with the accumulation of common settings which are wrong for the
local case but which are not overridden in the local POM. It also makes
the override mechanism more consistent with <dependencyManagement/>.

Show
John Casey added a comment - From an email I sent to the users@ list regarding plugin configuration, local overrides, and the pluginManagement section: I'm looking at:
  • org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler
  • org.apache.maven.project.injection.DefaultModelDefaultsInjector
and here's what I see:
  • Combination of inherited <pluginManagement/> sections (both parent and child have <pluginManagement/> stuff defined): ----------------------------------------------------------------------
Everything is merged, with locally specified elements overriding ancestor-specified elements in the event of a tie. NOTE: There was a problem with the <configuration/> of a plugin not being merged. I'm fixing this as we speak, although it's not going to be in alpha-1 obviously...
  • Combination of local POM's <plugins/> with [inherited] <pluginManagement/> section: ----------------------------------------------------------------------
HOW IT WORKS: <configuration/> elements (both on <goal/> and on <plugin/>) are combined, with ties going to the local configuration (if the elements collide, the local specification wins). The list of goals is accumulated, with the previous note applying to collisions of goals. That is, if the <pluginManagement/> section specifies some goals and their configuration for a given plugin, and the <plugin/> section specifies some goals, the goal definitions from the <pluginManagement/> section are merged into the one from the plugin specification itself. NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). For instance, how would I suppress a goal that was declared in <pluginManagement/> but allow other goals from that plugin to run? How would I suppress plugin configuration declared similarly? HOW I'M FIXING IT TO WORK: Any <configuration/> or <goals/> element specified within a plugin in a local POM will negate the usage of the corresponding element in the <pluginManagement/> section for that plugin. This allows users to specify local overrides without having to deal with the accumulation of common settings which are wrong for the local case but which are not overridden in the local POM. It also makes the override mechanism more consistent with <dependencyManagement/>.
Hide
Permalink
John Casey added a comment -

I've committed the fix, but currently don't have a test case in which to verify my code changes (though they are pretty simple).

If someone has the time/motivation to build from trunk, and test the inheritance and injection scenarios above, I'd really appreciate it. Otherwise, I'll get to testing this when things calm down a bit.

Show
John Casey added a comment - I've committed the fix, but currently don't have a test case in which to verify my code changes (though they are pretty simple). If someone has the time/motivation to build from trunk, and test the inheritance and injection scenarios above, I'd really appreciate it. Otherwise, I'll get to testing this when things calm down a bit.
Hide
Permalink
Brett Porter added a comment -

nothing is required according to the original description. A different bug regarding pluginManagement was opened and that has been fixed.

Show
Brett Porter added a comment - nothing is required according to the original description. A different bug regarding pluginManagement was opened and that has been fixed.

People

  • Assignee:
    John Casey
    Reporter:
    Peter van de Hoef
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: