maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kek (JIRA)" <>
Subject [jira] Created: (MNG-4455) Pluggable Artifact types
Date Wed, 18 Nov 2009 12:20:55 GMT
Pluggable Artifact types

                 Key: MNG-4455
             Project: Maven 2
          Issue Type: Improvement
          Components: Artifacts and Repositories
            Reporter: Kek

First I want to thank to authors of great tool like Maven is.
And now my wish for Maven improvement:
Last week I try to make my first maven plugin to add support for my proprietary packaging,
the inspiration was from

This works fine, but I need support following scenario:

1) In Project-X  add dependency on Artifact-Y with packaging/type set to "MyArchive"
2) Maven resolves this dependency and downloads the artifact to local repository
3) When compilation or testing phase occures, the Artifact-Y:MyArchive should be unpacked
to some location (when not already unpacked) and the location should be added as classpathElement
to project classpath. 

I know, there is some possibility to use unpack-dependencies goal, but I need to unpack the
dependency only ones and share it in multi-module project environment. And second problem
is how to modify classpath to add the unpacked location. I found many questions about this
functionality on many forums, but no solution. Many people want to add some folder to classpath,
but no way. There was one - the system scope in dependency specification, but currently it
does not support folders in path.

So for my solution I create some specialized Mojo for this with following hack-code:
Set<Artifact> artSet=project.getDependencyArtifacts();
    for(Artifact art:artSet){
        File sharedFolder = new File("\\\\temp\\maven-shared")

This works fine, but when I use this in M2Eclipse plugin, then the folder is not added to
project classpath, because there is not my Mojo plugin executed during classpath resolution.

I look at m2eclipse source codes and to Maven2 and Maven3 source codes and in my opinion the
best way how to add support for this kind of issues ( when somebody want to define its own
type of Artifact and provide some plugable logic for its resolution/initialization) will be:

1) add and call ArtifactHandler.getClassPathFile() instead of Artifact.getFile() to obtain
reference to file or directory to be added to classpath  - the ArtifactHandler could provide
specialized implementation for different Artifact types as supported in current version.

2) OR add some support for plugable Artifact realizations by type, in current versions there
is DefaultArtifactFactory used for Artifact creation like :

ArtifactHandler handler = artifactHandlerManager.getArtifactHandler( type );
return new DefaultArtifact( groupId, artifactId, versionRange, desiredScope, type, classifier,
handler,optional );

The code should be changed to:

ArtifactHandler handler = artifactHandlerManager.getArtifactHandler( type );
return handler.createArtifact( groupId, artifactId, versionRange, desiredScope, type, classifier,optional

Or the ArtifactFactory should be pluggable by Artifact-type in the same way as ArtifactHandler.
Or some other solution.

I could contribute these changes to Maven, but I'm not sure, what is the prefered way to follow
Maven architecture ideas.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message