This document will track the design and implementation issues involved in adding support to m2 for marmalade-based mojos.
As in all mojo specifications, it is ideal that the descriptor for a marmalade-based mojo be inline with the source code. This centralizes all maintenance related to a single mojo to a single point of maintenance.
The following is what I'm thinking as of now:
- a marmalade-based mojo should look something like:
<mojo xmlns="m2:mojo" xmlns:marmalade-control="marmalade:marmalade-control" marmalade-control:el="none"> <metadata> <id>mmld</id> <name>mmldCompile</name> <lifecyclePhase>compile</lifecyclePhase> <description>Used to compile marmalade scripts into java beans.</description> <requiresDependencyResolution/> <instantiationStrategy/> <executionStrategy/> <parameters> <parameter> <name>classpath</name> <description>The compilation classpath</description> <type>java.util.List</type> <expression>#pom.artifacts</expression> <required/> <validator/> <default/> </parameter> </parameters> </metadata> <execute> <!-- Do some stuff. --> </execute> </mojo>
The marmalade mojo packager will:
The scripts directory should be tied to the script language within the POM. Until we have multiple language support in the POM, we'll use something like: xpath(build/marmaladeSourceDirectory).
This may include compilation of java helper classes, etc. and plugin-artifact packaging, presumably via 'jar:jar' or similar.
The marmalade mojo loader will:
Execution involves:
- #request == MavenExecutionRequest
- #response == MavenExecutionResponse
- Any globally configured environmental constraints, such as a global preserve-whitespace setting
This is important, since the default mojo loader will not be smart enough to do the job, and embedding this behavior in that loader is not scalable or extensible enough to accommodate future expansion into the realms of jython, groovy, etc...
UPDATE:07-FEB-2005
We'll plan on using some sort of language specification in the mojo descriptor to determine which mojo loader to use, then we'll populate the PluginLoader/PluginManager with a map of known languages->loaders.
This is closely related to [1] above.
UPDATE:07-FEB-2005
See update in [3].
These might include a mix of standard-java and marmalade mojos. It strikes me that many marmalade-based mojos may use beans/tags that are actually adapter classes for other third-party APIs (why they wouldn't implement everything as java mojos in this cases is beyond me). If they have java source inside the plugin source directory, we should probably compile it and bundle it with the plugin scripts; but what if this source also has mojo annotations? This will have implications for [1] and [2] above.
UPDATE:07-FEB-2005
We will plan on allowing this sort of implementation, and simply start by applying all known generators which have a source directory set in the POM (or later, have a language/ section, maybe). At any rate, helper classes will be allowed for script-based mojos.