The following issue has been updated:

    Updater: Brett Porter (mailto:[EMAIL PROTECTED])
       Date: Wed, 2 Mar 2005 9:55 PM
    Comment:
this requires the use of maven-artifact from m2
    Changes:
             Fix Version changed from 1.1
             Fix Version changed to 1.1-beta-1
             Component changed from core
             Version changed from 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
   Fix Fors:
             1.1-beta-1

   Assignee: 
   Reporter: John Casey

    Created: Thu, 22 Jan 2004 2:22 PM
    Updated: Wed, 2 Mar 2005 9:55 PM
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]

Reply via email to