maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject RE: PROPOSAL: decouple artifact types from maven core
Date Thu, 22 Jan 2004 23:06:21 GMT
Hi John,

I haven't looked at the stuff you put in JIRA, but you should be aware that
this is already planned and mostly implemented in the maven-artifact
component, I believe which will be integrated into Maven at a later date.
There is also the artifact plugin which we were discussing the other day and
relates to some of this.

I'll hold on to your mail and make sure all your requirements are met by the
new work, but I'm not sure we have a timeframe for including it just yet.
Michal is the expert on this :)


> -----Original Message-----
> From: John Casey [] 
> Sent: Friday, 23 January 2004 4:57 AM
> To:
> Subject: PROPOSAL: decouple artifact types from maven core
> 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...
> Let me know what you all think.
> -john
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message