Extend Mojo API to allow resolution of both compile and runtime dependencies

Details

  • Complexity:
    Intermediate

Description

Right now, only @requiresDependencyResolution compile|runtime|test is supported. However, runtime is no superset of compile but plugins occasionally need both scopes. To better support those use cases, a new resolution scope compile+runtime will be introduced. See also [DISCUSS] Extend Mojo API to allow for resolution of multiple dependency scopes

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-1390 @requiresDependencyResolution in process-classes post compile

  • 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
Benjamin Bentmann added a comment -

Done in r803422.

Show
Benjamin Bentmann added a comment - Done in r803422.
Hide
Permalink
Paul Benedict added a comment -

Too bad the inverse is not supported. With source annotation processors, they only need compile scope but not runtime scope.

Show
Paul Benedict added a comment - Too bad the inverse is not supported. With source annotation processors, they only need compile scope but not runtime scope.
Hide
Permalink
Benjamin Bentmann added a comment -

The inverse of the new scope "compile+runtime" would be test-only, so I don't get how that fits together with your statement about needing only compile scope. Those goals can already use @requiresDependencyResolution compile.

Show
Benjamin Bentmann added a comment - The inverse of the new scope "compile+runtime" would be test-only, so I don't get how that fits together with your statement about needing only compile scope. Those goals can already use @requiresDependencyResolution compile.
Hide
Permalink
Paul Benedict added a comment - - edited

I misspoke. It's actually a problem for the package phase (or for MWAR). Right now, the assumption is that all dependencies of compile scope are also necessary for packaging. That's not necessarily correct. If a library is only need for compile scope (such as annotation processor), it gets bundled into WEB-INF/lib. While not necessarily directly related to this ticket, a new possible scope would be great for this purpose. Is it simply a matter of packaging exclusion or is it really another scope?

How is test scope the inverse? If it is only needed for compiling, it doesn't need to be loaded for testing either.

By the way, I know a plus-sign can have the same semantics as a comma (i.e., logical or), but if you used the comma it could leave room for future expansion. Maybe one day users could configure any combination of scopes. Specifying "compile,runtime" seems like the natural path, imo.

Show
Paul Benedict added a comment - - edited I misspoke. It's actually a problem for the package phase (or for MWAR). Right now, the assumption is that all dependencies of compile scope are also necessary for packaging. That's not necessarily correct. If a library is only need for compile scope (such as annotation processor), it gets bundled into WEB-INF/lib. While not necessarily directly related to this ticket, a new possible scope would be great for this purpose. Is it simply a matter of packaging exclusion or is it really another scope? How is test scope the inverse? If it is only needed for compiling, it doesn't need to be loaded for testing either. By the way, I know a plus-sign can have the same semantics as a comma (i.e., logical or), but if you used the comma it could leave room for future expansion. Maybe one day users could configure any combination of scopes. Specifying "compile,runtime" seems like the natural path, imo.

People

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

Dates

  • Created:
    Updated:
    Resolved: