Maven 1
  1. Maven 1
  2. MAVEN-1127

decouple artifact type implementations from maven core

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None
    • Environment:
      all
    • Number of attachments :
      3

      Description

      This is a copy of the proposal email I send to the dev list
      (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=dev@maven.apache.org&msgNo=13740):

      While I find the plugin architecture of maven to be fantastic, I have run into a somewhat serious barrier to my own plugin development
      efforts: adding support for new artifacts requires some pretty significant changes to the maven core, and results in a requirement that I maintain a patch for each artifact type.

      The Problem
      ----------------------------

      The concept of artifact types is intimately coupled with the rest of the maven core implementation. There seems to be no real compelling reason for this; each artifact type has a base set of operations which can be performed against it (with high overlap between types: install, install-snapshot, deploy, deploy-snapshot), and one or more plugins which are the primary producers/consumers of it. While I would agree that certain artifact types are fundamental to maven operation, it can also be stated that certain plugins are similarly fundamental. Therefore, for these plugins, the concept of decoupling via plugin architecture is flawed. In order to change the plugin in any significant way, a change to the maven core may be required to support changes to the artifact type. In addition, this inherently limits plugin development by giving a hard-and-fast set of artifact types which can be manipulated by maven.

      The Solution
      ---------------------------

      Simply put, decouple artifact type implementations from the maven core. Instead of having a concrete implementation specifying attributes about a .jar, EJB, or .pom, factor out the common behavior (aforementioned permutations of install and deploy) into an interface, called ArtifactTypeHandler. Then, create concrete implementations of this interface for each type. Finally, add a new dynamic type handler loader (factory class) which will do the following:

      1. Pull the <type>typename</type> attribute from a dependency, or otherwise arrive at the artifact type desired.

      2. Read the classpath resource META-INF/artifactTypes/typename; line 1 of this file specifies the fully-qualified class name for the type handler.

      3. Instantiate this handler class, and return it as the implementation to use in manipulating this artifact.

      This is a variation on the JAR service discovery method specified in the JDK1.3, and allows each plugin to add an artifact type handler for its own use. Unrecognized artifact types (i.e. the handler jar is not in the classpath, and therefore the META-INF/artifactTypes/typename resource is not present) can be ignored or throw an exception.

      Justification
      ------------------------

      Under this new architecture, the only artifact-related code in maven-core is the ArtifactTypeHandlerFactory and the abstract [interface] ArtifactTypeHandler. This frees maven up to be a general build tool, agnostic of what type of artifacts it is handling. DLL's, C headers, configuration files, etc. are all perfectly usable within the maven repository scheme. Maven is only limited by the plugins available for it at this point, and plugin development is not limited by the release cycle for maven-core.

      I can produce a patch against maven to accomplish this, if there is adequate interest...

        Activity

        Hide
        John Casey added a comment -

        I believe this refactoring can begin life as simply an explosion of the ArtifactType typesafe enum, where the ArtifactType static method functionality actually becomes a factory implementation. This is where the META-INF/artifactTypes/... stuff would come into play.

        Admittedly, this modification would make is a little harder to find an authoritative list of supported artifact types, but I'm not sure what the value of that list really is...

        Show
        John Casey added a comment - I believe this refactoring can begin life as simply an explosion of the ArtifactType typesafe enum, where the ArtifactType static method functionality actually becomes a factory implementation. This is where the META-INF/artifactTypes/... stuff would come into play. Admittedly, this modification would make is a little harder to find an authoritative list of supported artifact types, but I'm not sure what the value of that list really is...
        Hide
        John Casey added a comment -

        ...oops, forgot to add this...

        I believe this addition would make the inclusion of solutions to

        MAVEN-1068
        MAVEN-670
        MAVEN-572

        pretty easy to code, without synchronizing them with the release cycle of maven-core.

        Show
        John Casey added a comment - ...oops, forgot to add this... I believe this addition would make the inclusion of solutions to MAVEN-1068 MAVEN-670 MAVEN-572 pretty easy to code, without synchronizing them with the release cycle of maven-core.
        Hide
        John Casey added a comment -

        first pass at implementation of this proposal vs. maven HEAD.

        I build maven with this patch in place, and everything seems to work fine.

        Show
        John Casey added a comment - first pass at implementation of this proposal vs. maven HEAD. I build maven with this patch in place, and everything seems to work fine.
        Hide
        Daniel Marchant added a comment -

        I did some changes for against the Maven 1.0 RC4 and had changed it to be a bit more robust for supporting different type of artifacts and artifact handlers. I have attached the patch and new code files as changes.patch and org.zip

        Also the way I did it, is have the project.properties add something like:

        maven.type.handler.package=org.apache.maven.repository.ComponentArtifactTypeHandler
        maven.type.handler.jni=org.apache.maven.repository.NativeArtifactTypeHandler

        Where the "maven.type.handler." is a prefix and the "package" is the name of the type that is specified in the dependency type. This helped me create a native dependency grabber (included in the zip) and a component dependency grabber (included in the zip) that would grab the <dependency artifactid >.xml and loop through to grab it's dependencies as well.

        Hope this helps in making maven a bit more robust and easier to extend.

        Show
        Daniel Marchant added a comment - I did some changes for against the Maven 1.0 RC4 and had changed it to be a bit more robust for supporting different type of artifacts and artifact handlers. I have attached the patch and new code files as changes.patch and org.zip Also the way I did it, is have the project.properties add something like: maven.type.handler.package=org.apache.maven.repository.ComponentArtifactTypeHandler maven.type.handler.jni=org.apache.maven.repository.NativeArtifactTypeHandler Where the "maven.type.handler." is a prefix and the "package" is the name of the type that is specified in the dependency type. This helped me create a native dependency grabber (included in the zip) and a component dependency grabber (included in the zip) that would grab the <dependency artifactid >.xml and loop through to grab it's dependencies as well. Hope this helps in making maven a bit more robust and easier to extend.
        Hide
        Daniel Marchant added a comment -

        Changes Daniel Marchant proposes

        Show
        Daniel Marchant added a comment - Changes Daniel Marchant proposes
        Hide
        Daniel Marchant added a comment -

        Code for new files as part of Daniel Marchant's proposal

        Show
        Daniel Marchant added a comment - Code for new files as part of Daniel Marchant's proposal
        Hide
        Daniel Marchant added a comment -

        By the way John I like the way you added the properties in the classpath like the discovery. So whatever seems to work for this the better.

        I moved the artifact wrapper creation to the artifact handler as well so that integrators can have a bit more flexibility of how the url and other things are created.

        Let me know how I can help in finalizing this.

        Thanks

        Dan

        Show
        Daniel Marchant added a comment - By the way John I like the way you added the properties in the classpath like the discovery. So whatever seems to work for this the better. I moved the artifact wrapper creation to the artifact handler as well so that integrators can have a bit more flexibility of how the url and other things are created. Let me know how I can help in finalizing this. Thanks Dan

          People

          • Assignee:
            Unassigned
            Reporter:
            John Casey
          • Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 6 hours
              6h
              Remaining:
              Remaining Estimate - 6 hours
              6h
              Logged:
              Time Spent - Not Specified
              Not Specified