Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


When the developer executes a Maven plugin (written in Java) from the command line, the Maven framework resolves the plugin and dependent artifacts: this does not cover non-Java artifacts. The problem with using non-Java artifacts within the runtime build environment is that it is not a matter of creating a classpath and referencing the artifacts from the local Maven repository; but rather, the artifacts may need to reside in specific locations on the build machine. For example, I have artifacts that NMaven resolves and installs into the GAC to support the Maven plugins written in .NET. Similar problems exist within C (or Java with JNI) environments with the need to resolve and add artifacts to the LD_LIBRARY path. In short, to support non-Java builds with Maven, we must be able to resolve and install artifacts into multiple locations and/or repositories.


At a minimum, the solution should tell the Maven client where to install the artifact: LD_LIBRARY, GAC, PAB (Private Assembly Base), Maven repo, etc. The artifact provider (the one who built the artifact) should be able to specify multiple endpoints, since there are cases where the artifact may be used, say, within both the GAC and PAB.

Given that the installation instruction may vary considerably based on language and environment, the instructions should be general enough to account for adding new environments. One approach would be to have Maven assign Resolver(s)/Installer(s) based on the artifact endpoint type (GAC, LD_LIBRARY). For instance, if Maven sees that the artifact is a dll and that it has instructions to install into the GAC and PAB, then Maven would instantiate the GacResolverInstaller implementation and the PabResolverInstaller implementation and invoke installation method(s) on each.

A second consideration would be how to get the right ResolverInstaller implementation if it is not included within core. Take the following example. Someone comes along and wants to add Ruby support to Maven. They build a ruby gem and deploy it to a Maven repo. They put within the pom.xml file installation instructions two pieces of information: 1) artifact-endpoint-type=GEM_REPO; 2) location=$RUBY_HOME. Now they create an implementation of the ResolverInstaller that knows what to do with the location value. They package and deploy this Java artifact, calling it maven-resinstaller-gem_repo (maven-resinstaller-<artifact-endpoint-type>). Maven can now match the appropriate implementation to the artifact-endpoint-type and will be able to resolve and install the gem even though it knows nothing about gems.


  • No labels