See inlined comments. Since it seems that we're both in basic agreement,
I'll proceed with this general plan and make adjustments where need be
later.
Brett Porter 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.
>
So what you're saying is put in some type of comment with embedded XML
for things like janino, beanshell, and groovy? Then, I suppose we could
put a parser in place that's non-specific to any type of script,
providing we can tie each type to a component-factory reliably...
Another option to implement the descriptor annotations for non-marmalade
(that is, java-syntax-based) might be to have a base class or interface
from which all mojo scripts inherit. I've looked around, and this is
technically possible in janino and beanshell, and jason tells me it's
possible in groovy as well. One thing about creating a GUI mojo editor
is that unless we're going to provide syntactic support for all of our
supported mojo scripting languages, it's not going to bring much value...
>> <requiresDependencyResolution/>
>>
>>
> If using this, I'd make it a boolean element rather than test existence.
> Modello probably likes it better anyway :)
Yeah, that's just John-speak for "optional element". I'd definitely
prefer some way of specifying a concrete boolean value for these.
>
> I'd still like to consider the use of attributes in this sort of area if
> possible to make it less verbose.
I've always been in favor of using xml attributes for this type of
stuff, but if we're not changing the POM syntax, I'd oppose this. It
will only confuse developers if we're inconsistent.
>
> 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 ?
Do we provide <marmaladeSourceDirectory/>? If so, should we think about
binding this setting to the marmalade-mojo mojos, to make the POM scale
a little better? I'd hate to have to include <janinoSourceDirectory/>,
<beanshellSourceDirectory/> and <groovySourceDirectory/>...
>
>> *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?
Yeah, that's definitely something we could code into the plugin loader.
I guess we'd have to hand the plugin loader a mapping of
languages-to-mojoLoaders, but that's no real problem.
>
>> [[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
This is a little harder, unless we're going to have mojo developers bind
the specific generators to part of the lifecycle...and even then, we
need to setup some inter-generator aggregator for MojoDescriptor's, so
that at the end of the generation lifecycle phase we can puke one plugin
descriptor file out to META-INF/maven/plugin.xml. We can provide a
default lifecycle with all generators bound, but we still have the same
problem with aggregation of all generated mojo descriptors.
>
>> [[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.
>
We'll strike it from the record, then. :)
>> [[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.
Agreed.
>
> Cheers,
> Brett
>
>
>