Hello Igor, Well - there is certainly a point of requiring the plugin API to require same dependencies (including versions) as are mandatory for correct execution of the plugin itself. A common parent defining maven GAVs and standard dependency management can probably solve that without too much hazzle.
However, I'm more concerned with the case where the extensions do not require most/any of the plugin's dependencies at all. The NodeProcessor example above implies only SAX/DOM dependencies - no JAXB/plexus or other framework stuff is required at all, since the NodeProcessor specification does not deal with anything JAXB'ish. Instead, this particular plugin extension manages post-processing results generated by SchemaGen. Therefore, I felt it was far from optimal to drench the implementation project in the JAXB plugin's compile-scope dependencies by not moving the extensino specifications to separate projects. It would likely be simpler to just have a single project, and let the users deal with the complexities of dependency fiddling - but it seems a rather poor example of applied modularisation. 2015-01-18 14:00 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>: > 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 > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
