Maven 2 & 3

Revisit backwards compat of extensions (IT 0114)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 3.0-alpha-1
  • Fix Version/s: 3.0-alpha-3
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

currently, it 0114 doesn't pass due to the removal of extension support

we need to either:

  • restore some form of backwards compat by loading the extension into the expected place
  • provide a graceful failure instead

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-2749 extensions stopped working in 2.0.5-SNAPSHOT

  • Blocker - Blocks development and/or testing work, production could not run
  • 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
Brett Porter added a comment -

also affected: 111, mng3485

Show
Brett Porter added a comment - also affected: 111, mng3485
Hide
Permalink
Benjamin Bentmann added a comment -

Just to avoid suprises: it0114 has been renamed to match its corresonding issue MNG-2749.

Show
Benjamin Bentmann added a comment - Just to avoid suprises: it0114 has been renamed to match its corresonding issue MNG-2749 .
Hide
Permalink
Jason van Zyl added a comment -

Once I update the extension support this should be taken care of.

Show
Jason van Zyl added a comment - Once I update the extension support this should be taken care of.
Hide
Permalink
Benjamin Bentmann added a comment -

Fixed in r815761.

Just to mention it, we can't completely cut off plugins from the extensions because plugins can inspect the execution plan or create&resolve artifacts. Those tasks require access to lifecycle mappings and artifact handlers, both contributed by extensions.

We now have the following parent-child chain of class realms on trunk: core realm -> project realm -> plugin realm. The project realm is only present if the project actually declares any extensions, otherwise the plugin realm is a direct child of the core realm.

The project realm aggregates all JARs from its build extensions so there's the potential for conflicts between extensions. For the moment, this should work well enough, more sophisticated class loader setups likely require more metadata in the extension JARs, e.g. what should be exported/shared and what is private impl.

Show
Benjamin Bentmann added a comment - Fixed in r815761 . Just to mention it, we can't completely cut off plugins from the extensions because plugins can inspect the execution plan or create&resolve artifacts. Those tasks require access to lifecycle mappings and artifact handlers, both contributed by extensions. We now have the following parent-child chain of class realms on trunk: core realm -> project realm -> plugin realm. The project realm is only present if the project actually declares any extensions, otherwise the plugin realm is a direct child of the core realm. The project realm aggregates all JARs from its build extensions so there's the potential for conflicts between extensions. For the moment, this should work well enough, more sophisticated class loader setups likely require more metadata in the extension JARs, e.g. what should be exported/shared and what is private impl.

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Brett Porter
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: