Maven
  1. Maven
  2. MNG-4293

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

    Details

    • Complexity:
      Intermediate
    • Number of attachments :
      0

      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

          Activity

          Hide
          Benjamin Bentmann added a comment -

          Done in r803422.

          Show
          Benjamin Bentmann added a comment - Done in r803422 .
          Hide
          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
          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
          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
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: