[ http://jira.codehaus.org/browse/MAVEN-1127?page=all ]
Arnaud Heritier updated MAVEN-1127:
-----------------------------------
Fix Version: (was: 1.1-beta-3)
1.1-beta-4
> decouple artifact type implementations from maven core
> ------------------------------------------------------
>
> Key: MAVEN-1127
> URL: http://jira.codehaus.org/browse/MAVEN-1127
> Project: Maven
> Type: New Feature
> Components: core
> Environment: all
> Reporter: John Casey
> Fix For: 1.1-beta-4
> Attachments: changes.patch, decoupled-artifact-types.patch, org.zip
>
> Original Estimate: 6 hours
> Remaining: 6 hours
>
> This is a copy of the proposal email I send to the dev list
> (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&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...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
