geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [DISCUSSION] to create a set of maven archetypes for applications running on geronimo ?
Date Sat, 04 Apr 2009 17:15:50 GMT

On Mar 31, 2009, at 2:26 AM, Shawn Jiang wrote:

>
> On Tue, Mar 31, 2009 at 7:13 AM, David Jencks  
> <david_jencks@yahoo.com> wrote:
> I had a lot more thoughts on this subject while working up my  
> apachecon eu talk on geronimo server assemblies.
>
> Right now we have a _lot_ of deployer code that carefully examines  
> exactly what your app needs and depending on what it finds adds  
> dependencies to the classloader.  For instance if it figures out you  
> have a web app and it's the jetty deployer it adds the jetty car as  
> a parent.  (Some of the smaller deployer bits I think currently  
> always add their dependencies since there was a problem with  
> changing the classpath but I hope this can be fixed with the recent  
> configuration/classloader work).
>
> I think the plugin archetype should do this too.  You tell it what  
> app you are trying to deploy and some kind of profile like jetty/ 
> tomcat and cxf/axis2 and it (should) use the same logic as the  
> deployer to figure out what is needed.  For the archetype, it should  
> be adding the dependencies and deployer dependencies to the pom and  
> listing the deployer dependencies the car-maven-plugin needs to start.
>
> Great idea !  This will increase the usability of geronimo plugin  
> development remarkably from the user's perspective since this allow  
> the user to get the specific plugin only by selecting some simple  
> and understandable options.
>
>
> re stringtemplate vs. velocity.... I don't know enough about how the  
> archetype framework to judge whether anything except velocity is  
> plausible.
>
> As I know,  currently Maven Archetype only supports velocity as the  
> template.
>
> Are you actively working on this project?  If not I might see if  
> there's some fairly easy way to access the decision making the  
> current deployers use.
>
> I have not started doing this for some reasons.  It would be great  
> if you can help find the way to access the deployers decision making  
> API.

I have some ideas..... but I looked at the archetype framework and it  
doesn't look like it supports any way to run java code to help decide  
what to include in the generated project.  I've asked on the maven dev  
list for advice on how to proceed.

thanks
david jencks

>
>
> thanks!
> david jencks
>
> On Mar 17, 2009, at 1:26 AM, Shawn Jiang wrote:
>
>> It looks to me as if there are no plans in the javaee apps parts of  
>> the samples apps, so the plans are all in the plugin modules.  I  
>> really don't think we want to duplicate the functionality of the  
>> existing archetypes that do a fine job of creating projects for  
>> java ee apps.  If you really do want to help people make projects  
>> like the sample apps, the way to do that is to improve the plugin  
>> archetype.
>>
>> Thanks for your comments.  actually, what I said was to make the  
>> pom.xml and plan.xml template but not the JEE app itself.  For  
>> example:
>>
>> servlet-examples/
>> 		pom.xml
>> 		servlet-examples-jetty/
>> 			pom.xml
>> 			src/
>> 				main/
>> 					plan/
>> 						plan.xml			
>> 		servlet-examples-tomcat/
>> 		servlet-examples-war/
>>
>>  From this pespective, what I was talking about is to create  
>> plugins archetype instead of JEE app archetype.
>>
>>
>>  I like your ideas about what can be generated in the geronimo  
>> plan.  I think we can also generate a lot more of the pom than we  
>> do now.
>>
>> I agree.
>>
>> I would be very tempted to try stringtemplate instead of velocity.   
>> I think its clear MVC separation and roots in code generation  
>> technology (it's the output stage for antlr)  may prove useful for  
>> the manipulation we need to do.
>>
>> But how could we reuse the existing powerful maven archetype if  
>> using stringtemplate ?  I feel that StringTemplate is more useful  
>> in a MVC framework but not in a project generating  tool.  Do you  
>> agree ?
>>
>> While enabling people to reproduce our sample apps is probably  
>> better than what we do now, I'd prefer to help them with apps that  
>> actually do a realistic amount of work.  I think improving the  
>> plugin archetype would be a really big help.
>>
>> I suggest to start with the current sample plugins.   The final  
>> goal is to reduce most of the effort to release all samples for  
>> each geronimo version by providing stable archetype.
>>
>> thanks
>> david jencks
>>
>>
>>
>>
>>
>> On Tue, Mar 17, 2009 at 3:35 PM, David Jencks  
>> <david_jencks@yahoo.com> wrote:
>>
>> On Mar 16, 2009, at 11:50 PM, Shawn Jiang wrote:
>>
>>> From my point of view, every current geronimo sample could be  
>>> converted to a archetype. So that the user just needs install  
>>> maven and he could just type a command like this:
>>>
>>> mvn archetype:generate -DarcheTypeCatalog=http://geronimo.apache.org/archetypes/samples
>>>
>>> he will get a sample menu like this:
>>>
>>> Choose archetype:
>>> 1: internal -> hello (geronimo sample web application project)
>>> 2: internal -> calculator-stateless-pojo (geronimo sample ejb  
>>> project)
>>> 3: internal -> mdb (geronimo Message-Driven Bean sample project)
>>> 4: internal -> GBean(simple geronimo GBean project)
>>> 5: internal -> xxxx
>>> 6: internal -> xxxx
>>> 7: internal -> xxxx
>>>
>>> Choose a number:  (1/2/3/4/5/6/7) 1: : 1
>>>
>>> select "1" to create a hello sample project will bring him to a  
>>> wizard like this:
>>>
>>>
>>> Define value for geronimo_version: : 2.1.4
>>> Define value for context_root: : hellocontext
>>> Define value for groupId: : my.first.geronimo.web
>>> Define value for artifactId: : helloApp
>>> Define value for version:  1.0-SNAPSHOT: :
>>> Define value for package:  my.first.geronimo.web: :
>>> Confirm properties configuration:
>>> geronimo_version: 2.1.4
>>> context_root: hellocontext
>>> groupId: my.first.geronimo.web
>>> artifactId: helloApp
>>> version: 1.0-SNAPSHOT
>>> package: my.first.geronimo.web
>>>  Y: : Y
>>>
>>> notice the user could define which geronimo version he is using  
>>> and defind the context root when generating the application.  The  
>>> two values will be used to generate a geronimo-web.xml like this:
>>>
>>> <web-app xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-2.0.1"
>>>          xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2"
>>>          xmlns:sec="http://geronimo.apache.org/xml/ns/security-2.0"
>>>          xmlns:sys="http://geronimo.apache.org/xml/ns/ 
>>> deployment-1.2">
>>>
>>>   <sys:environment>
>>>     <sys:moduleId>
>>>       <sys:groupId>my.first.geronimo.web</sys:groupId>
>>>       <sys:artifactId>helloApp</sys:artifactId>
>>>       <sys:version>1.0-SNAPSHOT</sys:version>
>>>       <sys:type>car</sys:type>
>>>     </sys:moduleId>
>>>     <sys:dependencies>
>>>        <!--some dependency on geronimo 2.1.4 here>
>>>     </sys:dependencies>
>>>     <sys:hidden-classes/>
>>>     <sys:non-overridable-classes/>
>>>   </sys:environment>
>>>
>>>   <context-root>/hellocontext</context-root>
>>>
>>> </web-app>
>>>
>>>
>>> I can see following benefits by creating these kind of sample  
>>> archetypes:
>>>
>>> 1, User does not need to install a subversion to get the samples  
>>> or to download the samples zip.
>>> He just need to install a maven to get all kinds of samples  
>>> whatever he wants.
>>>
>>> 2, geronimo version could be provided at sample project generating  
>>> time.
>>> As I know, most of samples content does not change at all except  
>>> those geronimo version update.  To keep these "stable" samples to  
>>> archetypes can save the time to
>>> maintain every samples per geronimo release.  (of course, for  
>>> those unstable samples, we still need to update them per geronimo  
>>> release)
>>>
>>> 3, Other key properties in geronimo deployment plan could be  
>>> provided at sample project generating time.
>>> This is helpful for user to understand the essential elements of  
>>> geronimio deployment plan.
>>>
>>> Current maven archetype is using velocity template which is very  
>>> powerful to generate project contents based on user's input.
>>
>> It looks to me as if there are no plans in the javaee apps parts of  
>> the samples apps, so the plans are all in the plugin modules.  I  
>> really don't think we want to duplicate the functionality of the  
>> existing archetypes that do a fine job of creating projects for  
>> java ee apps.  If you really do want to help people make projects  
>> like the sample apps, the way to do that is to improve the plugin  
>> archetype.  I like your ideas about what can be generated in the  
>> geronimo plan.  I think we can also generate a lot more of the pom  
>> than we do now.
>>
>> I would be very tempted to try stringtemplate instead of velocity.   
>> I think its clear MVC separation and roots in code generation  
>> technology (it's the output stage for antlr)  may prove useful for  
>> the manipulation we need to do.
>>
>> While enabling people to reproduce our sample apps is probably  
>> better than what we do now, I'd prefer to help them with apps that  
>> actually do a realistic amount of work.  I think improving the  
>> plugin archetype would be a really big help.
>>
>> thanks
>> david jencks
>>
>>>
>>>
>>> On Tue, Mar 17, 2009 at 1:41 AM, David Jencks <david_jencks@yahoo.com 
>>> > wrote:
>>>
>>> On Mar 16, 2009, at 12:18 AM, Shawn Jiang wrote:
>>>
>>>> Maven archetype is a powerful tools to make life easier when  
>>>> developers want to create a project from scratch.  Currently,  
>>>> Geronimo is using archetype to create new testsuite/assembly/ 
>>>> plugin/ quickly.
>>>>
>>>> 1: local -> geronimo-archetype-testsuite (testsuite)
>>>> 2: local -> geronimo-assembly-archetype (geronimo-assembly- 
>>>> archetype)
>>>> 3: local -> geronimo-plugin-archetype (geronimo-plugin-archetype)
>>>> 4: local -> xmlbeans-maven-plugin (xmlbeans-maven-plugin)
>>>>
>>>> Which can only help geronimo developers/contributors when they  
>>>> want to create their new testsuite/assembly/plugin.  There's no  
>>>> archetype for geronimo users who want to create their geronimo  
>>>> Apps/Assets easily from scratch.   I'm wondering if geronimo  
>>>> could provide a set of new archetypes for Apps/assets running in  
>>>> geronimo. Some initial candidates are:
>>>>
>>>> 1, war-geronimo-archetype
>>>> A simple war which contains the geronimo deployment plan.
>>>>
>>>> 2, ear-geronimo-archtype
>>>> A maven project that contains 4 modules:
>>>>  1, a war module
>>>>  2, a ear module
>>>>  3, a ejb module
>>>>  4, a client module.
>>>>
>>>> 3, datasource-geronimo-archtypes
>>>> There should be many sub archtypes to create different  
>>>> datasources plan.
>>>>
>>>> 4, security-geronimo-archtypes
>>>> There should be many sub archtypes to create different(properties/ 
>>>> db/ldap) realms.
>>>>
>>>> 5, GBean-geronimo-archtype
>>>> A simple GBean development archtype with two mode: normal/ 
>>>> annotation
>>>>
>>>> Any comments ?
>>>
>>> I don't quite understand yet what these archetypes would provide.   
>>> The most plausible thing would be to add a "fill in the blanks"  
>>> plan template.  I'm not sure an archetype is the best way to do  
>>> this, but I'm certainly open to seeing how it works.
>>>
>>> Our existing plugin and assembly archetypes are rather obsolete  
>>> and don't use the current archetype infrastructure.  I wonder if a  
>>> more practical project would be to update especially the plugin  
>>> archetype to figure out what kind of thing you are building a  
>>> plugin for and include the appropriate plan template and add the  
>>> appropriate dependencies and car-maven-plugin configuration.
>>>
>>> I guess if we could figure out how to this more or less the same  
>>> logic could be used to modify an existing javaee maven project to  
>>> insert the appropriate geronimo plan template in the appropriate  
>>> directory.  I don't think that dupicating the war, ear, etc  
>>> archetypes is likely to be worth the effort.
>>>
>>> Anyway I'd certainly like to know more about what you have in mind  
>>> and am very glad someone else is thinking about maven archetype  
>>> support!
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Shawn
>>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> Shawn
>>
>>
>>
>>
>> -- 
>> Shawn
>
>
>
>
> -- 
> Shawn


Mime
View raw message