The following issue has been updated:
Updater: Brett Porter (mailto:[EMAIL PROTECTED])
Date: Sat, 23 Oct 2004 2:20 AM
Changes:
Fix Version changed to 1.1
---------------------------------------------------------------------
For a full history of the issue, see:
http://jira.codehaus.org/browse/MAVEN-1127?page=history
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/browse/MAVEN-1127
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MAVEN-1127
Summary: decouple artifact type implementations from maven core
Type: New Feature
Status: Unassigned
Priority: Major
Original Estimate: 6 hours
Time Spent: Unknown
Remaining: 6 hours
Project: maven
Components:
core
Fix Fors:
1.1
Versions:
1.1
Assignee:
Reporter: John Casey
Created: Thu, 22 Jan 2004 2:22 PM
Updated: Sat, 23 Oct 2004 2:20 AM
Environment: all
Description:
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...
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
