...
While all of the issues outlined below have the potential to cause counter-intuitive build failures, those marked as merely IMPORTANT are considered edge cases that should not affect a wide spectrum of users.
...
[CRITICAL]
...
Plugin
...
Extensions
...
and
...
POM
...
Inheritance
Plugins that use the extensions flag could conceivably cause issues for the ExtensionManager, since their coordinate information (most notably, their version) can be inherited from parent POMs or injected from a pluginManagement section of the POM. Additionally, plugin-level dependencies may be inherited or injected in a similar fashion. Currently, I'm not entirely confident that these use cases have been covered in tests. If they are broken, some additional logic will be required to ensure some minimal inheritance and managed-data injection take place before the extension plugin is initialized.
...
[CRITICAL]
...
Plugins
...
with
...
extensions
...
flag
...
and
...
plugin-level
...
dependencies
...
will
...
experience
...
the
...
same
...
first-come-first-served
...
behavior
...
as
...
all
...
plugins
...
did
...
in
...
Maven
...
2.0.x.
One possible solution to this is to simply adopt the same realm key algorithm used in non-extension plugins currently in 2.1.x, though the GOTCHA about inheritance and injection of plugin information still applies here.
...
...
[IMPORTANT]
...
Support
...
builds
...
that
...
specify
...
interproject
...
extension
...
references
I think this issue creates a backward-compatibility problem from 2.0.x, though I can't find a test that verifies it.
...
Also, it's not clear how aggregator plugins might derail this logic, since they need access to all project instances when they execute. Another drawback of this approach is that it would negate a lot of the fail-fast behavior built into the current Maven, by deferring extension loading - and by extension, project instantiation for B - until after other projects have built...and some project builds are very time consuming.
...
[IMPORTANT]
...
Modules
...
defined
...
in
...
POM
...
profiles
...
are
...
not
...
scanned
...
for
...
extensions
In cases where profiles are used to change the behavior of builds on the broadest scales (the ServiceMix around SVN revId: 642243 is a great example of this), profiles are often used to switch between two completely separate sets of modules, with no modules defined in the root of the POM itself. When applying the current 2.1 extension-loading design to this scenario, none of the modules are currently scanned for extensions or plugins with an active extensions flag.
...
- avoid exceptions when these custom activators are used, but haven't yet been loaded (in case we cannot load them first)
- or, better yet: make sure any custom profile activators used by the current POM are loaded before the profiles are activated, to ensure all intended profile activation can take place.
...
...
[IMPORTANT]
...
Plugins
...
defined
...
in
...
POM
...
profiles
...
with
...
an
...
active
...
extensions
...
flag
...
will
...
not
...
be
...
loaded
...
as
...
extensions
This situation is very similar to that outlined in the section above, where the module-list scanned for extensions is incorrect due to some modules being defined in profiles. Likewise, plugins with extensions == true could be defined in profiles, and currently Maven would fail to find them during the extension-scanning process. Fixes for this will likely be the same as the above.
...
...
[IMPORTANT]
...
Allow
...
extension
...
authors
...
to
...
specify
...
which
...
classes
...
should
...
be
...
imported
...
into
...
project
...
realms
In cases where the extension classpath is 2 or fewer artifacts, or the extension provides a lifecycle mapping, the current extension-loading mechanism in 2.1.x breaks backward compatibility. In such cases, 2.0.x loads the entire extension classpath is exposed to the Maven runtime for use in plugins or the core itself. By limiting class imports into the project realm to only component-implementation classes, Maven 2.1.x currently eliminates the possibility of accessing a component by a custom interface defined in the extension (through casting). It also prohibits access to components defined in dependencies of the extension artifact, since these dependency artifacts are not scanned for component definitions. Finally, anything else, such as custom datatypes, will also be isolated behind the extension-realm barrier.
...