maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: cvs commit: maven-components/maven-core/src/site/apt/scripting-support marmalade-support.apt
Date Wed, 09 Feb 2005 01:11:45 GMT
John Casey wrote:

> 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.

Sounds good.

>
> 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...

urgh! No, not really :) I meant there's a case for having the xml 
metadata separate from the script. I'm not passionate about this either 
way, and I think its fine to include in the script for marmalade and we 
can consider more when we get to the next scripting language (I feel 
beanshell or javascript may be the best next one?). Just don't put any 
roadblocks to having it separate :)

>
> 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...

Right, but if someone else provides support for said language (at least 
groovy are pushing this), then it'd be good if we don't have to do 
additional work on top of that.

>>
>> 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.

Right, I see what you mean. There's a point - does this stuff belong in 
the POM? Hmm... the answer to that is probably whether the information 
is needed without downloading/loading the plugin.

>>>
>>>
>> 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/>...

I need to push out another document I have that just allows multiple 
languages in the POM. marmaladeSourceDirectory might be fine for now?

>
> 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.

Right, I see where you are coming from. This, like the previous one, get 
to the heart of the lifecycle stuff we are discussing. Perhaps for now, 
we can allow a little hardwiring with a note to incorporate this when we 
come back?

Thanks John!

Cheers,
Brett

Mime
View raw message