Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-5771

improved user-configurable core extensions mechanism

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.3.1
    • Component/s: Class Loading
    • Labels:
      None

      Description

      As of version 3.2.5 maven provides two mechanisms to contribute additional components to maven core runtime. It is possible to add component jars to $M2_HOME/lib/ext directory. It is also possible to specify component jars using -Dmaven.ext.class.path command line parameter. Neither of the mechanisms is user friendly. In both cases, the user is expected to manually locate and download all required jar file. In both cases, this has to be done on all systems where the extensions are needed. In both cases, all extra jars are loaded into single classloader so all extensions must agree of the same set of dependencies.

      This jira is to track changes needed to make it possible to configure core extensions in terms of groupId/artifactId/version and share set of required extensions across multiple systems.

      More specifically,

      • introduce new ${maven.projectBasedir}/.mvn/extensions.xml descriptor to specify list of extensions. Initially, the descriptor will only allow specification of extension groupId/artifactId/version, but can be extended to support dependency includes/excludes mechanism and configuration parameters later
        <?xml version="1.0" encoding="UTF-8"?>
        <extensions>
          <extension>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
            <version>...</version>
          </extension>
          <extension>...</extension>
          ...
        </extensions>
        
      • change maven to read and load core extensions in separate class realms as part of plexus container setup.
      • provide mechanism for extensions to declare exported artifacts and packages using META-INF/maven/extension.xml descriptor.

        Issue Links

          Activity

          Hide
          igorf Igor Fedorenko added a comment -

          reading extension exported packages and artifacts from META-INF/maven/extension.xml descriptor
          https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8631d79ca3b2f08a610196ac04a7b7cde4832c4a

          loading user-defined core extensions from $

          {maven.projectBasedir}

          /.mvn/extensions.xml
          https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6efacdb3fc5e8369fa3586c0603184dc785303da

          Show
          igorf Igor Fedorenko added a comment - reading extension exported packages and artifacts from META-INF/maven/extension.xml descriptor https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=8631d79ca3b2f08a610196ac04a7b7cde4832c4a loading user-defined core extensions from $ {maven.projectBasedir} /.mvn/extensions.xml https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=6efacdb3fc5e8369fa3586c0603184dc785303da
          Hide
          khmarbaise Karl Heinz Marbaise added a comment - - edited

          The extension mechanism is available since 3.1.1 as far as i know? Or do i mistaken here something?

          As of version 3.2.5 maven provides two mechanisms to contribute additional components to maven core runtime. It is possible to add component jars to $M2_HOME/lib/ext directory. It is also possible to specify component jars using -Dmaven.ext.class.path command line parameter.

          Show
          khmarbaise Karl Heinz Marbaise added a comment - - edited The extension mechanism is available since 3.1.1 as far as i know? Or do i mistaken here something? As of version 3.2.5 maven provides two mechanisms to contribute additional components to maven core runtime. It is possible to add component jars to $M2_HOME/lib/ext directory. It is also possible to specify component jars using -Dmaven.ext.class.path command line parameter.
          Hide
          igorf Igor Fedorenko added a comment -

          The new mechanisms allows configuration to be persisted inside project source tree, something that was not possible before. The extensions are configured in terms of groupId/artifactId/version and should be easier to manage. The new mechanism also has cleaner classloading model, so different extensions can have different dependencies.

          Show
          igorf Igor Fedorenko added a comment - The new mechanisms allows configuration to be persisted inside project source tree, something that was not possible before. The extensions are configured in terms of groupId/artifactId/version and should be easier to manage. The new mechanism also has cleaner classloading model, so different extensions can have different dependencies.
          Hide
          khmarbaise Karl Heinz Marbaise added a comment -

          I was just referencing the subject that it was already available for Maven 3.1.1 in general...with some drawback etc. which is has now became better (using via GAV) instead of command line option and per project...etc.

          Show
          khmarbaise Karl Heinz Marbaise added a comment - I was just referencing the subject that it was already available for Maven 3.1.1 in general...with some drawback etc. which is has now became better (using via GAV) instead of command line option and per project...etc.
          Hide
          igorf Igor Fedorenko added a comment -

          Fair enough. Updated jira description to indicate this is an improvement to rudimentary implementation that already existed in earlier maven versions.

          Show
          igorf Igor Fedorenko added a comment - Fair enough. Updated jira description to indicate this is an improvement to rudimentary implementation that already existed in earlier maven versions.
          Hide
          ydewit Yuri added a comment -

          Thanks, this is a great addition I have been waiting for some time!

          One comment though: wouldn't it make sense to allow extensions in the ~/.m2/settings.xml file too? Or allow settings.xml in the projectBaseDir? I have a situation where we have externalized our repo urls to settings.xml and these urls do require a specific extension. Right now, I need to manage the url and the extension that goes along with it in two different places.

          Show
          ydewit Yuri added a comment - Thanks, this is a great addition I have been waiting for some time! One comment though: wouldn't it make sense to allow extensions in the ~/.m2/settings.xml file too? Or allow settings.xml in the projectBaseDir? I have a situation where we have externalized our repo urls to settings.xml and these urls do require a specific extension. Right now, I need to manage the url and the extension that goes along with it in two different places.
          Hide
          igorf Igor Fedorenko added a comment -

          I don't think settings.xml in project basedir is a good idea. User settings are meant to provide environment specific configuration, like user credentials, which cannot be shared across different build system.

          Using ~/.m2/settings.xml to configure extensions is not a good idea because it will break earlier versions of maven. I don't have strong opinion about ~/.m2/extension.xml (or something like that). It is probably okay to for environment specific extensions, like your custom repository extension, assuming I understood your usercase correctly. I have no immediate plans to implement this myself, however.

          As a side note, questions like this are better asked on m2e-dev mailing list, where they will be visible to a wider audience of interested developers.

          Show
          igorf Igor Fedorenko added a comment - I don't think settings.xml in project basedir is a good idea. User settings are meant to provide environment specific configuration, like user credentials, which cannot be shared across different build system. Using ~/.m2/settings.xml to configure extensions is not a good idea because it will break earlier versions of maven. I don't have strong opinion about ~/.m2/extension.xml (or something like that). It is probably okay to for environment specific extensions, like your custom repository extension, assuming I understood your usercase correctly. I have no immediate plans to implement this myself, however. As a side note, questions like this are better asked on m2e-dev mailing list, where they will be visible to a wider audience of interested developers.
          Hide
          hudson Hudson added a comment -

          SUCCESS: Integrated in maven-3.x #1081 (See https://builds.apache.org/job/maven-3.x/1081/)
          MNG-5771 added core extension reference (hboutemy: rev 08715d87d92b06aa2845250c0caee5b271cf37c2)

          • maven-embedder/src/site/apt/index.apt.vm
          Show
          hudson Hudson added a comment - SUCCESS: Integrated in maven-3.x #1081 (See https://builds.apache.org/job/maven-3.x/1081/ ) MNG-5771 added core extension reference (hboutemy: rev 08715d87d92b06aa2845250c0caee5b271cf37c2) maven-embedder/src/site/apt/index.apt.vm
          Hide
          ydewit Yuri added a comment -

          I don't think settings.xml in project basedir is a good idea. User settings are meant to provide environment specific configuration, like user credentials, which cannot be shared across different build system.

          I agree 100%.

          Using ~/.m2/settings.xml to configure extensions is not a good idea because it will break earlier versions of maven. I don't have strong opinion about ~/.m2/extension.xml (or something like that). It is probably okay to for environment specific extensions, like your custom repository extension, assuming I understood your usercase correctly. I have no immediate plans to implement this myself, however.

          I didn't realize it would break earlier versions of maven. In any case, something like ~/.m2/extension.xml would work just the same.

          Just to be a bit more specific, we are using Spring's S3 Wagon and it provides us a scalable and fault tolerant storage for our artifacts without the need for something like Artifactory or Nexus. We used to set this S3 wagon extension in a parent POM that was released independently, but then we got into a chicken and egg problem, specially when we have new hires or when bootstrapping a new laptop or when recreating ~/.m2/repo: how to download the parent POM when it is the one that would tell maven how.

          So we moved the <repository/> urls to settings.xml as properties in an active-by-default profile and we started distributing a custom Maven distribution with the S3 wagon jars embedded in the lib/ext folder. It works but it is a bit of a pain specially when there are new versions etc. If we were able to provide every developer a /.m2/settings.xml and a /.m2/extension.xml then both the S3 urls and the S3 wagon that can read/write these urls, then we would be done with it.

          Show
          ydewit Yuri added a comment - I don't think settings.xml in project basedir is a good idea. User settings are meant to provide environment specific configuration, like user credentials, which cannot be shared across different build system. I agree 100%. Using ~/.m2/settings.xml to configure extensions is not a good idea because it will break earlier versions of maven. I don't have strong opinion about ~/.m2/extension.xml (or something like that). It is probably okay to for environment specific extensions, like your custom repository extension, assuming I understood your usercase correctly. I have no immediate plans to implement this myself, however. I didn't realize it would break earlier versions of maven. In any case, something like ~/.m2/extension.xml would work just the same. Just to be a bit more specific, we are using Spring's S3 Wagon and it provides us a scalable and fault tolerant storage for our artifacts without the need for something like Artifactory or Nexus. We used to set this S3 wagon extension in a parent POM that was released independently, but then we got into a chicken and egg problem, specially when we have new hires or when bootstrapping a new laptop or when recreating ~/.m2/repo : how to download the parent POM when it is the one that would tell maven how. So we moved the <repository/> urls to settings.xml as properties in an active-by-default profile and we started distributing a custom Maven distribution with the S3 wagon jars embedded in the lib/ext folder. It works but it is a bit of a pain specially when there are new versions etc. If we were able to provide every developer a /.m2/settings.xml and a /.m2/extension.xml then both the S3 urls and the S3 wagon that can read/write these urls, then we would be done with it.
          Hide
          igorf Igor Fedorenko added a comment -

          @Yuri I meant dev@maven.apache.org maven development list, not m2e dev list. sorry for the confusion.

          Show
          igorf Igor Fedorenko added a comment - @Yuri I meant dev@maven.apache.org maven development list, not m2e dev list. sorry for the confusion.

            People

            • Assignee:
              igorfie igorfie
              Reporter:
              igorf Igor Fedorenko
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development