geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [DISCUSS] enhance the assemble server portlet usability
Date Fri, 22 Aug 2008 16:05:07 GMT
This seems good, but don't we currently include both webservice   
implementations in both javaee servers ,allowing you to swtich with a  
command line property?

a small detail
david jencks

On Aug 22, 2008, at 6:24 AM, 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 <>  
> 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 <>  
>> 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=" 
>>> "
>>> xmlns:ns2="">
>>>   <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></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

View raw message