I probably wouldn't use this for my plugins
Today, plugin extensions are loaded in the same classloader as the rest
of plugin dependencies. Hiding plugin dependencies from extensions
during compile-time does not reflect runtime and can do more harm than
good. If, for example, a plugin depends on Guava 14, it is probably a
good idea to compile plugin extensions against the same Guava version.
I also believe most extensibility APIs start as small experiments and
insisting on separate API module from the get-go seems unnecessary. And
even for well-defined extensibility API, I will still probably use
separate "public API" package(s) and move the rest of plugin
implementation to private packages extensions not supposed to use.
--
Regards,
Igor
On 2015-01-18 6:17, Lennart Jörelid wrote:
Hello folks,
I need a best practise here - hope you can assist me with some ideas and
suggestions.
*APIs for extensible-configuration plugins*
I believe that plugins that exposes extensible configuration options should
publish the APIs of those options as a separate project, to keep the set of
transitive dependencies pushed onto any implementors small.
If not extracting the configuration of the plugin to a separate project,
you force the entire stack of transitive dependencies from the plugin
project onto the implementing project - which might complicate things
unnecessarily. I'm making the following assumptions
1. A plugin (say jaxb2-maven-plugin) should expose its API in a project
whose GAV connects it to the plugin project. While the artifactID
"jaxb2-maven-plugin-configuration-api" is a mouthful, the naming standard
clearly connects it to the plugin project itself.
2. The PluginAPI project can contain default implementations - if
required - of the configuration objects which will serve to de-mystify the
potentially complex plugin configuration extension implementations.
3. When generating the documentation within the plugin project, it is
nice to have all documentation concerning usage and configuration in the
same location.
*Example*
Suppose you define the interface NodeProcessor within the PluginAPI
project, and use it within the Plugin project as follows:
@Parameter
private List<NodeProcessor> postProcessors;
.. and that the specification interface is trivial enough:
/**
* Processor/visitor pattern specification for DOM Nodes.
*
* @author <a href="mailto:l...@jguru.se";>Lennart Jörelid</a>
*/
public interface NodeProcessor {
/**
* Defines if this visitor should process the provided node.
*
* @param aNode The DOM node to process.
* @return <code>true</code> if the provided Node should be
processed by this NodeProcessor.
*/
boolean accept(Node aNode);
/**
* Processes the provided DOM Node.
*
* @param aNode The DOM Node to process.
*/
void process(Node aNode);
}
Since the NodeProcessor interface has nothing to do with Maven-esque APIs
or JAXB dependencies, I feel that this specification - as well as the few
standard existing implementations of the NodeProcessor interface - should
be placed in a PluginAPI project instead of the plugin project. This
implies that folks wanting to implement their own NodeProcessor does not
need to handle/combat any JAXB/Plexus/[whatever] dependencies needed by the
plugin project.
1. Do you agree?
2. If not - why? ... and
- How else would you suggest we should manage this?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
