geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <linsun....@gmail.com>
Subject Re: [DISCUSS] enhance the assemble server portlet usability
Date Fri, 22 Aug 2008 13:24:19 GMT
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