Return-Path: 
 <m2-dev-return-2392-apmail-maven-m2-dev-archive=maven.apache.org@maven.apache.org>
Delivered-To: apmail-maven-m2-dev-archive@www.apache.org
Received: (qmail 59265 invoked from network); 9 Feb 2005 00:29:05 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur-2.apache.org with SMTP; 9 Feb 2005 00:29:05 -0000
Received: (qmail 76678 invoked by uid 500); 9 Feb 2005 00:29:05 -0000
Delivered-To: apmail-maven-m2-dev-archive@maven.apache.org
Received: (qmail 76658 invoked by uid 500); 9 Feb 2005 00:29:05 -0000
Mailing-List: contact m2-dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:m2-dev-help@maven.apache.org>
list-unsubscribe: <mailto:m2-dev-unsubscribe@maven.apache.org>
list-post: <mailto:m2-dev@maven.apache.org>
List-Id: "Maven 2 Developers List" <m2-dev.maven.apache.org>
Reply-To: "Maven 2 Developers List" <m2-dev@maven.apache.org>
Delivered-To: mailing list m2-dev@maven.apache.org
Received: (qmail 76639 invoked by uid 99); 9 Feb 2005 00:29:04 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from mail-05.iinet.net.au (HELO mail.iinet.net.au) (203.59.3.37)
  by apache.org (qpsmtpd/0.28) with SMTP; Tue, 08 Feb 2005 16:29:04 -0800
Received: (qmail 417 invoked from network); 9 Feb 2005 00:28:58 -0000
Received: from unknown (HELO ?10.1.1.27?) (203.217.68.43)
  by mail.iinet.net.au with SMTP; 9 Feb 2005 00:28:58 -0000
Message-ID: <42095947.5090209@apache.org>
Date: Wed, 09 Feb 2005 11:28:55 +1100
From: Brett Porter <brett@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Maven 2 Developers List <m2-dev@maven.apache.org>
Subject: Re: cvs commit:
 maven-components/maven-core/src/site/apt/scripting-support
 marmalade-support.apt
References: <20050208205148.60816.qmail@minotaur.apache.org>
In-Reply-To: <20050208205148.60816.qmail@minotaur.apache.org>
X-Enigmail-Version: 0.90.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Hi John,

This is looking pretty good!

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

jdcasey@apache.org 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.

Cheers,
Brett