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: [DISCUSS] enhance the assemble server portlet usability
Date Mon, 25 Aug 2008 22:00:46 GMT

On Aug 25, 2008, at 2:30 PM, Lin Sun wrote:

> I agree with David that I think what you are proposing could be
> achieved using the geronimo plugin group concept.
>
> I have been working on/trying out things with the plugin group lately.
>  On my local machine, I can create a plugin group for the Web-tomcat
> using c-m-p, and have it built into my tomcat javaee5 assembly.
>
> Then I made some code change to the plugin portlet to allow users to
> select this plugin group and use it to assemble a custom server that
> is equivalent to little G tomcat.    My current workaround is to set
> the module-id of the plugin group to null if the plugin category is
> "Geronimo Plugin Groups" thus only plugin dependencies are installed.
> With that, the module is not registered in the config.xml in the
> custom server.  (the better approach is to investigate how to do step
> 1 in David's note.)
>
> I plan to develop more geronimo plugin groups (plan to put there at
> the same level as framework, assemblies, plugins directory) for other
> functions, such as JMS, web-jetty, Web services CXF, etc.
>
> I think it would be nice, if we can figure out how to use these
> geronimo plugin groups to build our assemblies (such as Little G,
> javaee5, etc), using maven or other tool.

I'd expect we'd just list the single plugin group for the server as  
the only dependency.  I think that we've been listing all the plugins  
that go into a server rather than a minimal set simply so we'd have a  
complete list of what was in the server.  This might not be such a  
good idea :-).

thanks
david jencks

>
>
> Lin
>
>
>
>
> On Mon, Aug 25, 2008 at 3:12 PM, Jay D. McHugh  
> <jaydmchugh@gmail.com> wrote:
>> Hey all,
>>
>> I have been trying to get my thought straight on profiles/templates.
>> And, I think I just might have done it (we'll see).  Warning, there  
>> is
>> very little 'implementation' here - mostly food for thought.
>>
>> First of all, I think that it would be useful to have several ways of
>> thinking about groups of modules.  Right now, we have maven artifacts
>> and plugins (that are groups of artifacts).  In this discussion, we  
>> are
>> trying to figure out how to divide/build up a server.  And, the  
>> idea of
>> profiles came up to group plugins that are necessary for a particular
>> function.
>>
>> So far, I like everything about the direction that the discussion is
>> going.  But, I have two ideas that I think might improve the
>> managability of server building/configuration.
>>
>> The first involves adding a list of profiles that the different
>> Gernonimo modules/artifacts would 'satisfy' into the pom's.  That  
>> would
>> enable us to stay away from manually building/rebuilding the list of
>> default included ('provided by Geronimo') profiles.
>>
>> The second would be to add one more level of grouping artifacts -
>> templates.  The idea would be that profiles group modules that  
>> provide a
>> particular function and templates would group profiles that (when
>> combined) provide a particular server.
>>
>> For example, right now, we provide five distinct 'flavors' of  
>> Geronimo:
>> minimal (framework), little-G (tomcat), little-G (jetty), JEE5  
>> (tomcat),
>> and JEE5 (jetty).  Those would correspond to five 'provided'  
>> templates
>> for Geronimo.
>>
>> As an (extremely oversimplified) example, here is what the little-G
>> template might look like:
>>
>> <template id='little-g-tomcat'>
>> <description>Geronimo Tomcat Little-G Server</description>
>> <version>2.1.2</version>
>> <includesProfile>
>>   <!-- full function profiles -->
>>   <profile id='geronimo framework' version='x.x' />
>>   <profile id='tomcat web container' version='x.x' />
>> </includesProfile>
>> <includesPlugin>
>>   <!-- individual plugins, either provided or 'customer specific' -->
>> </includesPlugin>
>> <includesArtifact>
>>   <!-- individual libraries -->
>> </includesArtifact>
>> </template
>>
>> A template like this would be relatively easy for either a program or
>> user to build and allows for almost unlimited customizability in
>> describing what should go into building a server.  Then, rather than
>> having our server assembly portlet actually do the work of making an
>> actual server - it could simply output the template.  Or, we could  
>> have
>> a new option that would allow for template creation and export (ie:
>> export current server as template).
>>
>> Then we could either check the currently assembled server against the
>> template (and pull down whatever profiles/plugins are needed) or  
>> have a
>> 'load template' function that would apply the template to a new
>> (presumably framework only) server.
>>
>> Thoughts?
>>
>> Jay
>>
>> Lin Sun wrote:
>>> Here is what I am thinking.   Let me take the Web profile as an  
>>> example:
>>>
>>> So we want to allow users to check/select the Web profile to select
>>> all the necessary geronimo plugins for little G.   Users would only
>>> see Web profile, instead the 10+ geronimo plugins.
>>>
>>> -------------------------------------------------
>>> Select from the following Profiles/Plugin Groups:
>>> __ Web (when this selected, we'll install the 10+ geronimo plugins  
>>> for
>>> the user to get little G env.)
>>> __ Web Service
>>> ...
>>> -------------------------------------------------
>>>
>>> In order to do this, we'll need to know which geronimo plugins can  
>>> get
>>> the users to the Web profile and store this relatonship somewhere  
>>> that
>>> is avail for both admin console and command line custom  
>>> assembly.   I
>>> come to the conclusion that we need some sort of group of plugins
>>> function and David reminded me about the geronimo-plugin.xml that  
>>> has
>>> no module-id can work as group of plugins.   Here is the wording  
>>> from
>>> the schema:
>>>
>>> If no module-id is provided, that means this is a plugin group,  
>>> which
>>> is just a list of other plugins to install.
>>>
>>> With that, I can just build a geronimo plugin group for web profile
>>> and have the 10+ geronimo plugins listed as dependencies.   This
>>> geronimo plugin group can be available as part of the assmebly,  
>>> along
>>> with the other geronimo plugin groups.
>>>
>>> The idea is that if a user selects Web profile in either admin  
>>> console
>>> or command line, we can just select the corresponding geronimo  
>>> plugin
>>> group behind the scene, which would install all its dependencies.
>>>
>>> Now back to the web services sample, we 'll have 2 web service  
>>> plugin groups:
>>>
>>> web service CXF - cxf and cxf-deployer
>>> web service Axis2 - axis2 and axis2-deployer
>>>
>>> The web service Jetty plugin group will be included in the jetty
>>> javaee5 assembly and web service tomcat plugin group will be  
>>> included
>>> in the tomcat javaee5 assembly.   Initially, I plan to only support
>>> custom server assembly from the current local server, so when user  
>>> has
>>> jetty assembly, he will see web service CXF.   When user has tomcat
>>> assembly, he'll see web service Axis2.   In the long run, we could
>>> present both to the users and they can just pick either one.
>>>
>>> I hope above addressed your questions.   Please feel free to let me
>>> know any other comments you may have.
>>>
>>> Lin
>>>
>>> On Thu, Aug 21, 2008 at 11:57 PM, Jarek Gawor <jgawor@gmail.com>  
>>> wrote:
>>>> Hmm.. I'm not sure how this profile idea fits in with what the user
>>>> have to select in the "assemble a server" portlet. Would there be a
>>>> profile for axis2 that only has two plugins axis2 and axis2- 
>>>> deployer
>>>> defined? And there would be a similar profile with two plugins for
>>>> cxf? And the user would either pick the axis2 or cxf profile and
>>>> combine it with the jetty or tomcat profile? I'm just not sure how
>>>> this relates to the steps the user would have to go through in the
>>>> portlet to create the desired server.
>>>>
>>>> Jarek
>>>>
>>>> On Tue, Aug 19, 2008 at 4:20 PM, Lin Sun <linsun.unc@gmail.com>  
>>>> wrote:
>>>>> I have been thinking a bit more on how we achieve this.   Here  
>>>>> is my
>>>>> idea and I welcome your input -
>>>>>
>>>>> So we have a need to allow users to install groups of  
>>>>> plugins(function
>>>>> profile), instead of individual plugins.   Install individual  
>>>>> plugins
>>>>> are nice for standalone apps, but for system modules, I think it  
>>>>> would
>>>>> be better to allow users to install groups of plugins as  
>>>>> functional
>>>>> profiles(unless the user is an expert user).    What we need is to
>>>>> expose the groups of plugins for certain functions available to  
>>>>> our
>>>>> users and allow them to select the ones of their interest to  
>>>>> build the
>>>>> customer server.
>>>>>
>>>>> I am proposing in addition to store plugin metadata of each  
>>>>> plugin in
>>>>> the plugin catalog, we could also host installable groups of  
>>>>> plugins
>>>>> information there (or in a separate catalog file).   For  
>>>>> example, for
>>>>> a function such as Web (same as little G) that has been  
>>>>> discussed in
>>>>> above posts, we could have the following plugin metadata -
>>>>>
>>>>> <geronimo-plugin xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3

>>>>> "
>>>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2">
>>>>>   <name>Geronimo Assemblies :: Minimal + Tomcat</name>
>>>>>   <category>WEB Profile</category>
>>>>>   <profile>true</profile>
>>>>>   <description>A minimal Geronimo server (Little-G) assembly using
>>>>> the Tomcat web-container.</description>
>>>>>   <url>http://www.apache.org/</url>
>>>>>   <author>Apache Software Foundation</author>
>>>>>   <license osi-approved="true">The Apache Software License,  
>>>>> Version
>>>>> 2.0</license>
>>>>>   <plugin-artifact>
>>>>>       <module-id>
>>>>>           <groupId>org.apache.geronimo.assemblies</groupId>
>>>>>           <artifactId>geronimo-tomcat6-minimal</artifactId>
>>>>>           <version>2.2-SNAPSHOT</version>
>>>>>           <type>car</type>
>>>>>       </module-id>
>>>>>       <geronimo-version>2.2-SNAPSHOT</geronimo-version>
>>>>>       <jvm-version>1.5</jvm-version>
>>>>>       <jvm-version>1.6</jvm-version>
>>>>>
>>>>>       <dependency>
>>>>>           <groupId>org.apache.geronimo.assemblies</groupId>
>>>>>           <artifactId>geronimo-boilderplate-minimal</artifactId>
>>>>>           <version>2.2-SNAPSHOT</version>
>>>>>           <type>jar</type>
>>>>>       </dependency>
>>>>>
>>>>>       <dependency start="false">
>>>>>           <groupId>org.apache.geronimo.framework</groupId>
>>>>>           <artifactId>upgrade-cli</artifactId>
>>>>>           <version>2.2-SNAPSHOT</version>
>>>>>           <type>car</type>
>>>>>       </dependency>
>>>>>
>>>>>       <dependency start="true">
>>>>>           <groupId>org.apache.geronimo.framework</groupId>
>>>>>           <artifactId>rmi-naming</artifactId>
>>>>>           <version>2.2-SNAPSHOT</version>
>>>>>           <type>car</type>
>>>>>       </dependency>
>>>>>
>>>>>       <dependency start="true">
>>>>>           <groupId>org.apache.geronimo.framework</groupId>
>>>>>           <artifactId>j2ee-security</artifactId>
>>>>>           <version>2.2-SNAPSHOT</version>
>>>>>           <type>car</type>
>>>>>       </dependency>
>>>>>
>>>>>       <dependency start="true">
>>>>>           <groupId>org.apache.geronimo.configs</groupId>
>>>>>           <artifactId>tomcat6</artifactId>
>>>>>           <version>2.2-SNAPSHOT</version>
>>>>>           <type>car</type>
>>>>>       </dependency>
>>>>> ...
>>>>>
>>>>> When a plugin is a profile, it means it just contains a group of
>>>>> geronimo plugin dependencies that are installable and can perform
>>>>> certain functions.  By installing it, it will simply install the
>>>>> dependency plugins.
>>>>>
>>>>> Questions -
>>>>>
>>>>> How do we build this profile type of plugin?   We could build them
>>>>> manually initially to try things but maybe c-m-p could be used  
>>>>> here.
>>>>> How do we install this profile type of plugin?  I think we could
>>>>> leverage the pluginInstallerGBean to install it...when profile is
>>>>> true, we just download the dependencies.
>>>>> How/Where should we make this file avail?   We could make this  
>>>>> file
>>>>> avail in geronimo-plugins.xml (or another catalog file in repo)  
>>>>> and
>>>>> with our server assembly (one assembly contains the plugin  
>>>>> profiles it
>>>>> have).  When building customer server, when load all the plugins  
>>>>> that
>>>>> are profile and ask users to pick which ones they want.   If we  
>>>>> have a
>>>>> framework that can install geronimo plugins, a user can just  
>>>>> download
>>>>> the framework and pick from our apache repo on which plugin  
>>>>> profiles
>>>>> they want to build their geronimo server.
>>>>> How are we handle the upgrade scenarios Joe mentioned?   No idea
>>>>> yet... I think this is a rather complicated scenario.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Lin
>>>>>
>>


Mime
View raw message