Where should plugins live? Who can update them? Does it really make a difference?
The main Maven distribution includes many plugins, but the growing trend is to as plugin owners to host the plugins themselves (What do you mean, host?). Why? There are many advantages for the plugin owners, the users, and the Maven team.
Since only Maven committers may update the maven-plugins
repository, changes you make to your
plugin will take a while to make it into a Maven distribution. Each plugin needs a committer willing to
maintain it, and that plugin is not the only piece of Maven the committer works on.
Plugin owners are in a much better position to maintain the plugin. They originally wrote the plugin. They have a vested interest in seeing it succeed. If they host the plugin themselves, then updates can be incorporated quickly, and users get the benefits of updated software quicker.
This benefit is often maximized when a team that writes a library, like the StatCvs group, also creates the Maven plugin. As the library changes, the plugin may be updated to keep in sync. In fact, the Cactus and StatCvs plugins were among the first to voluntarily remove their plugins from the Maven distribution and be hosted with their respective libraries.
To "host" a Maven plugin, you require only two things:
maven site
) documentationThere are a variety of options available for each need. Your source code may simply be kept on your hard drive, using a local installation of a version control tool like CVS or Subversion (you do use version control, don't you?). If you'd like to share your plugin source with others, you can request a new project at a service like SourceForge or Java.Net, or request to join an existing project like the Maven-Plugins project on SourceForge.
If you're creating a plugin for an existing open-source (or even closed-source) library, the ideal situation is to approach the library maintainers about hosting your plugin source and site. That way the plugin source is close to the people most likely to care about its success, and ensure it works well far into the future. The plugin site is located close to the already well-known library site. In the end, this cooperation means a better chance at happy users, and up-to-date plugins for everyone.
Please see the instructions for uploading a resource to ibiblio.org.
NOTE: If your plugin requires resources (JAR files) that are not already at ibilio.org, you may need to make several separate upload requests.
There are two ways to let your potential users know about your plugin. The first is through sending an announcement
to the maven-user
mailing list. Here's a few pointers on how to go about it.
maven-user
mailing listmaven-user
mailing listThe second way to publicize your plugin is on the Maven site itself. The Maven project currently maintains a list of other sites that host plugins. The best way to get your link on this page is to get the Maven source, and submit a patch to the list file itself. Here are the steps in a bit more detail.
maven-plugins
source as described hereMAVEN_PLUGINS_SOURCE/xdocs/index.xml
<tr>
) portion above to your
host's section. Order your plugins appropriately within your host section.maven
(here) and the documentation
component.
Place a note in your JIRA issue telling the developer that your patch is against the maven-plugins
documentation.Here's the general idea
maven plugin:download -DartifactId=[plugin-name] -DgroupId=[plugin-group] -Dversion=[plugin-version]
For example:
maven plugin:download -DartifactId=maven-statcvs-plugin -DgroupId=statcvs -Dversion=2.4
Documentation maintained by Maven committers.
These links include collected documentation about Maven, contributed from a variety of sources.
Discussion that occured on the Maven mailing lists.