maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: cvs commit: maven-components/maven-core/src/site/apt/scripting-support marmalade-support.apt
Date Wed, 09 Feb 2005 00:28:55 GMT
Hi John,

This is looking pretty good!

I'll let you own the document, but here are my thoughts. wrote:

>          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.
Is this potentially a problem in that we have to have so many ways of 
configuring different types of scripts. It may not be at all appropriate 
for some to do it in their native language.
While the javadoc style works great for Java ones, I wonder if a generic 
XML one might be helpful. In marmalade, this can still be inlined using 
namespaces as you have done.
Another reason is that this will mean we can make a more generic plugin 
metadata GUI editor.

>              <requiresDependencyResolution/>
If using this, I'd make it a boolean element rather than test existence. 
Modello probably likes it better anyway :)

I'd still like to consider the use of attributes in this sort of area if 
possible to make it less verbose.

Other than that, this looks good.

>    [[2]] <<Marmalade mojo packager.>>
>          The marmalade mojo packager will:
>          [[a]] Locate all *.mmld files within the scripts directory of the project.
src/main/mmld ?

>  *Implementation Issues
>    [[1]] How do we make Maven smart enough to switch loader implementations based
>          on some sub-type of maven-plugin? 
Ok, this is superficial, but as I understand it, each mojo is 
independant, and a plugin is a block of mojos. So a plugin is just one 
type and can record the language of each mojo, and execute using the 
appropriate loader?

>    [[2]] How do we make the plugin:install process smart enough to switch 
>          generator implementations based on some sub-type of maven-plugin?
as above

>    [[3]] We should probably look into enforcing <<<org/apache/maven/plugins/$pluginId>>>
>          namespacing for plugin generation, to avoid the case where two plugins
>          are script-based, load from the context classloader, depend on one 
>          another's APIs, and have script names that collide.
I'm confused by this. I thought each plugin's classloader was separated, 
and deep integration such as what you talk about for aspectwerkz is not 
on. If AW needs to use some shared services, it would need to depend on 
a JAR, which may contain Java or some other Marmalade script as long as 
MMLD knows how to exec it, but never cross reference code from another 
running plugin.

>    [[4]] Do we want to allow mixed-bag plugin implementations? 
I think so. Being able to include arbitrary Java classes that can be 
accessed from Java Mojo's and MMLD Mojo's and so on is one thing, and I 
think essential. The other thing is being able to have Java Mojos and 
MMLD mojos in one script. This is less important, but still a nice to have.


View raw message