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
>>>>>
>>
|