You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Lin Sun <li...@gmail.com> on 2008/08/11 17:50:50 UTC
[DISCUSS] enhance the assemble server portlet usability
Hi,
I'd like to enhance the assemble server portlet's usability.
Currently it is hard to come up with a desired custom server assembly.
For example, I want to create a custom server that provides similar
function as tomcat. To do this, I picked the boilerplate-minimal,
tomcat and tomcat-deployer to build my custom server. However, soon I
found out that I am not able to deploy anything to the server, as I
didn't select any plugins to enable command deployer or hot deployer
or console deployer or gshell deployment. So I went back to the
assemble server portlet and I saw so many plugins related to
deployment, by looking at the plugins under the Deployment category-
org.apache.geronimo.framework/upgrade-cli/2.1.2/car
org.apache.geronimo.framework/jsr88-cli/2.1.2/car
org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
org.apache.geronimo.framework/offline-deployer/2.1.2/car
org.apache.geronimo.framework/online-deployer/2.1.2/car
org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
Which one do I pick? I don't want to select any extra ones... I just
want to enable command line deployer for war modules. By poking
around the pom.xml files, I think I only need to select
org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
boilerplate-minimal, tomcat and tomcat-deployer.
To improve the usability, I suggest the following:
>From the assemble server portlet, a user can choose what type of
customer assembly he/she wants to build:
- Functional custom assembly
- Application scope custom assembly
- Advanced configuration
Selecting "Function custom assembly" will lead to selection of key
functions of the server, and we can use the category of plugins to
associate functions and plugins. Instead of displaying all the
plugins, we group the plugins by their function(category) and display
the function only. I think it would be nice to see some explanation
of each function. For example:
- Geronimo Core - plugins that provide the core service of the
geronimo server...
- Web Services - plugins that provides the web service stack of the
geronimo server...
- Deployment - plugins that enables you to deploy apps onto the server...
...
If desired, users have the option to see what plugins are associated
with a function, such as Geronimo Core. Also, if we want to provide
detailed functions, we can update the category to be more accurate,
such as Deployment: Offline Deployment, Deployment : Command Line
Deployer, Deployment: Hot Deploy, etc.
Selecting "Application scope custom assembly" will lead to selection
of custom applications deployed to the server. We can also warn our
users that the custom server may not be able to deploy anything.
Selecting "Advanced configuration" will lead to the current assemble
server page that allows a user to select plugins from all the plugins
in local server. This assumes the user knows the plugins in local
server well.
For all options, we should always display the pre-selected
boilerplate-minimal.
Comments are welcome! If there is no objection, I'll start working on this.
Lin
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Yes I agree that we should also improve the usability of the command
based scenarios. Whatever we discussed and agreed here can be used
for the command based scenarios.
Lin
On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller <ke...@gmail.com> wrote:
> My one comment, at the moment, is the discussion may be too focused on the
> admin console. I'd like to be sure we also include command-based scenarios
> as well (and even maven?). IMO, we should permit the same basic abstractions
> (at least for the command-based scenario).
>
> --kevan
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
Sounds like a good approach.
-Donald
David Jencks wrote:
>
> On Aug 12, 2008, at 12:47 PM, Lin Sun wrote:
>
>> Thanks again for the valuable feedback - Donald and Kevan!
>>
>> If profile is what people are interested in, we need to identify what
>> profiles we want to provide and the plugins that each profile
>> contains. We also want to think what type(s) of deployment we want
>> to provide with these profiles. Do we always provide the command
>> line deployment with the profiles, or hot deployment, or console
>> deployment or gshell deployment, or we always provide all the
>> deployment options for each of the profile? I am sure there are other
>> options/variables.
>>
>> Here are some possible profiles -
>>
>> - Web (our minimal assembly today)
>> - Web + JMS
>> - Web + EJB
>> - Web + Web Services
>> - Web + EJB + Persistence
>> - Web + Admin Console
>> - Web + JMS + Admin Console
>> - Web + EJB + Admin Console
>> - Web + JSF
>> - Web + Clustering
>
> client profiles might be apropriate too.
>
> I wonder how much of this is actually necessary? e.g. if you install
> the jetty-deployer plugin you get jetty too. If you install the
> jetty-console you get jetty....
>
> What if we had a "select the parts" page that was organized differently
> than the list of plugins.... e.g. checkboxes for web, ejb, webservices.
> If you say yes to web, you get to choose jetty/tomcat, whether you want
> deployment, whether you want the console.
>
> Choosing web or ejb gives you the opportunity to include openjpa ( or
> maybe toplink in the future)
> Choosing webservices gives you the choice of cxf or axis2
>
>
> Just some more or less random thoughts
> david jencks
>
>>
>> ...
>>
>> I think it could be too much combinations than we can handle, unless
>> we can identify the exact profiles that users will likely want.
>>
>> If we allow users to pick profiles, it is nice we provide users with
>> profiles that we can test and verify first. However, the user may end
>> up not seeing the function combination he desires.
>>
>> If we allow users to pick functions (a function is a group of
>> plugins), the user will have the maximum flexibility and we can still
>> test the common combination of functions (which is same as profiles).
>>
>> Lin
>>
>>
>>
>>
>>
>> On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller <ke...@gmail.com>
>> wrote:
>>>
>>> On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
>>>
>>>> Keeping 3 starting paths is fine, but we need to make sure we reuse the
>>>> same portlet views throughout.
>>>>
>>>> Also, I've heard second hand from other community members (like Kevan -
>>>> cough cough) that they have talked to end users who wanted
>>>> simplified/tested
>>>> profiles to use for assembling servers (like Web + JMS). If we provide
>>>> application and advanced paths, then we also need to provide a
>>>> profile/function path, which would allow companies/ISVs to create
>>>> custom
>>>> packages tailored to different development groups that only contain the
>>>> function they need.
>>>
>>> :-) I have had conversations where that was requested and seem to recall
>>> musing/wishing for this in the past...
>>>
>>> Glad to see this discussion occurring.
>>>
>>> I like the concept of profiles.
>>>
>>> My one comment, at the moment, is the discussion may be too focused
>>> on the
>>> admin console. I'd like to be sure we also include command-based
>>> scenarios
>>> as well (and even maven?). IMO, we should permit the same basic
>>> abstractions
>>> (at least for the command-based scenario).
>>>
>>> --kevan
>>>
>>>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Right, I was thinking in that single plugin group, we can use the
other plugin groups. For example, if I want to build the plugin group
for tomcat-javaee5, instead of having individual geronimo plugins as
its dependencies, I can use web-tomcat, jms, webservices-axis2,
openejb, jsf, persistence, console, and other plugin groups as its
dependencies.
Lin
On Mon, Aug 25, 2008 at 6:00 PM, David Jencks <da...@yahoo.com> wrote:
> 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
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
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
> <ja...@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 <jg...@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 <li...@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
>>>>>
>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
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.
Lin
On Mon, Aug 25, 2008 at 3:12 PM, Jay D. McHugh <ja...@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 <jg...@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 <li...@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
>>>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
David Jencks wrote:
>
> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>
>> I appreciate your valuable feedback!
>>
>> Currently, a user doesn't have that much choices, as we only allow the
>> user to assemble a new server out of plugins in local server, unless
>> we want to change this behavior.
>>
>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>> only choose tomcat + axis2. If a user installs the
>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>
> true... for now :-)
>>
>>
>> To simplify things, here is what I suggest. We allow the users to
>> choose from -
>>
>> __ Web
> __jsp
>>
>> __ JMS
>> __ Web Services
>> __ EJB
>> __ OpenJPA
>> __ Deployment
>> __ Admin Console
>> __ Cluster (tomcat only?)
> __wadi clustering
>>
>>
>> Then the user can just select one or more functions they need and
>> request for the customer assembly server to be created. Optionally,
>> the user can add on additional deployed apps or other system modules
>> then request for the customer assembly server to be created.
>
> I wonder if we can think bigger :-)
>
> What if we distributed something with _all_ the cars in it and
> customizable profiles for the servers we ship now? So, you wouldn't
> unpack a particular server, but the server construction kit. You could
> pick a profile and optionally modify it, then spit out the desired
> server. Then you would be able to pick jetty/tomcat and cxf/axis2 and
> however much deployment you wanted.
Couldn't we consider the maven repos as our server construction kit?
Seems that if users want this level of customization (building a server
from pieces instead of from an already working server) then using the
car-maven-plugin to build a server would be the preferred path.
>
> Alternatively maybe the "assemble a server" can show plugins from more
> than just the current server.
>
> thanks
> david jencks
>
>
>
>>
>>
>> Lin
>>
>> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>> client profiles might be apropriate too.
>>>
>>> I wonder how much of this is actually necessary? e.g. if you install
>>> the
>>> jetty-deployer plugin you get jetty too. If you install the
>>> jetty-console
>>> you get jetty....
>>>
>>> What if we had a "select the parts" page that was organized
>>> differently than
>>> the list of plugins.... e.g. checkboxes for web, ejb, webservices.
>>> If you
>>> say yes to web, you get to choose jetty/tomcat, whether you want
>>> deployment,
>>> whether you want the console.
>>>
>>> Choosing web or ejb gives you the opportunity to include openjpa ( or
>>> maybe
>>> toplink in the future)
>>> Choosing webservices gives you the choice of cxf or axis2
>>>
>>>
>>> Just some more or less random thoughts
>>> david jencks
>>>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
I would be in favor of this - stay focus for the 2.2 release first.
I do appreciate many ideas proposed here which always challenge me to
think outside of the box! :) We should revisit these ideas (server
construction kit, assembly server from not only local current server,
but also local repo or remote repo...) in the near future.
Lin
On Wed, Aug 13, 2008 at 8:21 AM, Donald Woods <dw...@apache.org> wrote:
> Let's stay focused on what can be done for the current custom server
> assemblies support in 2.2 for this thread versus new features, like the
> server construction kit (which can be done today via c-m-p and the maven
> repos.)
>
> Need to also think about adding some unit tests in the testsuite to verify
> the function works automatically for both the console and cmdine.
>
> For the profiles, lets start with 2 or 3, so we can get all of the UI and
> tests flushed out. I'd still suggest -
> Web (identical to minimal assembly - Servlets+JSP+JSF)
> Web + JMS
> If someone wants EJB or JPA, they can use the full assembly until we get
> additional profiles created and verified.
>
>
> -Donald
>
>
> Lin Sun wrote:
>>
>> Thanks for updating the key function list.
>>
>> Your big idea is very interesting... Also, It is possible we just
>> distribute the server construction kit, and a user could just select
>> profiles/plugins from a remote repo to assemble a desired custom
>> server. I wonder if we could revisit this post 2.2, or after we
>> finish the usability improvement of the custom assembly.
>>
>> Lin
>>
>> On Tue, Aug 12, 2008 at 6:11 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>>>
>>>> I appreciate your valuable feedback!
>>>>
>>>> Currently, a user doesn't have that much choices, as we only allow the
>>>> user to assemble a new server out of plugins in local server, unless
>>>> we want to change this behavior.
>>>>
>>>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>>>> only choose tomcat + axis2. If a user installs the
>>>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>>>
>>> true... for now :-)
>>>>
>>>> To simplify things, here is what I suggest. We allow the users to
>>>> choose
>>>> from -
>>>>
>>>> __ Web
>>>
>>> __jsp
>>>>
>>>> __ JMS
>>>> __ Web Services
>>>> __ EJB
>>>> __ OpenJPA
>>>> __ Deployment
>>>> __ Admin Console
>>>> __ Cluster (tomcat only?)
>>>
>>> __wadi clustering
>>>>
>>>> Then the user can just select one or more functions they need and
>>>> request for the customer assembly server to be created. Optionally,
>>>> the user can add on additional deployed apps or other system modules
>>>> then request for the customer assembly server to be created.
>>>
>>> I wonder if we can think bigger :-)
>>>
>>> What if we distributed something with _all_ the cars in it and
>>> customizable
>>> profiles for the servers we ship now? So, you wouldn't unpack a
>>> particular
>>> server, but the server construction kit. You could pick a profile and
>>> optionally modify it, then spit out the desired server. Then you would
>>> be
>>> able to pick jetty/tomcat and cxf/axis2 and however much deployment you
>>> wanted.
>>>
>>> Alternatively maybe the "assemble a server" can show plugins from more
>>> than
>>> just the current server.
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>>>
>>>> Lin
>>>>
>>>> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>
>>>>> client profiles might be apropriate too.
>>>>>
>>>>> I wonder how much of this is actually necessary? e.g. if you install
>>>>> the
>>>>> jetty-deployer plugin you get jetty too. If you install the
>>>>> jetty-console
>>>>> you get jetty....
>>>>>
>>>>> What if we had a "select the parts" page that was organized differently
>>>>> than
>>>>> the list of plugins.... e.g. checkboxes for web, ejb, webservices. If
>>>>> you
>>>>> say yes to web, you get to choose jetty/tomcat, whether you want
>>>>> deployment,
>>>>> whether you want the console.
>>>>>
>>>>> Choosing web or ejb gives you the opportunity to include openjpa ( or
>>>>> maybe
>>>>> toplink in the future)
>>>>> Choosing webservices gives you the choice of cxf or axis2
>>>>>
>>>>>
>>>>> Just some more or less random thoughts
>>>>> david jencks
>>>>>
>>>
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
Let's stay focused on what can be done for the current custom server
assemblies support in 2.2 for this thread versus new features, like the
server construction kit (which can be done today via c-m-p and the maven
repos.)
Need to also think about adding some unit tests in the testsuite to
verify the function works automatically for both the console and cmdine.
For the profiles, lets start with 2 or 3, so we can get all of the UI
and tests flushed out. I'd still suggest -
Web (identical to minimal assembly - Servlets+JSP+JSF)
Web + JMS
If someone wants EJB or JPA, they can use the full assembly until we get
additional profiles created and verified.
-Donald
Lin Sun wrote:
> Thanks for updating the key function list.
>
> Your big idea is very interesting... Also, It is possible we just
> distribute the server construction kit, and a user could just select
> profiles/plugins from a remote repo to assemble a desired custom
> server. I wonder if we could revisit this post 2.2, or after we
> finish the usability improvement of the custom assembly.
>
> Lin
>
> On Tue, Aug 12, 2008 at 6:11 PM, David Jencks <da...@yahoo.com> wrote:
>> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>>
>>> I appreciate your valuable feedback!
>>>
>>> Currently, a user doesn't have that much choices, as we only allow the
>>> user to assemble a new server out of plugins in local server, unless
>>> we want to change this behavior.
>>>
>>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>>> only choose tomcat + axis2. If a user installs the
>>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>> true... for now :-)
>>>
>>> To simplify things, here is what I suggest. We allow the users to choose
>>> from -
>>>
>>> __ Web
>> __jsp
>>> __ JMS
>>> __ Web Services
>>> __ EJB
>>> __ OpenJPA
>>> __ Deployment
>>> __ Admin Console
>>> __ Cluster (tomcat only?)
>> __wadi clustering
>>>
>>> Then the user can just select one or more functions they need and
>>> request for the customer assembly server to be created. Optionally,
>>> the user can add on additional deployed apps or other system modules
>>> then request for the customer assembly server to be created.
>> I wonder if we can think bigger :-)
>>
>> What if we distributed something with _all_ the cars in it and customizable
>> profiles for the servers we ship now? So, you wouldn't unpack a particular
>> server, but the server construction kit. You could pick a profile and
>> optionally modify it, then spit out the desired server. Then you would be
>> able to pick jetty/tomcat and cxf/axis2 and however much deployment you
>> wanted.
>>
>> Alternatively maybe the "assemble a server" can show plugins from more than
>> just the current server.
>>
>> thanks
>> david jencks
>>
>>
>>
>>>
>>> Lin
>>>
>>> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>> client profiles might be apropriate too.
>>>>
>>>> I wonder how much of this is actually necessary? e.g. if you install the
>>>> jetty-deployer plugin you get jetty too. If you install the
>>>> jetty-console
>>>> you get jetty....
>>>>
>>>> What if we had a "select the parts" page that was organized differently
>>>> than
>>>> the list of plugins.... e.g. checkboxes for web, ejb, webservices. If
>>>> you
>>>> say yes to web, you get to choose jetty/tomcat, whether you want
>>>> deployment,
>>>> whether you want the console.
>>>>
>>>> Choosing web or ejb gives you the opportunity to include openjpa ( or
>>>> maybe
>>>> toplink in the future)
>>>> Choosing webservices gives you the choice of cxf or axis2
>>>>
>>>>
>>>> Just some more or less random thoughts
>>>> david jencks
>>>>
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Thanks for updating the key function list.
Your big idea is very interesting... Also, It is possible we just
distribute the server construction kit, and a user could just select
profiles/plugins from a remote repo to assemble a desired custom
server. I wonder if we could revisit this post 2.2, or after we
finish the usability improvement of the custom assembly.
Lin
On Tue, Aug 12, 2008 at 6:11 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>
>> I appreciate your valuable feedback!
>>
>> Currently, a user doesn't have that much choices, as we only allow the
>> user to assemble a new server out of plugins in local server, unless
>> we want to change this behavior.
>>
>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>> only choose tomcat + axis2. If a user installs the
>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>
> true... for now :-)
>>
>>
>> To simplify things, here is what I suggest. We allow the users to choose
>> from -
>>
>> __ Web
>
> __jsp
>>
>> __ JMS
>> __ Web Services
>> __ EJB
>> __ OpenJPA
>> __ Deployment
>> __ Admin Console
>> __ Cluster (tomcat only?)
>
> __wadi clustering
>>
>>
>> Then the user can just select one or more functions they need and
>> request for the customer assembly server to be created. Optionally,
>> the user can add on additional deployed apps or other system modules
>> then request for the customer assembly server to be created.
>
> I wonder if we can think bigger :-)
>
> What if we distributed something with _all_ the cars in it and customizable
> profiles for the servers we ship now? So, you wouldn't unpack a particular
> server, but the server construction kit. You could pick a profile and
> optionally modify it, then spit out the desired server. Then you would be
> able to pick jetty/tomcat and cxf/axis2 and however much deployment you
> wanted.
>
> Alternatively maybe the "assemble a server" can show plugins from more than
> just the current server.
>
> thanks
> david jencks
>
>
>
>>
>>
>> Lin
>>
>> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>> client profiles might be apropriate too.
>>>
>>> I wonder how much of this is actually necessary? e.g. if you install the
>>> jetty-deployer plugin you get jetty too. If you install the
>>> jetty-console
>>> you get jetty....
>>>
>>> What if we had a "select the parts" page that was organized differently
>>> than
>>> the list of plugins.... e.g. checkboxes for web, ejb, webservices. If
>>> you
>>> say yes to web, you get to choose jetty/tomcat, whether you want
>>> deployment,
>>> whether you want the console.
>>>
>>> Choosing web or ejb gives you the opportunity to include openjpa ( or
>>> maybe
>>> toplink in the future)
>>> Choosing webservices gives you the choice of cxf or axis2
>>>
>>>
>>> Just some more or less random thoughts
>>> david jencks
>>>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by "Jay D. McHugh" <ja...@gmail.com>.
Comments/responses inline
Jay
Joe Bohn wrote:
> Jay D. McHugh 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.
>
>
> I think I'm getting a little lost in the terms here. IIUC you are using
> the following groupings (from the most comprehensive to the least):
>
> Templates (server definitions) contain Profiles
> Profiles (groupings of plugins) contain Plugins
> Plugins contain Geronimo modules/artifacts
> modules/artifacts - core building blocks of Geronimo
>
> I've oversimplified a bit but I think that is logical grouping you are
> proposing .... Is that correct?
Exactly what I was thinking. But if it is possible to make all of these
with plugins (and 'meta-plugins') then there is no reason to invent a
new structure to hold them.
I do think that it -might- be useful to keep those levels as
descriptions for types of plugins. ie: Profile plugins, (server)
Template plugins, etc... I guess it would fall apart as soon as someone
thought of a JEE5 server (template plugin) as a 'functionality' (profile
plugin) to be include in a 'full server'.
So maybe it might only be worth while to keep the idea of a profile
plugin that encapsulates other plugins. And leave off trying to further
narrow types of plugins.
>
> If it is, then I think your 1st idea above is to include the knowledge
> of containment in the child rather the parent. So would I be correct in
> assuming that you are proposing adding the knowledge of profile
> membership into the plugins (rather than modules/artifacts)? I don't
> have an opinion on that yet ... just trying to understand.
That was what I originally was thinking of. But David's point about
future profiles not being able to inherit modules kind of shoots it
down. Besides, if plugins are the vehicle for containing these packages
then the 'automatic' assembly of profiles stops being a convenience and
starts being detrimental.
>
>>
>> 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.
>
> This notion of a template is exactly in line with what we had discussed
> before and what I brought up again a few days ago. It is basically a
> definition of a server in "thin" format. I keep thinking of it in xml
> (like you referenced above) but it could be in some other format. The
> idea was that you could use this template and some utility to enhance a
> framework server and turn it into whatever kind of server you want it to
> be. The utility would be nothing more than something that could read
> the template, drill down to the appropriate set of plugins, and install
> them along with any other configuration necessary for the server. The
> actual plugins that are installed (also groupings of plugins for
> simplification) could be in some local toolkit repo we ship with
> Geronimo or in remote repositories we make available when we release a
> server version (as we do today).
>
> I prefer this approach because it encourages portability and
> predictability. You can generate a template and then use it to create
> many server images which should be identical. Thought must be given
> when creating the template. However, creating multiple server images is
> then a fairly simple process from the user perspective. If we can come
> up with a version independent way to specify the Geronimo dependencies
> then this can be portable across server releases so that the user can
> potentially use the template they generated for a particular server
> image in 2.2.1 and generate a comparable server image for 2.2.2. I
> wouldn't anticipate that we could make this portable across major
> releases but I would hope we could make it portable across minor
> releases. We don't necessarily need to tackle the upgrade scenario now
> but I think the template approach sets the stage for some possibilities.
>
>>
>> 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 <jg...@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 <li...@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
>>>>>
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 28, 2008, at 2:30 AM, Rex Wang wrote:
> Really an exciting roadmap on Customer Server Assembly! I'd like to
> clear my understanding on this mission, and hope this helpful for
> "function centric" server assembly.
>
> Glossary:
> Server template – a description of a customer server assembly, and
> is composed by some function profiles.
> Function profile – a description of a function (that is plugin
> group), and is composed by some plugins.
>
> 1. How to assemble a server?
> 1) manually choose the function profiles from a list to
> assemble a server
> 2) using a server template to generate a server
>
> 2. How to generate a server template?
> 1) manually choose the function profiles from a list and
> export as a server template
> 2) export the current server as a server template
>
> 3. How to build a function profile?
> 1) manually choose some plugins from a list and export as a
> function profile (such as what we does today, for advanced user only)
> 2) combine some existing function profiles to build a new
> function profile
>
I don't disagree with anything you are saying, but to me these are all
plugins. What I'd like to see added to what we have now are:
- better support for "list of plugins" plugins that dont end up
creating a classloader at runtime. The boilerplate plugin does this
now, but it should be easier.
- something in the console that lets you create a "list of plugins"
plugin.
I think using the Category or perhaps a naming convention might be
enough structure to distinguish code-and-service plugins, "profile"
plugins, and "template" plugins.
thanks
david jencks
>
>
> Thanks!
>
> Rex
>
>
> 2008/8/26 Joe Bohn <jo...@earthlink.net>
> David Jencks wrote:
>
> On Aug 25, 2008, at 3:25 PM, Joe Bohn wrote:
>
> Jay D. McHugh 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.
>
>
> I think I'm getting a little lost in the terms here. IIUC you are
> using the following groupings (from the most comprehensive to the
> least):
>
> Templates (server definitions) contain Profiles
> Profiles (groupings of plugins) contain Plugins
> Plugins contain Geronimo modules/artifacts
> modules/artifacts - core building blocks of Geronimo
>
> I've oversimplified a bit but I think that is logical grouping you
> are proposing .... Is that correct?
>
> If it is, then I think your 1st idea above is to include the
> knowledge of containment in the child rather the parent. So would I
> be correct in assuming that you are proposing adding the knowledge
> of profile membership into the plugins (rather than modules/
> artifacts)? I don't have an opinion on that yet ... just trying to
> understand.
>
> I missed that and don't see how it would work. If I come up with a
> new template or profile tomorrow, how will the current plugins know
> if they are in it or not?
>
> As I tried to say before, hierarchy is good but we already have
> unlimited nesting in plugins.... we just need to fix a little bit of
> goo so they don't result in excess classloaders at runtime.
>
>
> 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.
>
> This notion of a template is exactly in line with what we had
> discussed before and what I brought up again a few days ago. It is
> basically a definition of a server in "thin" format. I keep
> thinking of it in xml (like you referenced above) but it could be in
> some other format. The idea was that you could use this template
> and some utility to enhance a framework server and turn it into
> whatever kind of server you want it to be. The utility would be
> nothing more than something that could read the template, drill down
> to the appropriate set of plugins, and install them along with any
> other configuration necessary for the server. The actual plugins
> that are installed (also groupings of plugins for simplification)
> could be in some local toolkit repo we ship with Geronimo or in
> remote repositories we make available when we release a server
> version (as we do today).
>
> You can get a plugin to install just about anything you want
> already. The tomcat plugin installs the tomcat config under var,
> there are some instructions in the wiki on how to install
> application specific logging, etc etc. There are also some ways to
> customize preexisting configuration (such as config.xml) that we use
> in the tck servers.... can't remember exactly how it works though.
>
>
> I prefer this approach because it encourages portability and
> predictability. You can generate a template and then use it to
> create many server images which should be identical. Thought must
> be given when creating the template. However, creating multiple
> server images is then a fairly simple process from the user
> perspective. If we can come up with a version independent way to
> specify the Geronimo dependencies then this can be portable across
> server releases so that the user can potentially use the template
> they generated for a particular server image in 2.2.1 and generate a
> comparable server image for 2.2.2. I wouldn't anticipate that we
> could make this portable across major releases but I would hope we
> could make it portable across minor releases. We don't necessarily
> need to tackle the upgrade scenario now but I think the template
> approach sets the stage for some possibilities.
>
> I really don't think we should encourage leaving out the versions.
> it's a bit maven centric but maven can substitute versions when
> constructing a geronimo-plugin.xml. I'm sure there are other ways.
>
> I guess the other way is what you have mentioned before ...
> substitute the version when installing the plugin (via aliases).
>
>
>
> I may not be understanding what you are saying. It seems to me that
> what we're talking about is basically turning the lists of plugins
> now in the assembly poms into independent artifacts that can be used
> by the car-maven-plugin to assemble servers, and also from other
> spots such as gshell and maybe the console. We're can do this today
> with the existing plugin mechanism although it has a few bad side
> effects which we should be able to eliminate pretty easily.
>
> Right. I think the approach that you and Lin have been discussing to
> use the existing plugin mechanism and extend the function in the car-
> maven-plugin (and gshell/console) makes a lot of sense. I think the
> concept of a plugin that is just an arbitrary container of other
> plugins (nested multiple levels) can be used in a variety of helpful
> ways:
>
> 1) It can be used to create these "profiles" of logical sets of
> plugins that make sense together for easy selection/installation by
> users.
> 2) A user can use the same feature to create their own profiles of
> functions base upon their own components. For example, a user could
> create a shopping cart, bookstore, and electronics store profiles.
> They could then combine/install these on servers to manage their
> book business, electronic business, or both on any combination of
> servers.
> 3) The profiles can be persisted, reused, and shared among users
> (just like regular plugins).
> 4) It can be used to construct entire collections of components that
> define a cohesive set of function for a server. This can then be
> installed on a framework assembly to produce consistent/repeatable
> server images (such as our javaee5 server or some subset such as a
> web service only server image).
> 5) It might be able to be used to create a consistent server image
> across server released when modified (via automation or manually) to
> accommodate differences between the old and new server versions.
> This can potentially provide an upgrade path for our users that have
> created custom assemblies.
>
> I think this function is more general than just what is needed for
> "assemble a server". However, in that specific context we could do
> the following:
> - Let a user choose plugins, profile plugins (for lack of a better
> term) or whatever from which they would like to create a server image.
> - Produce another profile plugin that includes the total selection
> instead of (or in addition to) creating a server image.
> - The user could then save/publish/whatever the profile plugin.
> - The profile plugin could be installed into a framework server
> image to convert it into the specific server that was desired.
> - Of course, the real function (what we know as plugins now) would
> be installed from a repository - either local or remote.
>
>
> This kinda gets at one of the things that has been nagging me about
> the "assemble a server" discussion ... that being that a user must
> select some core set of plugins to create a viable server image.
> This always seemed a bit foreign to me because all along I've been
> thinking that assembling a server would always start with a core
> framework assembly which included the necessary core function (such
> as the ability to install plugins). That was originally the purpose
> of the framework assembly and I ensured that you could install
> plugins into it way back when. I think (but I might be wrong) that
> starting with a framework assembly when creating a new server
> assembly should make it easier to make a pure template/profile
> plugin because you don't need to worry about any core server
> capability. All of the core stuff should already be included in
> server image used as the starting point. A user would only need to
> install particular features on top of that to create the specific
> flavor of server they desire. And, these features could be combined
> to create a server image that has the nature of multiple profiles.
> From a user perspective it's all the same. He can build up a server
> by installing plugins - some very small in granularity and other
> quite large (perhaps large enough to pull in everything they want in
> the server image with one selection).
>
> I've rambled enough for now ... and I hope it isn't all lunacy.
> thanks,
> Joe
>
>
>
>
>
> thanks
> david jencks
>
>
>
>
> 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 <jg...@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 <li...@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
>
>
>
>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Rex Wang <rw...@gmail.com>.
Really an exciting roadmap on Customer Server Assembly! I'd like to clear my
understanding on this mission, and hope this helpful for "function centric"
server assembly.
Glossary:
Server template �C a description of a customer server assembly, and is
composed by some function profiles.
Function profile �C a description of a function (that is plugin group), and
is composed by some plugins.
1. How to assemble a server?
1) manually choose the function profiles from a list to assemble a
server
2) using a server template to generate a server
2. How to generate a server template?
1) manually choose the function profiles from a list and export as a
server template
2) export the current server as a server template
3. How to build a function profile?
1) manually choose some plugins from a list and export as a function
profile (such as what we does today, for advanced user only)
2) combine some existing function profiles to build a new function
profile
Thanks!
Rex
2008/8/26 Joe Bohn <jo...@earthlink.net>
> David Jencks wrote:
>
>>
>> On Aug 25, 2008, at 3:25 PM, Joe Bohn wrote:
>>
>> Jay D. McHugh 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.
>>>>
>>>
>>>
>>> I think I'm getting a little lost in the terms here. IIUC you are using
>>> the following groupings (from the most comprehensive to the least):
>>>
>>> Templates (server definitions) contain Profiles
>>> Profiles (groupings of plugins) contain Plugins
>>> Plugins contain Geronimo modules/artifacts
>>> modules/artifacts - core building blocks of Geronimo
>>>
>>> I've oversimplified a bit but I think that is logical grouping you are
>>> proposing .... Is that correct?
>>>
>>> If it is, then I think your 1st idea above is to include the knowledge of
>>> containment in the child rather the parent. So would I be correct in
>>> assuming that you are proposing adding the knowledge of profile membership
>>> into the plugins (rather than modules/artifacts)? I don't have an opinion
>>> on that yet ... just trying to understand.
>>>
>>
>> I missed that and don't see how it would work. If I come up with a new
>> template or profile tomorrow, how will the current plugins know if they are
>> in it or not?
>>
>> As I tried to say before, hierarchy is good but we already have unlimited
>> nesting in plugins.... we just need to fix a little bit of goo so they don't
>> result in excess classloaders at runtime.
>>
>>>
>>>
>>> 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.
>>>>
>>>
>>> This notion of a template is exactly in line with what we had discussed
>>> before and what I brought up again a few days ago. It is basically a
>>> definition of a server in "thin" format. I keep thinking of it in xml (like
>>> you referenced above) but it could be in some other format. The idea was
>>> that you could use this template and some utility to enhance a framework
>>> server and turn it into whatever kind of server you want it to be. The
>>> utility would be nothing more than something that could read the template,
>>> drill down to the appropriate set of plugins, and install them along with
>>> any other configuration necessary for the server. The actual plugins that
>>> are installed (also groupings of plugins for simplification) could be in
>>> some local toolkit repo we ship with Geronimo or in remote repositories we
>>> make available when we release a server version (as we do today).
>>>
>>
>> You can get a plugin to install just about anything you want already. The
>> tomcat plugin installs the tomcat config under var, there are some
>> instructions in the wiki on how to install application specific logging, etc
>> etc. There are also some ways to customize preexisting configuration (such
>> as config.xml) that we use in the tck servers.... can't remember exactly how
>> it works though.
>>
>>>
>>>
>>> I prefer this approach because it encourages portability and
>>> predictability. You can generate a template and then use it to create many
>>> server images which should be identical. Thought must be given when
>>> creating the template. However, creating multiple server images is then a
>>> fairly simple process from the user perspective. If we can come up with a
>>> version independent way to specify the Geronimo dependencies then this can
>>> be portable across server releases so that the user can potentially use the
>>> template they generated for a particular server image in 2.2.1 and generate
>>> a comparable server image for 2.2.2. I wouldn't anticipate that we
>>> could make this portable across major releases but I would hope we could
>>> make it portable across minor releases. We don't necessarily need to tackle
>>> the upgrade scenario now but I think the template approach sets the stage
>>> for some possibilities.
>>>
>>
>> I really don't think we should encourage leaving out the versions. it's a
>> bit maven centric but maven can substitute versions when constructing a
>> geronimo-plugin.xml. I'm sure there are other ways.
>>
>
> I guess the other way is what you have mentioned before ... substitute the
> version when installing the plugin (via aliases).
>
>
>> I may not be understanding what you are saying. It seems to me that what
>> we're talking about is basically turning the lists of plugins now in the
>> assembly poms into independent artifacts that can be used by the
>> car-maven-plugin to assemble servers, and also from other spots such as
>> gshell and maybe the console. We're can do this today with the existing
>> plugin mechanism although it has a few bad side effects which we should be
>> able to eliminate pretty easily.
>>
>
> Right. I think the approach that you and Lin have been discussing to use
> the existing plugin mechanism and extend the function in the
> car-maven-plugin (and gshell/console) makes a lot of sense. I think the
> concept of a plugin that is just an arbitrary container of other plugins
> (nested multiple levels) can be used in a variety of helpful ways:
>
> 1) It can be used to create these "profiles" of logical sets of plugins
> that make sense together for easy selection/installation by users.
> 2) A user can use the same feature to create their own profiles of
> functions base upon their own components. For example, a user could create
> a shopping cart, bookstore, and electronics store profiles. They could then
> combine/install these on servers to manage their book business, electronic
> business, or both on any combination of servers.
> 3) The profiles can be persisted, reused, and shared among users (just like
> regular plugins).
> 4) It can be used to construct entire collections of components that define
> a cohesive set of function for a server. This can then be installed on a
> framework assembly to produce consistent/repeatable server images (such as
> our javaee5 server or some subset such as a web service only server image).
> 5) It might be able to be used to create a consistent server image across
> server released when modified (via automation or manually) to accommodate
> differences between the old and new server versions. This can potentially
> provide an upgrade path for our users that have created custom assemblies.
>
> I think this function is more general than just what is needed for
> "assemble a server". However, in that specific context we could do the
> following:
> - Let a user choose plugins, profile plugins (for lack of a better term) or
> whatever from which they would like to create a server image.
> - Produce another profile plugin that includes the total selection instead
> of (or in addition to) creating a server image.
> - The user could then save/publish/whatever the profile plugin.
> - The profile plugin could be installed into a framework server image to
> convert it into the specific server that was desired.
> - Of course, the real function (what we know as plugins now) would be
> installed from a repository - either local or remote.
>
>
> This kinda gets at one of the things that has been nagging me about the
> "assemble a server" discussion ... that being that a user must select some
> core set of plugins to create a viable server image. This always seemed a
> bit foreign to me because all along I've been thinking that assembling a
> server would always start with a core framework assembly which included the
> necessary core function (such as the ability to install plugins). That was
> originally the purpose of the framework assembly and I ensured that you
> could install plugins into it way back when. I think (but I might be wrong)
> that starting with a framework assembly when creating a new server assembly
> should make it easier to make a pure template/profile plugin because you
> don't need to worry about any core server capability. All of the core stuff
> should already be included in server image used as the starting point. A
> user would only need to install particular features on top of that to create
> the specific flavor of server they desire. And, these features could be
> combined to create a server image that has the nature of multiple profiles.
> From a user perspective it's all the same. He can build up a server by
> installing plugins - some very small in granularity and other quite large
> (perhaps large enough to pull in everything they want in the server image
> with one selection).
>
> I've rambled enough for now ... and I hope it isn't all lunacy.
> thanks,
> Joe
>
>
>
>
>
>> thanks
>> david jencks
>>
>>
>>
>>>
>>> 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 <jg...@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 <li...@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
>>>>>>>
>>>>>>>
>>>
>>
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
>
> On Aug 25, 2008, at 3:25 PM, Joe Bohn wrote:
>
>> Jay D. McHugh 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.
>>
>>
>> I think I'm getting a little lost in the terms here. IIUC you are
>> using the following groupings (from the most comprehensive to the least):
>>
>> Templates (server definitions) contain Profiles
>> Profiles (groupings of plugins) contain Plugins
>> Plugins contain Geronimo modules/artifacts
>> modules/artifacts - core building blocks of Geronimo
>>
>> I've oversimplified a bit but I think that is logical grouping you are
>> proposing .... Is that correct?
>>
>> If it is, then I think your 1st idea above is to include the knowledge
>> of containment in the child rather the parent. So would I be correct
>> in assuming that you are proposing adding the knowledge of profile
>> membership into the plugins (rather than modules/artifacts)? I don't
>> have an opinion on that yet ... just trying to understand.
>
> I missed that and don't see how it would work. If I come up with a new
> template or profile tomorrow, how will the current plugins know if they
> are in it or not?
>
> As I tried to say before, hierarchy is good but we already have
> unlimited nesting in plugins.... we just need to fix a little bit of goo
> so they don't result in excess classloaders at runtime.
>>
>>
>>> 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.
>>
>> This notion of a template is exactly in line with what we had
>> discussed before and what I brought up again a few days ago. It is
>> basically a definition of a server in "thin" format. I keep thinking
>> of it in xml (like you referenced above) but it could be in some other
>> format. The idea was that you could use this template and some
>> utility to enhance a framework server and turn it into whatever kind
>> of server you want it to be. The utility would be nothing more than
>> something that could read the template, drill down to the appropriate
>> set of plugins, and install them along with any other configuration
>> necessary for the server. The actual plugins that are installed (also
>> groupings of plugins for simplification) could be in some local
>> toolkit repo we ship with Geronimo or in remote repositories we make
>> available when we release a server version (as we do today).
>
> You can get a plugin to install just about anything you want already.
> The tomcat plugin installs the tomcat config under var, there are some
> instructions in the wiki on how to install application specific logging,
> etc etc. There are also some ways to customize preexisting
> configuration (such as config.xml) that we use in the tck servers....
> can't remember exactly how it works though.
>>
>>
>> I prefer this approach because it encourages portability and
>> predictability. You can generate a template and then use it to create
>> many server images which should be identical. Thought must be given
>> when creating the template. However, creating multiple server images
>> is then a fairly simple process from the user perspective. If we can
>> come up with a version independent way to specify the Geronimo
>> dependencies then this can be portable across server releases so that
>> the user can potentially use the template they generated for a
>> particular server image in 2.2.1 and generate a comparable server
>> image for 2.2.2. I wouldn't anticipate that we could make this
>> portable across major releases but I would hope we could make it
>> portable across minor releases. We don't necessarily need to tackle
>> the upgrade scenario now but I think the template approach sets the
>> stage for some possibilities.
>
> I really don't think we should encourage leaving out the versions. it's
> a bit maven centric but maven can substitute versions when constructing
> a geronimo-plugin.xml. I'm sure there are other ways.
I guess the other way is what you have mentioned before ... substitute
the version when installing the plugin (via aliases).
>
> I may not be understanding what you are saying. It seems to me that
> what we're talking about is basically turning the lists of plugins now
> in the assembly poms into independent artifacts that can be used by the
> car-maven-plugin to assemble servers, and also from other spots such as
> gshell and maybe the console. We're can do this today with the existing
> plugin mechanism although it has a few bad side effects which we should
> be able to eliminate pretty easily.
Right. I think the approach that you and Lin have been discussing to use
the existing plugin mechanism and extend the function in the
car-maven-plugin (and gshell/console) makes a lot of sense. I think the
concept of a plugin that is just an arbitrary container of other plugins
(nested multiple levels) can be used in a variety of helpful ways:
1) It can be used to create these "profiles" of logical sets of plugins
that make sense together for easy selection/installation by users.
2) A user can use the same feature to create their own profiles of
functions base upon their own components. For example, a user could
create a shopping cart, bookstore, and electronics store profiles. They
could then combine/install these on servers to manage their book
business, electronic business, or both on any combination of servers.
3) The profiles can be persisted, reused, and shared among users (just
like regular plugins).
4) It can be used to construct entire collections of components that
define a cohesive set of function for a server. This can then be
installed on a framework assembly to produce consistent/repeatable
server images (such as our javaee5 server or some subset such as a web
service only server image).
5) It might be able to be used to create a consistent server image
across server released when modified (via automation or manually) to
accommodate differences between the old and new server versions. This
can potentially provide an upgrade path for our users that have created
custom assemblies.
I think this function is more general than just what is needed for
"assemble a server". However, in that specific context we could do the
following:
- Let a user choose plugins, profile plugins (for lack of a better term)
or whatever from which they would like to create a server image.
- Produce another profile plugin that includes the total selection
instead of (or in addition to) creating a server image.
- The user could then save/publish/whatever the profile plugin.
- The profile plugin could be installed into a framework server image to
convert it into the specific server that was desired.
- Of course, the real function (what we know as plugins now) would be
installed from a repository - either local or remote.
This kinda gets at one of the things that has been nagging me about the
"assemble a server" discussion ... that being that a user must select
some core set of plugins to create a viable server image. This always
seemed a bit foreign to me because all along I've been thinking that
assembling a server would always start with a core framework assembly
which included the necessary core function (such as the ability to
install plugins). That was originally the purpose of the framework
assembly and I ensured that you could install plugins into it way back
when. I think (but I might be wrong) that starting with a framework
assembly when creating a new server assembly should make it easier to
make a pure template/profile plugin because you don't need to worry
about any core server capability. All of the core stuff should already
be included in server image used as the starting point. A user would
only need to install particular features on top of that to create the
specific flavor of server they desire. And, these features could be
combined to create a server image that has the nature of multiple
profiles. From a user perspective it's all the same. He can build up a
server by installing plugins - some very small in granularity and other
quite large (perhaps large enough to pull in everything they want in the
server image with one selection).
I've rambled enough for now ... and I hope it isn't all lunacy.
thanks,
Joe
>
> thanks
> david jencks
>
>
>>
>>
>>> 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 <jg...@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 <li...@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
>>>>>>
>>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 25, 2008, at 3:25 PM, Joe Bohn wrote:
> Jay D. McHugh 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.
>
>
> I think I'm getting a little lost in the terms here. IIUC you are
> using the following groupings (from the most comprehensive to the
> least):
>
> Templates (server definitions) contain Profiles
> Profiles (groupings of plugins) contain Plugins
> Plugins contain Geronimo modules/artifacts
> modules/artifacts - core building blocks of Geronimo
>
> I've oversimplified a bit but I think that is logical grouping you
> are proposing .... Is that correct?
>
> If it is, then I think your 1st idea above is to include the
> knowledge of containment in the child rather the parent. So would I
> be correct in assuming that you are proposing adding the knowledge
> of profile membership into the plugins (rather than modules/
> artifacts)? I don't have an opinion on that yet ... just trying to
> understand.
I missed that and don't see how it would work. If I come up with a
new template or profile tomorrow, how will the current plugins know if
they are in it or not?
As I tried to say before, hierarchy is good but we already have
unlimited nesting in plugins.... we just need to fix a little bit of
goo so they don't result in excess classloaders at runtime.
>
>
>> 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.
>
> This notion of a template is exactly in line with what we had
> discussed before and what I brought up again a few days ago. It is
> basically a definition of a server in "thin" format. I keep
> thinking of it in xml (like you referenced above) but it could be in
> some other format. The idea was that you could use this template
> and some utility to enhance a framework server and turn it into
> whatever kind of server you want it to be. The utility would be
> nothing more than something that could read the template, drill down
> to the appropriate set of plugins, and install them along with any
> other configuration necessary for the server. The actual plugins
> that are installed (also groupings of plugins for simplification)
> could be in some local toolkit repo we ship with Geronimo or in
> remote repositories we make available when we release a server
> version (as we do today).
You can get a plugin to install just about anything you want already.
The tomcat plugin installs the tomcat config under var, there are some
instructions in the wiki on how to install application specific
logging, etc etc. There are also some ways to customize preexisting
configuration (such as config.xml) that we use in the tck servers....
can't remember exactly how it works though.
>
>
> I prefer this approach because it encourages portability and
> predictability. You can generate a template and then use it to
> create many server images which should be identical. Thought must
> be given when creating the template. However, creating multiple
> server images is then a fairly simple process from the user
> perspective. If we can come up with a version independent way to
> specify the Geronimo dependencies then this can be portable across
> server releases so that the user can potentially use the template
> they generated for a particular server image in 2.2.1 and generate a
> comparable server image for 2.2.2. I wouldn't anticipate that we
> could make this portable across major releases but I would hope we
> could make it portable across minor releases. We don't necessarily
> need to tackle the upgrade scenario now but I think the template
> approach sets the stage for some possibilities.
I really don't think we should encourage leaving out the versions.
it's a bit maven centric but maven can substitute versions when
constructing a geronimo-plugin.xml. I'm sure there are other ways.
I may not be understanding what you are saying. It seems to me that
what we're talking about is basically turning the lists of plugins now
in the assembly poms into independent artifacts that can be used by
the car-maven-plugin to assemble servers, and also from other spots
such as gshell and maybe the console. We're can do this today with
the existing plugin mechanism although it has a few bad side effects
which we should be able to eliminate pretty easily.
thanks
david jencks
>
>
>> 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 <jg...@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 <li...@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
>>>>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Joe Bohn <jo...@earthlink.net>.
Jay D. McHugh 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.
I think I'm getting a little lost in the terms here. IIUC you are using
the following groupings (from the most comprehensive to the least):
Templates (server definitions) contain Profiles
Profiles (groupings of plugins) contain Plugins
Plugins contain Geronimo modules/artifacts
modules/artifacts - core building blocks of Geronimo
I've oversimplified a bit but I think that is logical grouping you are
proposing .... Is that correct?
If it is, then I think your 1st idea above is to include the knowledge
of containment in the child rather the parent. So would I be correct in
assuming that you are proposing adding the knowledge of profile
membership into the plugins (rather than modules/artifacts)? I don't
have an opinion on that yet ... just trying to understand.
>
> 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.
This notion of a template is exactly in line with what we had discussed
before and what I brought up again a few days ago. It is basically a
definition of a server in "thin" format. I keep thinking of it in xml
(like you referenced above) but it could be in some other format. The
idea was that you could use this template and some utility to enhance a
framework server and turn it into whatever kind of server you want it to
be. The utility would be nothing more than something that could read
the template, drill down to the appropriate set of plugins, and install
them along with any other configuration necessary for the server. The
actual plugins that are installed (also groupings of plugins for
simplification) could be in some local toolkit repo we ship with
Geronimo or in remote repositories we make available when we release a
server version (as we do today).
I prefer this approach because it encourages portability and
predictability. You can generate a template and then use it to create
many server images which should be identical. Thought must be given
when creating the template. However, creating multiple server images is
then a fairly simple process from the user perspective. If we can come
up with a version independent way to specify the Geronimo dependencies
then this can be portable across server releases so that the user can
potentially use the template they generated for a particular server
image in 2.2.1 and generate a comparable server image for 2.2.2. I
wouldn't anticipate that we could make this portable across major
releases but I would hope we could make it portable across minor
releases. We don't necessarily need to tackle the upgrade scenario now
but I think the template approach sets the stage for some possibilities.
>
> 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 <jg...@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 <li...@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
>>>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 25, 2008, at 12:12 PM, Jay D. McHugh 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?
I think this idea is worth pursuing and thinking about some more. I
think that the "group of plugins" plugin might provide all the
functionality you want. Here are some comments on the current state
of things that I think might clean up the situation a bit.
First of all, right now the stuff in the foundation is a bit unsettled
and shifting. There's boilerplate which is kind of the foundation for
the server, but it has quite a bit too much stuff in it.... mostly all
the bin/*.jars used to start various servers, and the geronimo
schemas. Both of these should be possible to eliminate by enhancing
parts of the plugin installation process: the schemas can be extracted
from the classpath of some car, and the jars are relabeled packed car
files. The other part of the foundation is the gshell cars which I
suspect can all be made dependencies of boilerplate. Then you'll only
need to specify boilerplate as a single foundation dependency to get a
working server with whatever else you may want.
Previously I was considering that we don't want to have dependencies
on the foundation stuff from other real plugins so we could have
slimmer alternate foundation setups but maybe if we can slim down
boilerplate we could have an entry for boilerplate in the root
geronimo-plugin.xmls without having a dependency. I think this might
involve a change to the c-m-p plugin metadata generation.
Second, plugins are really built on dependencies. So if you have an
application you want to assemble a server around, all you need to do
is specify that plugin plus the foundation goo. If you want a server
you can deploy web apps to you can just specify [jetty6/tomcat6]-
deployer. So IMO a profile ought to be a really really short list of
plugins.... the full server ought to be pretty short. It might be
interesting to see just how short it can be right now.
Third, I think it will be really really unusual that anyone would
include an artifact in a "group" plugin or one of your templates. If
its brought in only in this way it can't be an any classloader so will
be inaccessible to any normal operations. The only reason I can think
of is to make it available to some kind of additional deployment
process but I'm having trouble thinking of an actual example.
Third, if we give all our "group of plugins" plugins moduleIds and
figure out how to keep them from getting "loaded" in any server, then
I think your template is just a plugin.... you can have other plugins
which happen to be profiles, "real" plugins, and plain artifacts.
So... here are some steps I can see forward...
- figure out how a plugin with a module ID can have no effect on any
config files, not even getting added with load="false". Boilerplate
might already be an example of this. I think though that we'll need
another flag in the maven xml. This will enable arbitrary nesting of
"group of plugins" plugins.
- figure out how to get dependencies into geronimo-plugin.xml without
getting into the classloader dependencies or service dependencies
Then the "root" plugins such as j2ee-system can pull in boilerplate
and the gshell dependencies without trying to start them or load their
classes.
- figure out how to copy files out of the car's classpath when
installing a plugin. (right now you can only copy files out of the car
itself). This will let us populate the schema directory automatically
as plugins are installed.
- figure out how to install "root" plugins into bin as jars.... or how
to start them directly from their unpacked repository locations. The
latter might be better but I suspect would require quite a bit of
gshell support.
thanks
david jencks
>
>
> 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 <jg...@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 <li...@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
>>>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by "Jay D. McHugh" <ja...@gmail.com>.
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 <jg...@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 <li...@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
>>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
I actually forgot that - my bad. If that is the case, we'll let users
to pick web service Axis2 or web service CXF in both assemblies.
Lin
On Fri, Aug 22, 2008 at 12:05 PM, David Jencks <da...@yahoo.com> wrote:
> 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 <jg...@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 <li...@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
>>>>
>>>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
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 <jg...@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 <li...@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
>>>
>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
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 <jg...@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 <li...@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
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
David, thanks - if there is an easier way I'd love to learn that :)
Can you please explain a bit more on this function (leaving out
moduleid and get dependencies installed)? Does that mean that I build
a geronimo plugin without moduleId but with dependencies? If so, I'd
like to look at this function and get it working.
I'll try what you suggested on the plugins needed to build little G.
Lin
On Tue, Aug 19, 2008 at 4:38 PM, David Jencks <da...@yahoo.com> wrote:
> A couple of comments...
>
> First, I thought you could already do this by leaving out the moduleId....
> you'd just get the dependencies installed. I might be wrong and this
> functionality might have broken along the way. Second, with this set of
> plugins all you need to specify is tomcat and upgrade-cli, the others should
> get pulled in via transitive dependencies I suspect you also want
> tomcat-deployer and jasper and I'm pretty sure you need to list the gshell
> plugins separately to get a working server.
>
> thanks
> david jencks
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Hi David,
Thanks. I am able to come down to the following plugins to build
little G(tomcat based) and I tried to use transitive dependencies as
much as possible -
org.apache.geronimo.assemblies/geronimo-boilerplate/2.2-SNAPSHOT/jar
org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car
Deployment related:
org.apache.geronimo.framework/upgrade-cli/2.2-SNAPSHOT/car
org.apache.geronimo.framework/offline-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jsr88-ear-configurer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jsr88-rar-configurer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jsr88-war-configurer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car
Gshell:
org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car
org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car
I tried to deploy the jsp-examples onto custom server, and it worked
fine. So the unavailable-deployers don't seem to be necessary.
I also looked at the earconfigbuilder code and there is a private
getBuilder method there that would throw deploymentExceptions when the
ejb/war/rar/appClient deployer is not defined. The getBuilder method
is used in the buildConfiguration method in many places.
With these information and the fact that the unavailable-deployers
aren't in the tomcat-javaee5 assembly, I don't think they are needed.
I plan to clean up the littleG pom.xml with only the above car files
as the dependencies.
Please let me know any comments you may have.
Lin
On Wed, Aug 20, 2008 at 2:04 AM, David Jencks <da...@yahoo.com> wrote:
>> Anyone has an idea what are these for? Is it ok to build little G env
>> without them?
>
> Not sure if they are actually needed.... I've been meaning to check and fix
> things so they aren't needed, assuming that they are. If they are currently
> required you will find out as soon as you try to deploy something jee
> related on the server.
>
> I think the ear config builder needs to be changed so that if one of the
> module builders is missing, the ear builder complains, rather than relying
> on an "unavailable deployer" to complain.
>
> I recommend rather strongly relying on transitive dependencies as much as
> possible.
>
> thanks
> david jencks
>
>>
>>
>> Thanks,
>>
>> Lin
>>
>>
>>
>>
>>
>> On Tue, Aug 19, 2008 at 4:38 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>
>>> A couple of comments...
>>>
>>> First, I thought you could already do this by leaving out the
>>> moduleId....
>>> you'd just get the dependencies installed. I might be wrong and this
>>> functionality might have broken along the way. Second, with this set of
>>> plugins all you need to specify is tomcat and upgrade-cli, the others
>>> should
>>> get pulled in via transitive dependencies I suspect you also want
>>> tomcat-deployer and jasper and I'm pretty sure you need to list the
>>> gshell
>>> plugins separately to get a working server.
>>>
>>> thanks
>>> david jencks
>>>
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 19, 2008, at 7:45 PM, Lin Sun wrote:
> I have tried to come up with the minimum plugins to build little G.
> In the case of tomcat, it needs the following plugins -
>
> org.apache.geronimo.assemblies/geronimo-boilerplate/2.2-SNAPSHOT/jar
> org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car
>
> Gshell related:
> org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car
> org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car
>
> Also all under Deployment category (I think one or two plugin can be
> removed here as they will be installed via transitive dependencies but
> it is nice just to select everything under deployment category):
> org.apache.geronimo.framework/upgrade-cli/2.2-SNAPSHOT/car
> org.apache.geronimo.framework/jsr88-cli/2.2-SNAPSHOT/car
> org.apache.geronimo.framework/jsr88-deploymentfactory/2.2-SNAPSHOT/car
> org.apache.geronimo.framework/offline-deployer/2.2-SNAPSHOT/car
> org.apache.geronimo.framework/online-deployer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/jsr88-ear-configurer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/jsr88-jar-configurer/2.2-SNAPSHOT/car
> <--I don't understand why Little G doesn't have this, but it has the
> jsr88-ear/rar/war-configurer...anyone has ideas-->
this is for app clients, not supported in little-g
>
> org.apache.geronimo.configs/jsr88-rar-configurer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/jsr88-war-configurer/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car
>
> Also I am missing the following three plugins, which aren't avail in
> my local geronimo-tomcat6-javaee5 server.
>
> + org.apache.geronimo.configs/unavailable-client-deployer/2.2-
> SNAPSHOT/car
> + org.apache.geronimo.configs/unavailable-ejb-deployer/2.2-SNAPSHOT/
> car
> + org.apache.geronimo.configs/unavailable-webservices-deployer/2.2-
> SNAPSHOT/car
>
> Anyone has an idea what are these for? Is it ok to build little G env
> without them?
Not sure if they are actually needed.... I've been meaning to check
and fix things so they aren't needed, assuming that they are. If they
are currently required you will find out as soon as you try to deploy
something jee related on the server.
I think the ear config builder needs to be changed so that if one of
the module builders is missing, the ear builder complains, rather than
relying on an "unavailable deployer" to complain.
I recommend rather strongly relying on transitive dependencies as much
as possible.
thanks
david jencks
>
>
> Thanks,
>
> Lin
>
>
>
>
>
> On Tue, Aug 19, 2008 at 4:38 PM, David Jencks
> <da...@yahoo.com> wrote:
>>
>
>> A couple of comments...
>>
>> First, I thought you could already do this by leaving out the
>> moduleId....
>> you'd just get the dependencies installed. I might be wrong and this
>> functionality might have broken along the way. Second, with this
>> set of
>> plugins all you need to specify is tomcat and upgrade-cli, the
>> others should
>> get pulled in via transitive dependencies I suspect you also want
>> tomcat-deployer and jasper and I'm pretty sure you need to list the
>> gshell
>> plugins separately to get a working server.
>>
>> thanks
>> david jencks
>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
I have tried to come up with the minimum plugins to build little G.
In the case of tomcat, it needs the following plugins -
org.apache.geronimo.assemblies/geronimo-boilerplate/2.2-SNAPSHOT/jar
org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/tomcat6-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/sharedlib/2.2-SNAPSHOT/car
Gshell related:
org.apache.geronimo.framework/gshell-geronimo/2.2-SNAPSHOT/car
org.apache.geronimo.framework/gshell-remote/2.2-SNAPSHOT/car
Also all under Deployment category (I think one or two plugin can be
removed here as they will be installed via transitive dependencies but
it is nice just to select everything under deployment category):
org.apache.geronimo.framework/upgrade-cli/2.2-SNAPSHOT/car
org.apache.geronimo.framework/jsr88-cli/2.2-SNAPSHOT/car
org.apache.geronimo.framework/jsr88-deploymentfactory/2.2-SNAPSHOT/car
org.apache.geronimo.framework/offline-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.framework/online-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/hot-deployer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jsr88-ear-configurer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jsr88-jar-configurer/2.2-SNAPSHOT/car
<--I don't understand why Little G doesn't have this, but it has the
jsr88-ear/rar/war-configurer...anyone has ideas-->
org.apache.geronimo.configs/jsr88-rar-configurer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/jsr88-war-configurer/2.2-SNAPSHOT/car
org.apache.geronimo.configs/remote-deploy-tomcat/2.2-SNAPSHOT/car
Also I am missing the following three plugins, which aren't avail in
my local geronimo-tomcat6-javaee5 server.
+ org.apache.geronimo.configs/unavailable-client-deployer/2.2-SNAPSHOT/car
+ org.apache.geronimo.configs/unavailable-ejb-deployer/2.2-SNAPSHOT/car
+ org.apache.geronimo.configs/unavailable-webservices-deployer/2.2-SNAPSHOT/car
Anyone has an idea what are these for? Is it ok to build little G env
without them?
Thanks,
Lin
On Tue, Aug 19, 2008 at 4:38 PM, David Jencks <da...@yahoo.com> wrote:
>
> A couple of comments...
>
> First, I thought you could already do this by leaving out the moduleId....
> you'd just get the dependencies installed. I might be wrong and this
> functionality might have broken along the way. Second, with this set of
> plugins all you need to specify is tomcat and upgrade-cli, the others should
> get pulled in via transitive dependencies I suspect you also want
> tomcat-deployer and jasper and I'm pretty sure you need to list the gshell
> plugins separately to get a working server.
>
> thanks
> david jencks
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 19, 2008, at 1: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="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.
A couple of comments...
First, I thought you could already do this by leaving out the
moduleId.... you'd just get the dependencies installed. I might be
wrong and this functionality might have broken along the way. Second,
with this set of plugins all you need to specify is tomcat and upgrade-
cli, the others should get pulled in via transitive dependencies I
suspect you also want tomcat-deployer and jasper and I'm pretty sure
you need to list the gshell plugins separately to get a working server.
thanks
david jencks
>
>
> 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
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Jarek Gawor <jg...@gmail.com>.
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 <li...@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
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
Looking good.
Seems that this would have to be part of our regular builds, otherwise
they would never be maintained if it requires manual editing of files.
I would like to see a "profiles" directory created in the build tree,
either as a peer to assemblies or as a child of assemblies. Also, using
the c-m-p to build the plugin data form a pom.xml seems a given to me.
I wouldn't worry about Joe's "upgrade scenario" for now, but concentrate
on how to define profiles, build assemblies from profiles and/or
applications and how to present all of this in a easy to use fashion.
-Donald
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="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
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
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
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Jack Cai <gr...@gmail.com>.
If we can make the customization process very easy in the first place, then
it won't be a pain to recreate the custom server due to a Geronimo upgrade.
Surely we can allow the user to export the config for a custom server, but
it might not be a good scenario for the users to edit this file by hand to
update versions and things like that. This requires the user to have a very
good knowledge about Geronimo. A better scenario is to let the system import
the old config and automatically "absorb" the changes, but the
implementation might not be as easy as the first thought, considering some
components might be completely replaced with another implementation.
- Jack
2008/8/18 Joe Bohn <jo...@earthlink.net>
> Kevan Miller wrote:
>
>>
>> On Aug 12, 2008, at 6:11 PM, David Jencks wrote:
>>
>>
>>> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>>>
>>> I appreciate your valuable feedback!
>>>>
>>>> Currently, a user doesn't have that much choices, as we only allow the
>>>> user to assemble a new server out of plugins in local server, unless
>>>> we want to change this behavior.
>>>>
>>>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>>>> only choose tomcat + axis2. If a user installs the
>>>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>>>>
>>>
>>> true... for now :-)
>>>
>>>>
>>>>
>>>> To simplify things, here is what I suggest. We allow the users to
>>>> choose from -
>>>>
>>>> __ Web
>>>>
>>> __jsp
>>>
>>>>
>>>> __ JMS
>>>> __ Web Services
>>>> __ EJB
>>>> __ OpenJPA
>>>> __ Deployment
>>>> __ Admin Console
>>>> __ Cluster (tomcat only?)
>>>>
>>> __wadi clustering
>>>
>>>>
>>>>
>>>> Then the user can just select one or more functions they need and
>>>> request for the customer assembly server to be created. Optionally,
>>>> the user can add on additional deployed apps or other system modules
>>>> then request for the customer assembly server to be created.
>>>>
>>>
>>> I wonder if we can think bigger :-)
>>>
>>> What if we distributed something with _all_ the cars in it and
>>> customizable profiles for the servers we ship now? So, you wouldn't unpack
>>> a particular server, but the server construction kit. You could pick a
>>> profile and optionally modify it, then spit out the desired server. Then
>>> you would be able to pick jetty/tomcat and cxf/axis2 and however much
>>> deployment you wanted.
>>>
>>> Alternatively maybe the "assemble a server" can show plugins from more
>>> than just the current server.
>>>
>>
>> Sounds similar (same?) to something I've been thinking of... I was
>> thinking we could include multiple config.xml files. These files could be
>> specified when starting a server. E.g.:
>>
>> ./gsh geronimo/start-server -c jee-config.xml
>> ./gsh geronimo/start-server -c minimal-config.xml
>> ./gsh geronimo/start-server -c joes-custom-config.xml
>>
>> If server footprint is a concern, you can still create custom assemblies
>> based on these "profiles".
>>
>> I'm not sure we'd want to include *all* cars and include a wide variety of
>> possible config files. We certainly could, but I might stick with current
>> tomcat/axis2 and jetty/cxf specific variants and maintain a "server" focus,
>> rather than a "server construction" focus. I also don't think that such a
>> capability would necessarily replace the function that Lin is proposing.
>>
>
>
> Hi all,
>
> I'm still catching up after being away ...
>
> This all sounds very similar to the features we had discussed long ago that
> led the the creation of plugins themselves and the Geronimo Framework
> Assembly. At the time we discussed the notion of templates which were
> basically like the configuration files mentioned by Kevan above. We could
> ship a number of predefined templates along with a collection of plugins
> (aka the "server construction kit") which could be used to generate a server
> image. We debated the notion of packaging all of the plugins into a tarball
> or using the maven repos - both seem viable. The user could also create
> their own templates and persist them for future use.
>
> I think the key notion there was the idea of this persistent, small
> "definition" of a server image content we were calling a "template" at the
> time. This provided a mechanism that could potentially be leveraged across
> server releases with minor changes to create consistent server image as a
> user upgraded from Geronimo 2.x to Geronimo 2.X+1 without a lot of manual
> effort (such as repeating a set of steps in the console, command line, or
> whatever perhaps months or years later). For example, if you wanted the
> same server image you created for 2.1.2 in 2.2 you could potentially:
> 1) take your 2.1.2 template (config.xml like thingy)
> 2) update it as appropriate for version changes or perhaps replacement
> modules (leveraging cxf instead of axis2)
> 3) run it through an assembly utility in 2.2 (console, command line,
> whatever)
> 4) Have a server image spit out the other end that is similar to the 2.1.2
> assembly but upgraded to 2.2.
>
> I think this upgrade scenario is an important aspect of the building custom
> assemblies that must be considered.
>
> Joe
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Joe Bohn <jo...@earthlink.net>.
Kevan Miller wrote:
>
> On Aug 12, 2008, at 6:11 PM, David Jencks wrote:
>
>>
>> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>>
>>> I appreciate your valuable feedback!
>>>
>>> Currently, a user doesn't have that much choices, as we only allow the
>>> user to assemble a new server out of plugins in local server, unless
>>> we want to change this behavior.
>>>
>>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>>> only choose tomcat + axis2. If a user installs the
>>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>>
>> true... for now :-)
>>>
>>>
>>> To simplify things, here is what I suggest. We allow the users to
>>> choose from -
>>>
>>> __ Web
>> __jsp
>>>
>>> __ JMS
>>> __ Web Services
>>> __ EJB
>>> __ OpenJPA
>>> __ Deployment
>>> __ Admin Console
>>> __ Cluster (tomcat only?)
>> __wadi clustering
>>>
>>>
>>> Then the user can just select one or more functions they need and
>>> request for the customer assembly server to be created. Optionally,
>>> the user can add on additional deployed apps or other system modules
>>> then request for the customer assembly server to be created.
>>
>> I wonder if we can think bigger :-)
>>
>> What if we distributed something with _all_ the cars in it and
>> customizable profiles for the servers we ship now? So, you wouldn't
>> unpack a particular server, but the server construction kit. You
>> could pick a profile and optionally modify it, then spit out the
>> desired server. Then you would be able to pick jetty/tomcat and
>> cxf/axis2 and however much deployment you wanted.
>>
>> Alternatively maybe the "assemble a server" can show plugins from more
>> than just the current server.
>
> Sounds similar (same?) to something I've been thinking of... I was
> thinking we could include multiple config.xml files. These files could
> be specified when starting a server. E.g.:
>
> ./gsh geronimo/start-server -c jee-config.xml
> ./gsh geronimo/start-server -c minimal-config.xml
> ./gsh geronimo/start-server -c joes-custom-config.xml
>
> If server footprint is a concern, you can still create custom assemblies
> based on these "profiles".
>
> I'm not sure we'd want to include *all* cars and include a wide variety
> of possible config files. We certainly could, but I might stick with
> current tomcat/axis2 and jetty/cxf specific variants and maintain a
> "server" focus, rather than a "server construction" focus. I also don't
> think that such a capability would necessarily replace the function that
> Lin is proposing.
Hi all,
I'm still catching up after being away ...
This all sounds very similar to the features we had discussed long ago
that led the the creation of plugins themselves and the Geronimo
Framework Assembly. At the time we discussed the notion of templates
which were basically like the configuration files mentioned by Kevan
above. We could ship a number of predefined templates along with a
collection of plugins (aka the "server construction kit") which could be
used to generate a server image. We debated the notion of packaging all
of the plugins into a tarball or using the maven repos - both seem
viable. The user could also create their own templates and persist them
for future use.
I think the key notion there was the idea of this persistent, small
"definition" of a server image content we were calling a "template" at
the time. This provided a mechanism that could potentially be leveraged
across server releases with minor changes to create consistent server
image as a user upgraded from Geronimo 2.x to Geronimo 2.X+1 without a
lot of manual effort (such as repeating a set of steps in the console,
command line, or whatever perhaps months or years later). For example,
if you wanted the same server image you created for 2.1.2 in 2.2 you
could potentially:
1) take your 2.1.2 template (config.xml like thingy)
2) update it as appropriate for version changes or perhaps replacement
modules (leveraging cxf instead of axis2)
3) run it through an assembly utility in 2.2 (console, command line,
whatever)
4) Have a server image spit out the other end that is similar to the
2.1.2 assembly but upgraded to 2.2.
I think this upgrade scenario is an important aspect of the building
custom assemblies that must be considered.
Joe
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
I think footprint could be a concern for users in developing
countries. A user may only want to download what he needs.
I also agree such capability doesn't overlap what I am proposing, as a
user could still want to build custom assembly server out of his
current server.
Lin
> Sounds similar (same?) to something I've been thinking of... I was thinking
> we could include multiple config.xml files. These files could be specified
> when starting a server. E.g.:
>
> ./gsh geronimo/start-server -c jee-config.xml
> ./gsh geronimo/start-server -c minimal-config.xml
> ./gsh geronimo/start-server -c joes-custom-config.xml
>
> If server footprint is a concern, you can still create custom assemblies
> based on these "profiles".
>
> I'm not sure we'd want to include *all* cars and include a wide variety of
> possible config files. We certainly could, but I might stick with current
> tomcat/axis2 and jetty/cxf specific variants and maintain a "server" focus,
> rather than a "server construction" focus. I also don't think that such a
> capability would necessarily replace the function that Lin is proposing.
>
> --kevan
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Rex Wang <rw...@gmail.com>.
So, I think it is not necessary to limit that
" if a user installs the geronimo-tomcat-javaee5 assembly, he can
only choose tomcat + axis2. If a user installs the
geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf."
We can list all the function here, and user also can choose them all,
If the plugin does not stay in current server, then before the assembling
process,
a page show a list of the missing plugins and tell that it will download
them from the repo on internet to complete the assembly, and also will
provide an estimated cost of time for user.
Make sense?
Rex.
2008/8/13 Jack <gr...@gmail.com>
> Thanks Lin for bringing this up! This is a very valuable improvement to
> make the custom server assembly feature truly usable.
>
> I really like the idea of grouping functions and describing them in a
> language that is understandable to users. I think we can organize them in a
> hierachy, similar to the way how we select features to install during a
> desktop application installation. Grabbed a random snapshot here:
> http://www.tenouk.com/clabworksheet/windowspsdk_files/windowssdkpsdk008.png
>
> As to the proposed list, I would suggest the following changes/additions
> * Break down Web further into JSP+Servlet and JSF
> * Change OpenJPA to JPA. I guess user does not have to care about whether
> it's OpenJPA or whatever else.
> * Add JTA, JavaMail. Suppose Security is by default included...
>
> Last but not least, if a user uses the custom server assembly function in a
> customized server (say, without JPA), will we allow the user to select JPA?
>
> - Jack
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Jack <gr...@gmail.com>.
Thanks Lin for bringing this up! This is a very valuable improvement to make
the custom server assembly feature truly usable.
I really like the idea of grouping functions and describing them in a
language that is understandable to users. I think we can organize them in a
hierachy, similar to the way how we select features to install during a
desktop application installation. Grabbed a random snapshot here:
http://www.tenouk.com/clabworksheet/windowspsdk_files/windowssdkpsdk008.png
As to the proposed list, I would suggest the following changes/additions
* Break down Web further into JSP+Servlet and JSF
* Change OpenJPA to JPA. I guess user does not have to care about whether
it's OpenJPA or whatever else.
* Add JTA, JavaMail. Suppose Security is by default included...
Last but not least, if a user uses the custom server assembly function in a
customized server (say, without JPA), will we allow the user to select JPA?
- Jack
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 12, 2008, at 6:11 PM, David Jencks wrote:
>
> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>
>> I appreciate your valuable feedback!
>>
>> Currently, a user doesn't have that much choices, as we only allow
>> the
>> user to assemble a new server out of plugins in local server, unless
>> we want to change this behavior.
>>
>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>> only choose tomcat + axis2. If a user installs the
>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>
> true... for now :-)
>>
>>
>> To simplify things, here is what I suggest. We allow the users to
>> choose from -
>>
>> __ Web
> __jsp
>>
>> __ JMS
>> __ Web Services
>> __ EJB
>> __ OpenJPA
>> __ Deployment
>> __ Admin Console
>> __ Cluster (tomcat only?)
> __wadi clustering
>>
>>
>> Then the user can just select one or more functions they need and
>> request for the customer assembly server to be created. Optionally,
>> the user can add on additional deployed apps or other system modules
>> then request for the customer assembly server to be created.
>
> I wonder if we can think bigger :-)
>
> What if we distributed something with _all_ the cars in it and
> customizable profiles for the servers we ship now? So, you wouldn't
> unpack a particular server, but the server construction kit. You
> could pick a profile and optionally modify it, then spit out the
> desired server. Then you would be able to pick jetty/tomcat and cxf/
> axis2 and however much deployment you wanted.
>
> Alternatively maybe the "assemble a server" can show plugins from
> more than just the current server.
Sounds similar (same?) to something I've been thinking of... I was
thinking we could include multiple config.xml files. These files could
be specified when starting a server. E.g.:
./gsh geronimo/start-server -c jee-config.xml
./gsh geronimo/start-server -c minimal-config.xml
./gsh geronimo/start-server -c joes-custom-config.xml
If server footprint is a concern, you can still create custom
assemblies based on these "profiles".
I'm not sure we'd want to include *all* cars and include a wide
variety of possible config files. We certainly could, but I might
stick with current tomcat/axis2 and jetty/cxf specific variants and
maintain a "server" focus, rather than a "server construction" focus.
I also don't think that such a capability would necessarily replace
the function that Lin is proposing.
--kevan
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
> I appreciate your valuable feedback!
>
> Currently, a user doesn't have that much choices, as we only allow the
> user to assemble a new server out of plugins in local server, unless
> we want to change this behavior.
>
> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
> only choose tomcat + axis2. If a user installs the
> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
true... for now :-)
>
>
> To simplify things, here is what I suggest. We allow the users to
> choose from -
>
> __ Web
__jsp
>
> __ JMS
> __ Web Services
> __ EJB
> __ OpenJPA
> __ Deployment
> __ Admin Console
> __ Cluster (tomcat only?)
__wadi clustering
>
>
> Then the user can just select one or more functions they need and
> request for the customer assembly server to be created. Optionally,
> the user can add on additional deployed apps or other system modules
> then request for the customer assembly server to be created.
I wonder if we can think bigger :-)
What if we distributed something with _all_ the cars in it and
customizable profiles for the servers we ship now? So, you wouldn't
unpack a particular server, but the server construction kit. You
could pick a profile and optionally modify it, then spit out the
desired server. Then you would be able to pick jetty/tomcat and cxf/
axis2 and however much deployment you wanted.
Alternatively maybe the "assemble a server" can show plugins from more
than just the current server.
thanks
david jencks
>
>
> Lin
>
> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks
> <da...@yahoo.com> wrote:
>>
>> client profiles might be apropriate too.
>>
>> I wonder how much of this is actually necessary? e.g. if you
>> install the
>> jetty-deployer plugin you get jetty too. If you install the jetty-
>> console
>> you get jetty....
>>
>> What if we had a "select the parts" page that was organized
>> differently than
>> the list of plugins.... e.g. checkboxes for web, ejb, webservices.
>> If you
>> say yes to web, you get to choose jetty/tomcat, whether you want
>> deployment,
>> whether you want the console.
>>
>> Choosing web or ejb gives you the opportunity to include openjpa
>> ( or maybe
>> toplink in the future)
>> Choosing webservices gives you the choice of cxf or axis2
>>
>>
>> Just some more or less random thoughts
>> david jencks
>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
I appreciate your valuable feedback!
Currently, a user doesn't have that much choices, as we only allow the
user to assemble a new server out of plugins in local server, unless
we want to change this behavior.
So if a user installs the geronimo-tomcat-javaee5 assembly, he can
only choose tomcat + axis2. If a user installs the
geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
To simplify things, here is what I suggest. We allow the users to choose from -
__ Web
__ JMS
__ Web Services
__ EJB
__ OpenJPA
__ Deployment
__ Admin Console
__ Cluster (tomcat only?)
Then the user can just select one or more functions they need and
request for the customer assembly server to be created. Optionally,
the user can add on additional deployed apps or other system modules
then request for the customer assembly server to be created.
Lin
On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <da...@yahoo.com> wrote:
>
> client profiles might be apropriate too.
>
> I wonder how much of this is actually necessary? e.g. if you install the
> jetty-deployer plugin you get jetty too. If you install the jetty-console
> you get jetty....
>
> What if we had a "select the parts" page that was organized differently than
> the list of plugins.... e.g. checkboxes for web, ejb, webservices. If you
> say yes to web, you get to choose jetty/tomcat, whether you want deployment,
> whether you want the console.
>
> Choosing web or ejb gives you the opportunity to include openjpa ( or maybe
> toplink in the future)
> Choosing webservices gives you the choice of cxf or axis2
>
>
> Just some more or less random thoughts
> david jencks
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by David Jencks <da...@yahoo.com>.
On Aug 12, 2008, at 12:47 PM, Lin Sun wrote:
> Thanks again for the valuable feedback - Donald and Kevan!
>
> If profile is what people are interested in, we need to identify what
> profiles we want to provide and the plugins that each profile
> contains. We also want to think what type(s) of deployment we want
> to provide with these profiles. Do we always provide the command
> line deployment with the profiles, or hot deployment, or console
> deployment or gshell deployment, or we always provide all the
> deployment options for each of the profile? I am sure there are other
> options/variables.
>
> Here are some possible profiles -
>
> - Web (our minimal assembly today)
> - Web + JMS
> - Web + EJB
> - Web + Web Services
> - Web + EJB + Persistence
> - Web + Admin Console
> - Web + JMS + Admin Console
> - Web + EJB + Admin Console
> - Web + JSF
> - Web + Clustering
client profiles might be apropriate too.
I wonder how much of this is actually necessary? e.g. if you install
the jetty-deployer plugin you get jetty too. If you install the jetty-
console you get jetty....
What if we had a "select the parts" page that was organized
differently than the list of plugins.... e.g. checkboxes for web, ejb,
webservices. If you say yes to web, you get to choose jetty/tomcat,
whether you want deployment, whether you want the console.
Choosing web or ejb gives you the opportunity to include openjpa ( or
maybe toplink in the future)
Choosing webservices gives you the choice of cxf or axis2
Just some more or less random thoughts
david jencks
>
> ...
>
> I think it could be too much combinations than we can handle, unless
> we can identify the exact profiles that users will likely want.
>
> If we allow users to pick profiles, it is nice we provide users with
> profiles that we can test and verify first. However, the user may end
> up not seeing the function combination he desires.
>
> If we allow users to pick functions (a function is a group of
> plugins), the user will have the maximum flexibility and we can still
> test the common combination of functions (which is same as profiles).
>
> Lin
>
>
>
>
>
> On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller
> <ke...@gmail.com> wrote:
>>
>> On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
>>
>>> Keeping 3 starting paths is fine, but we need to make sure we
>>> reuse the
>>> same portlet views throughout.
>>>
>>> Also, I've heard second hand from other community members (like
>>> Kevan -
>>> cough cough) that they have talked to end users who wanted
>>> simplified/tested
>>> profiles to use for assembling servers (like Web + JMS). If we
>>> provide
>>> application and advanced paths, then we also need to provide a
>>> profile/function path, which would allow companies/ISVs to create
>>> custom
>>> packages tailored to different development groups that only
>>> contain the
>>> function they need.
>>
>> :-) I have had conversations where that was requested and seem to
>> recall
>> musing/wishing for this in the past...
>>
>> Glad to see this discussion occurring.
>>
>> I like the concept of profiles.
>>
>> My one comment, at the moment, is the discussion may be too focused
>> on the
>> admin console. I'd like to be sure we also include command-based
>> scenarios
>> as well (and even maven?). IMO, we should permit the same basic
>> abstractions
>> (at least for the command-based scenario).
>>
>> --kevan
>>
>>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Thanks again for the valuable feedback - Donald and Kevan!
If profile is what people are interested in, we need to identify what
profiles we want to provide and the plugins that each profile
contains. We also want to think what type(s) of deployment we want
to provide with these profiles. Do we always provide the command
line deployment with the profiles, or hot deployment, or console
deployment or gshell deployment, or we always provide all the
deployment options for each of the profile? I am sure there are other
options/variables.
Here are some possible profiles -
- Web (our minimal assembly today)
- Web + JMS
- Web + EJB
- Web + Web Services
- Web + EJB + Persistence
- Web + Admin Console
- Web + JMS + Admin Console
- Web + EJB + Admin Console
- Web + JSF
- Web + Clustering
...
I think it could be too much combinations than we can handle, unless
we can identify the exact profiles that users will likely want.
If we allow users to pick profiles, it is nice we provide users with
profiles that we can test and verify first. However, the user may end
up not seeing the function combination he desires.
If we allow users to pick functions (a function is a group of
plugins), the user will have the maximum flexibility and we can still
test the common combination of functions (which is same as profiles).
Lin
On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller <ke...@gmail.com> wrote:
>
> On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
>
>> Keeping 3 starting paths is fine, but we need to make sure we reuse the
>> same portlet views throughout.
>>
>> Also, I've heard second hand from other community members (like Kevan -
>> cough cough) that they have talked to end users who wanted simplified/tested
>> profiles to use for assembling servers (like Web + JMS). If we provide
>> application and advanced paths, then we also need to provide a
>> profile/function path, which would allow companies/ISVs to create custom
>> packages tailored to different development groups that only contain the
>> function they need.
>
> :-) I have had conversations where that was requested and seem to recall
> musing/wishing for this in the past...
>
> Glad to see this discussion occurring.
>
> I like the concept of profiles.
>
> My one comment, at the moment, is the discussion may be too focused on the
> admin console. I'd like to be sure we also include command-based scenarios
> as well (and even maven?). IMO, we should permit the same basic abstractions
> (at least for the command-based scenario).
>
> --kevan
>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Kevan Miller <ke...@gmail.com>.
On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
> Keeping 3 starting paths is fine, but we need to make sure we reuse
> the same portlet views throughout.
>
> Also, I've heard second hand from other community members (like
> Kevan - cough cough) that they have talked to end users who wanted
> simplified/tested profiles to use for assembling servers (like Web +
> JMS). If we provide application and advanced paths, then we also
> need to provide a profile/function path, which would allow companies/
> ISVs to create custom packages tailored to different development
> groups that only contain the function they need.
:-) I have had conversations where that was requested and seem to
recall musing/wishing for this in the past...
Glad to see this discussion occurring.
I like the concept of profiles.
My one comment, at the moment, is the discussion may be too focused on
the admin console. I'd like to be sure we also include command-based
scenarios as well (and even maven?). IMO, we should permit the same
basic abstractions (at least for the command-based scenario).
--kevan
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
Keeping 3 starting paths is fine, but we need to make sure we reuse the
same portlet views throughout.
Also, I've heard second hand from other community members (like Kevan -
cough cough) that they have talked to end users who wanted
simplified/tested profiles to use for assembling servers (like Web +
JMS). If we provide application and advanced paths, then we also need
to provide a profile/function path, which would allow companies/ISVs to
create custom packages tailored to different development groups that
only contain the function they need.
-Donald
Lin Sun wrote:
> Thanks for the valuable feedback.
>
> So basically, you are proposing to consolidate 3 options to 2 options
> and provide the advanced configuration option at the end of either
> option. I think it will still be useful to keep the advanced
> configuration option by itself for advanced users who knows exactly
> which plugins they want. This option can produce a custom server
> that is not producible from other two options.
>
> Here is what I understand of application centric custom assembly. I
> think the purpose is that the user deploys the application onto the
> server and the user is satisfied with everything, then he builds a
> customer server out of it. He wants to keep the assembly as small as
> possible with his application running, and it is not important to the
> user if he could deploy any other projects to the server. In this
> case, I think it is better not to present the advanced configuration
> option as it can confuse users, but it would be fine for me to provide
> that if you guys disagree.
>
> The profile concept you proposed is like a group of functions. I
> think I'd rather let users to select functions instead of providing
> profiles to keep things simple, as we may not be able to suggest the
> right profiles for users and some users may end up not seeing a set of
> functions he desires to see in the list of profiles.
>
> For functional based assembly, I like what you proposed of providing
> an advanced configuration at the end to add additional system modules
> or application modules if desired.
>
> Create a local server instance is interesting... something I haven't
> thought of so far. It can certainly be considered after the above
> items.
>
> Lin
>
>
>
>
>
>
>
> On Mon, Aug 11, 2008 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>> Yep, the current custom assembly portlet needs some love...
>>
>> I agree that there are three usage scenarios, but thinking that we could
>> handle all with the same portlet. We don't want users to start down an
>> "application" path only to find out that they can't add additional modules
>> (like the deployers, monitoring, ...) and have to start over and use the
>> advanced path.
>>
>> Maybe we can create a set of views that are displayed or hidden, based on
>> how the user starts, like
>> 1) "Create a server assembly based on a deployed application"
>> - prompts user to choose from deployed application(s) (but hides system
>> modules)
>> - presents user with an "advanced options" link, to add other system
>> modules
>> 2) "Create a server assembly based on a profile"
>> - prompts user to choose from a predetermined list of profiles
>> - Web (our minimal assembly today)
>> - Web + JMS
>> - Web + EJB
>> - Web + ....
>> - presents user with an option to "add deployed application(s)"
>> - presents user with an "advanced options" link, to add other system
>> modules
>>
>> Also, would be nice to give the option to create a local server instance
>> (sharing the same repo), along with the existing zip/tar option....
>>
>>
>> -Donald
>>
>>
>>
>> Lin Sun wrote:
>>> Hi,
>>>
>>> I'd like to enhance the assemble server portlet's usability.
>>> Currently it is hard to come up with a desired custom server assembly.
>>>
>>> For example, I want to create a custom server that provides similar
>>> function as tomcat. To do this, I picked the boilerplate-minimal,
>>> tomcat and tomcat-deployer to build my custom server. However, soon I
>>> found out that I am not able to deploy anything to the server, as I
>>> didn't select any plugins to enable command deployer or hot deployer
>>> or console deployer or gshell deployment. So I went back to the
>>> assemble server portlet and I saw so many plugins related to
>>> deployment, by looking at the plugins under the Deployment category-
>>>
>>> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
>>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
>>> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
>>> org.apache.geronimo.framework/offline-deployer/2.1.2/car
>>> org.apache.geronimo.framework/online-deployer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>>>
>>> Which one do I pick? I don't want to select any extra ones... I just
>>> want to enable command line deployer for war modules. By poking
>>> around the pom.xml files, I think I only need to select
>>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
>>> boilerplate-minimal, tomcat and tomcat-deployer.
>>>
>>> To improve the usability, I suggest the following:
>>>
>>>> From the assemble server portlet, a user can choose what type of
>>> customer assembly he/she wants to build:
>>>
>>> - Functional custom assembly
>>> - Application scope custom assembly
>>> - Advanced configuration
>>>
>>> Selecting "Function custom assembly" will lead to selection of key
>>> functions of the server, and we can use the category of plugins to
>>> associate functions and plugins. Instead of displaying all the
>>> plugins, we group the plugins by their function(category) and display
>>> the function only. I think it would be nice to see some explanation
>>> of each function. For example:
>>> - Geronimo Core - plugins that provide the core service of the
>>> geronimo server...
>>> - Web Services - plugins that provides the web service stack of the
>>> geronimo server...
>>> - Deployment - plugins that enables you to deploy apps onto the server...
>>> ...
>>>
>>> If desired, users have the option to see what plugins are associated
>>> with a function, such as Geronimo Core. Also, if we want to provide
>>> detailed functions, we can update the category to be more accurate,
>>> such as Deployment: Offline Deployment, Deployment : Command Line
>>> Deployer, Deployment: Hot Deploy, etc.
>>>
>>> Selecting "Application scope custom assembly" will lead to selection
>>> of custom applications deployed to the server. We can also warn our
>>> users that the custom server may not be able to deploy anything.
>>>
>>> Selecting "Advanced configuration" will lead to the current assemble
>>> server page that allows a user to select plugins from all the plugins
>>> in local server. This assumes the user knows the plugins in local
>>> server well.
>>>
>>> For all options, we should always display the pre-selected
>>> boilerplate-minimal.
>>>
>>> Comments are welcome! If there is no objection, I'll start working on
>>> this.
>>>
>>> Lin
>>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Sorry for sending this message multiple times. I had some probs with
gmail so I thought the message was not sent out but it actually did.
Lin
On Mon, Aug 11, 2008 at 5:51 PM, Lin Sun <li...@gmail.com> wrote:
> Thanks for the valuable feedback.
>
> So basically, you are proposing to consolidate 3 options to 2 options
> and provide the advanced configuration option at the end of either
> option. I think it will still be useful to keep the advanced
> configuration option by itself for advanced users who knows exactly
> which plugins they want. This option can produce a custom server
> that is not producible from other two options.
>
> Here is what I understand of application centric custom assembly. I
> think the purpose is that the user deploys the application onto the
> server and the user is satisfied with everything, then he builds a
> customer server out of it. He wants to keep the assembly as small as
> possible with his application running, and it is not important to the
> user if he could deploy any other projects to the server. In this
> case, I think it is better not to present the advanced configuration
> option as it can confuse users, but it would be fine for me to provide
> that if you guys disagree.
>
> The profile concept you proposed is like a group of functions. I
> think I'd rather let users to select functions instead of providing
> profiles to keep things simple, as we may not be able to suggest the
> right profiles for users and some users may end up not seeing a set of
> functions he desires to see in the list of profiles.
>
> For functional based assembly, I like what you proposed of providing
> an advanced configuration at the end to add additional system modules
> or application modules if desired.
>
> Create a local server instance is interesting... something I haven't
> thought of so far. It can certainly be considered after the above
> items.
>
> Lin
>
>
>
>
>
>
>
> On Mon, Aug 11, 2008 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
>> Yep, the current custom assembly portlet needs some love...
>>
>> I agree that there are three usage scenarios, but thinking that we could
>> handle all with the same portlet. We don't want users to start down an
>> "application" path only to find out that they can't add additional modules
>> (like the deployers, monitoring, ...) and have to start over and use the
>> advanced path.
>>
>> Maybe we can create a set of views that are displayed or hidden, based on
>> how the user starts, like
>> 1) "Create a server assembly based on a deployed application"
>> - prompts user to choose from deployed application(s) (but hides system
>> modules)
>> - presents user with an "advanced options" link, to add other system
>> modules
>> 2) "Create a server assembly based on a profile"
>> - prompts user to choose from a predetermined list of profiles
>> - Web (our minimal assembly today)
>> - Web + JMS
>> - Web + EJB
>> - Web + ....
>> - presents user with an option to "add deployed application(s)"
>> - presents user with an "advanced options" link, to add other system
>> modules
>>
>> Also, would be nice to give the option to create a local server instance
>> (sharing the same repo), along with the existing zip/tar option....
>>
>>
>> -Donald
>>
>>
>>
>> Lin Sun wrote:
>>>
>>> Hi,
>>>
>>> I'd like to enhance the assemble server portlet's usability.
>>> Currently it is hard to come up with a desired custom server assembly.
>>>
>>> For example, I want to create a custom server that provides similar
>>> function as tomcat. To do this, I picked the boilerplate-minimal,
>>> tomcat and tomcat-deployer to build my custom server. However, soon I
>>> found out that I am not able to deploy anything to the server, as I
>>> didn't select any plugins to enable command deployer or hot deployer
>>> or console deployer or gshell deployment. So I went back to the
>>> assemble server portlet and I saw so many plugins related to
>>> deployment, by looking at the plugins under the Deployment category-
>>>
>>> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
>>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
>>> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
>>> org.apache.geronimo.framework/offline-deployer/2.1.2/car
>>> org.apache.geronimo.framework/online-deployer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
>>> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>>>
>>> Which one do I pick? I don't want to select any extra ones... I just
>>> want to enable command line deployer for war modules. By poking
>>> around the pom.xml files, I think I only need to select
>>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
>>> boilerplate-minimal, tomcat and tomcat-deployer.
>>>
>>> To improve the usability, I suggest the following:
>>>
>>>> From the assemble server portlet, a user can choose what type of
>>>
>>> customer assembly he/she wants to build:
>>>
>>> - Functional custom assembly
>>> - Application scope custom assembly
>>> - Advanced configuration
>>>
>>> Selecting "Function custom assembly" will lead to selection of key
>>> functions of the server, and we can use the category of plugins to
>>> associate functions and plugins. Instead of displaying all the
>>> plugins, we group the plugins by their function(category) and display
>>> the function only. I think it would be nice to see some explanation
>>> of each function. For example:
>>> - Geronimo Core - plugins that provide the core service of the
>>> geronimo server...
>>> - Web Services - plugins that provides the web service stack of the
>>> geronimo server...
>>> - Deployment - plugins that enables you to deploy apps onto the server...
>>> ...
>>>
>>> If desired, users have the option to see what plugins are associated
>>> with a function, such as Geronimo Core. Also, if we want to provide
>>> detailed functions, we can update the category to be more accurate,
>>> such as Deployment: Offline Deployment, Deployment : Command Line
>>> Deployer, Deployment: Hot Deploy, etc.
>>>
>>> Selecting "Application scope custom assembly" will lead to selection
>>> of custom applications deployed to the server. We can also warn our
>>> users that the custom server may not be able to deploy anything.
>>>
>>> Selecting "Advanced configuration" will lead to the current assemble
>>> server page that allows a user to select plugins from all the plugins
>>> in local server. This assumes the user knows the plugins in local
>>> server well.
>>>
>>> For all options, we should always display the pre-selected
>>> boilerplate-minimal.
>>>
>>> Comments are welcome! If there is no objection, I'll start working on
>>> this.
>>>
>>> Lin
>>>
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Thanks for the valuable feedback.
So basically, you are proposing to consolidate 3 options to 2 options
and provide the advanced configuration option at the end of either
option. I think it will still be useful to keep the advanced
configuration option by itself for advanced users who knows exactly
which plugins they want. This option can produce a custom server
that is not producible from other two options.
Here is what I understand of application centric custom assembly. I
think the purpose is that the user deploys the application onto the
server and the user is satisfied with everything, then he builds a
customer server out of it. He wants to keep the assembly as small as
possible with his application running, and it is not important to the
user if he could deploy any other projects to the server. In this
case, I think it is better not to present the advanced configuration
option as it can confuse users, but it would be fine for me to provide
that if you guys disagree.
The profile concept you proposed is like a group of functions. I
think I'd rather let users to select functions instead of providing
profiles to keep things simple, as we may not be able to suggest the
right profiles for users and some users may end up not seeing a set of
functions he desires to see in the list of profiles.
For functional based assembly, I like what you proposed of providing
an advanced configuration at the end to add additional system modules
or application modules if desired.
Create a local server instance is interesting... something I haven't
thought of so far. It can certainly be considered after the above
items.
Lin
On Mon, Aug 11, 2008 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
> Yep, the current custom assembly portlet needs some love...
>
> I agree that there are three usage scenarios, but thinking that we could
> handle all with the same portlet. We don't want users to start down an
> "application" path only to find out that they can't add additional modules
> (like the deployers, monitoring, ...) and have to start over and use the
> advanced path.
>
> Maybe we can create a set of views that are displayed or hidden, based on
> how the user starts, like
> 1) "Create a server assembly based on a deployed application"
> - prompts user to choose from deployed application(s) (but hides system
> modules)
> - presents user with an "advanced options" link, to add other system
> modules
> 2) "Create a server assembly based on a profile"
> - prompts user to choose from a predetermined list of profiles
> - Web (our minimal assembly today)
> - Web + JMS
> - Web + EJB
> - Web + ....
> - presents user with an option to "add deployed application(s)"
> - presents user with an "advanced options" link, to add other system
> modules
>
> Also, would be nice to give the option to create a local server instance
> (sharing the same repo), along with the existing zip/tar option....
>
>
> -Donald
>
>
>
> Lin Sun wrote:
>>
>> Hi,
>>
>> I'd like to enhance the assemble server portlet's usability.
>> Currently it is hard to come up with a desired custom server assembly.
>>
>> For example, I want to create a custom server that provides similar
>> function as tomcat. To do this, I picked the boilerplate-minimal,
>> tomcat and tomcat-deployer to build my custom server. However, soon I
>> found out that I am not able to deploy anything to the server, as I
>> didn't select any plugins to enable command deployer or hot deployer
>> or console deployer or gshell deployment. So I went back to the
>> assemble server portlet and I saw so many plugins related to
>> deployment, by looking at the plugins under the Deployment category-
>>
>> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
>> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
>> org.apache.geronimo.framework/offline-deployer/2.1.2/car
>> org.apache.geronimo.framework/online-deployer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>>
>> Which one do I pick? I don't want to select any extra ones... I just
>> want to enable command line deployer for war modules. By poking
>> around the pom.xml files, I think I only need to select
>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
>> boilerplate-minimal, tomcat and tomcat-deployer.
>>
>> To improve the usability, I suggest the following:
>>
>>> From the assemble server portlet, a user can choose what type of
>>
>> customer assembly he/she wants to build:
>>
>> - Functional custom assembly
>> - Application scope custom assembly
>> - Advanced configuration
>>
>> Selecting "Function custom assembly" will lead to selection of key
>> functions of the server, and we can use the category of plugins to
>> associate functions and plugins. Instead of displaying all the
>> plugins, we group the plugins by their function(category) and display
>> the function only. I think it would be nice to see some explanation
>> of each function. For example:
>> - Geronimo Core - plugins that provide the core service of the
>> geronimo server...
>> - Web Services - plugins that provides the web service stack of the
>> geronimo server...
>> - Deployment - plugins that enables you to deploy apps onto the server...
>> ...
>>
>> If desired, users have the option to see what plugins are associated
>> with a function, such as Geronimo Core. Also, if we want to provide
>> detailed functions, we can update the category to be more accurate,
>> such as Deployment: Offline Deployment, Deployment : Command Line
>> Deployer, Deployment: Hot Deploy, etc.
>>
>> Selecting "Application scope custom assembly" will lead to selection
>> of custom applications deployed to the server. We can also warn our
>> users that the custom server may not be able to deploy anything.
>>
>> Selecting "Advanced configuration" will lead to the current assemble
>> server page that allows a user to select plugins from all the plugins
>> in local server. This assumes the user knows the plugins in local
>> server well.
>>
>> For all options, we should always display the pre-selected
>> boilerplate-minimal.
>>
>> Comments are welcome! If there is no objection, I'll start working on
>> this.
>>
>> Lin
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Thanks for the valuable feedback.
So basically, you are proposing to consolidate 3 options to 2 options
and provide the advanced configuration option at the end of either
option. I think it will still be useful to keep the advanced
configuration option by itself for advanced users who knows exactly
which plugins they want. This option can produce a custom server
that is not producible from other two options.
Here is what I understand of application centric custom assembly. I
think the purpose is that the user deploys the application onto the
server and the user is satisfied with everything, then he builds a
customer server out of it. He wants to keep the assembly as small as
possible with his application running, and it is not important to the
user if he could deploy any other projects to the server. In this
case, I think it is better not to present the advanced configuration
option as it can confuse users, but it would be fine for me to provide
that if you guys disagree.
The profile concept you proposed is like a group of functions. I
think I'd rather let users to select functions instead of providing
profiles to keep things simple, as we may not be able to suggest the
right profiles for users and some users may end up not seeing a set of
functions he desires to see in the list of profiles.
For functional based assembly, I like what you proposed of providing
an advanced configuration at the end to add additional system modules
or application modules if desired.
Create a local server instance is interesting... something I haven't
thought of so far. It can certainly be considered after the above
items.
Lin
On Mon, Aug 11, 2008 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
> Yep, the current custom assembly portlet needs some love...
>
> I agree that there are three usage scenarios, but thinking that we could
> handle all with the same portlet. We don't want users to start down an
> "application" path only to find out that they can't add additional modules
> (like the deployers, monitoring, ...) and have to start over and use the
> advanced path.
>
> Maybe we can create a set of views that are displayed or hidden, based on
> how the user starts, like
> 1) "Create a server assembly based on a deployed application"
> - prompts user to choose from deployed application(s) (but hides system
> modules)
> - presents user with an "advanced options" link, to add other system
> modules
> 2) "Create a server assembly based on a profile"
> - prompts user to choose from a predetermined list of profiles
> - Web (our minimal assembly today)
> - Web + JMS
> - Web + EJB
> - Web + ....
> - presents user with an option to "add deployed application(s)"
> - presents user with an "advanced options" link, to add other system
> modules
>
> Also, would be nice to give the option to create a local server instance
> (sharing the same repo), along with the existing zip/tar option....
>
>
> -Donald
>
>
>
> Lin Sun wrote:
>>
>> Hi,
>>
>> I'd like to enhance the assemble server portlet's usability.
>> Currently it is hard to come up with a desired custom server assembly.
>>
>> For example, I want to create a custom server that provides similar
>> function as tomcat. To do this, I picked the boilerplate-minimal,
>> tomcat and tomcat-deployer to build my custom server. However, soon I
>> found out that I am not able to deploy anything to the server, as I
>> didn't select any plugins to enable command deployer or hot deployer
>> or console deployer or gshell deployment. So I went back to the
>> assemble server portlet and I saw so many plugins related to
>> deployment, by looking at the plugins under the Deployment category-
>>
>> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
>> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
>> org.apache.geronimo.framework/offline-deployer/2.1.2/car
>> org.apache.geronimo.framework/online-deployer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>>
>> Which one do I pick? I don't want to select any extra ones... I just
>> want to enable command line deployer for war modules. By poking
>> around the pom.xml files, I think I only need to select
>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
>> boilerplate-minimal, tomcat and tomcat-deployer.
>>
>> To improve the usability, I suggest the following:
>>
>>> From the assemble server portlet, a user can choose what type of
>>
>> customer assembly he/she wants to build:
>>
>> - Functional custom assembly
>> - Application scope custom assembly
>> - Advanced configuration
>>
>> Selecting "Function custom assembly" will lead to selection of key
>> functions of the server, and we can use the category of plugins to
>> associate functions and plugins. Instead of displaying all the
>> plugins, we group the plugins by their function(category) and display
>> the function only. I think it would be nice to see some explanation
>> of each function. For example:
>> - Geronimo Core - plugins that provide the core service of the
>> geronimo server...
>> - Web Services - plugins that provides the web service stack of the
>> geronimo server...
>> - Deployment - plugins that enables you to deploy apps onto the server...
>> ...
>>
>> If desired, users have the option to see what plugins are associated
>> with a function, such as Geronimo Core. Also, if we want to provide
>> detailed functions, we can update the category to be more accurate,
>> such as Deployment: Offline Deployment, Deployment : Command Line
>> Deployer, Deployment: Hot Deploy, etc.
>>
>> Selecting "Application scope custom assembly" will lead to selection
>> of custom applications deployed to the server. We can also warn our
>> users that the custom server may not be able to deploy anything.
>>
>> Selecting "Advanced configuration" will lead to the current assemble
>> server page that allows a user to select plugins from all the plugins
>> in local server. This assumes the user knows the plugins in local
>> server well.
>>
>> For all options, we should always display the pre-selected
>> boilerplate-minimal.
>>
>> Comments are welcome! If there is no objection, I'll start working on
>> this.
>>
>> Lin
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Lin Sun <li...@gmail.com>.
Thanks for the valuable feedback.
So basically, you are proposing to consolidate 3 options to 2 options
and provide the advanced configuration option at the end of either
option. I think it will still be useful to keep the advanced
configuration option by itself for advanced users who knows exactly
which plugins they want. This option can produce a custom server
that is not producible from other two options.
Here is what I understand of application centric custom assembly. I
think the purpose is that the user deploys the application onto the
server and the user is satisfied with everything, then he builds a
customer server out of it. He wants to keep the assembly as small as
possible with his application running, and it is not important to the
user if he could deploy any other projects to the server. In this
case, I think it is better not to present the advanced configuration
option as it can confuse users, but it would be fine for me to provide
that if you guys disagree.
The profile concept you proposed is like a group of functions. I
think I'd rather let users to select functions instead of providing
profiles to keep things simple, as we may not be able to suggest the
right profiles for users and some users may end up not seeing a set of
functions he desires to see in the list of profiles.
For functional based assembly, I like what you proposed of providing
an advanced configuration at the end to add additional system modules
or application modules if desired.
Create a local server instance is interesting... something I haven't
thought of so far. It can certainly be considered after the above
items.
Lin
On Mon, Aug 11, 2008 at 1:50 PM, Donald Woods <dw...@apache.org> wrote:
> Yep, the current custom assembly portlet needs some love...
>
> I agree that there are three usage scenarios, but thinking that we could
> handle all with the same portlet. We don't want users to start down an
> "application" path only to find out that they can't add additional modules
> (like the deployers, monitoring, ...) and have to start over and use the
> advanced path.
>
> Maybe we can create a set of views that are displayed or hidden, based on
> how the user starts, like
> 1) "Create a server assembly based on a deployed application"
> - prompts user to choose from deployed application(s) (but hides system
> modules)
> - presents user with an "advanced options" link, to add other system
> modules
> 2) "Create a server assembly based on a profile"
> - prompts user to choose from a predetermined list of profiles
> - Web (our minimal assembly today)
> - Web + JMS
> - Web + EJB
> - Web + ....
> - presents user with an option to "add deployed application(s)"
> - presents user with an "advanced options" link, to add other system
> modules
>
> Also, would be nice to give the option to create a local server instance
> (sharing the same repo), along with the existing zip/tar option....
>
>
> -Donald
>
>
>
> Lin Sun wrote:
>>
>> Hi,
>>
>> I'd like to enhance the assemble server portlet's usability.
>> Currently it is hard to come up with a desired custom server assembly.
>>
>> For example, I want to create a custom server that provides similar
>> function as tomcat. To do this, I picked the boilerplate-minimal,
>> tomcat and tomcat-deployer to build my custom server. However, soon I
>> found out that I am not able to deploy anything to the server, as I
>> didn't select any plugins to enable command deployer or hot deployer
>> or console deployer or gshell deployment. So I went back to the
>> assemble server portlet and I saw so many plugins related to
>> deployment, by looking at the plugins under the Deployment category-
>>
>> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
>> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
>> org.apache.geronimo.framework/offline-deployer/2.1.2/car
>> org.apache.geronimo.framework/online-deployer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
>> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>>
>> Which one do I pick? I don't want to select any extra ones... I just
>> want to enable command line deployer for war modules. By poking
>> around the pom.xml files, I think I only need to select
>> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
>> boilerplate-minimal, tomcat and tomcat-deployer.
>>
>> To improve the usability, I suggest the following:
>>
>>> From the assemble server portlet, a user can choose what type of
>>
>> customer assembly he/she wants to build:
>>
>> - Functional custom assembly
>> - Application scope custom assembly
>> - Advanced configuration
>>
>> Selecting "Function custom assembly" will lead to selection of key
>> functions of the server, and we can use the category of plugins to
>> associate functions and plugins. Instead of displaying all the
>> plugins, we group the plugins by their function(category) and display
>> the function only. I think it would be nice to see some explanation
>> of each function. For example:
>> - Geronimo Core - plugins that provide the core service of the
>> geronimo server...
>> - Web Services - plugins that provides the web service stack of the
>> geronimo server...
>> - Deployment - plugins that enables you to deploy apps onto the server...
>> ...
>>
>> If desired, users have the option to see what plugins are associated
>> with a function, such as Geronimo Core. Also, if we want to provide
>> detailed functions, we can update the category to be more accurate,
>> such as Deployment: Offline Deployment, Deployment : Command Line
>> Deployer, Deployment: Hot Deploy, etc.
>>
>> Selecting "Application scope custom assembly" will lead to selection
>> of custom applications deployed to the server. We can also warn our
>> users that the custom server may not be able to deploy anything.
>>
>> Selecting "Advanced configuration" will lead to the current assemble
>> server page that allows a user to select plugins from all the plugins
>> in local server. This assumes the user knows the plugins in local
>> server well.
>>
>> For all options, we should always display the pre-selected
>> boilerplate-minimal.
>>
>> Comments are welcome! If there is no objection, I'll start working on
>> this.
>>
>> Lin
>>
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
Yep, the current custom assembly portlet needs some love...
I agree that there are three usage scenarios, but thinking that we could
handle all with the same portlet. We don't want users to start down an
"application" path only to find out that they can't add additional
modules (like the deployers, monitoring, ...) and have to start over and
use the advanced path.
Maybe we can create a set of views that are displayed or hidden, based
on how the user starts, like
1) "Create a server assembly based on a deployed application"
- prompts user to choose from deployed application(s) (but hides
system modules)
- presents user with an "advanced options" link, to add other
system modules
2) "Create a server assembly based on a profile"
- prompts user to choose from a predetermined list of profiles
- Web (our minimal assembly today)
- Web + JMS
- Web + EJB
- Web + ....
- presents user with an option to "add deployed application(s)"
- presents user with an "advanced options" link, to add other
system modules
Also, would be nice to give the option to create a local server instance
(sharing the same repo), along with the existing zip/tar option....
-Donald
Lin Sun wrote:
> Hi,
>
> I'd like to enhance the assemble server portlet's usability.
> Currently it is hard to come up with a desired custom server assembly.
>
> For example, I want to create a custom server that provides similar
> function as tomcat. To do this, I picked the boilerplate-minimal,
> tomcat and tomcat-deployer to build my custom server. However, soon I
> found out that I am not able to deploy anything to the server, as I
> didn't select any plugins to enable command deployer or hot deployer
> or console deployer or gshell deployment. So I went back to the
> assemble server portlet and I saw so many plugins related to
> deployment, by looking at the plugins under the Deployment category-
>
> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
> org.apache.geronimo.framework/offline-deployer/2.1.2/car
> org.apache.geronimo.framework/online-deployer/2.1.2/car
> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>
> Which one do I pick? I don't want to select any extra ones... I just
> want to enable command line deployer for war modules. By poking
> around the pom.xml files, I think I only need to select
> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
> boilerplate-minimal, tomcat and tomcat-deployer.
>
> To improve the usability, I suggest the following:
>
>>>From the assemble server portlet, a user can choose what type of
> customer assembly he/she wants to build:
>
> - Functional custom assembly
> - Application scope custom assembly
> - Advanced configuration
>
> Selecting "Function custom assembly" will lead to selection of key
> functions of the server, and we can use the category of plugins to
> associate functions and plugins. Instead of displaying all the
> plugins, we group the plugins by their function(category) and display
> the function only. I think it would be nice to see some explanation
> of each function. For example:
> - Geronimo Core - plugins that provide the core service of the
> geronimo server...
> - Web Services - plugins that provides the web service stack of the
> geronimo server...
> - Deployment - plugins that enables you to deploy apps onto the server...
> ...
>
> If desired, users have the option to see what plugins are associated
> with a function, such as Geronimo Core. Also, if we want to provide
> detailed functions, we can update the category to be more accurate,
> such as Deployment: Offline Deployment, Deployment : Command Line
> Deployer, Deployment: Hot Deploy, etc.
>
> Selecting "Application scope custom assembly" will lead to selection
> of custom applications deployed to the server. We can also warn our
> users that the custom server may not be able to deploy anything.
>
> Selecting "Advanced configuration" will lead to the current assemble
> server page that allows a user to select plugins from all the plugins
> in local server. This assumes the user knows the plugins in local
> server well.
>
> For all options, we should always display the pre-selected
> boilerplate-minimal.
>
> Comments are welcome! If there is no objection, I'll start working on this.
>
> Lin
>
Re: [DISCUSS] enhance the assemble server portlet usability
Posted by Donald Woods <dw...@apache.org>.
Lin, any thoughts on how we can automate testing of these new
profileplugins?
I saw you just converted the minimal assemblies over to use the web
profiles. Should we create a testsuite to verify that all of the other
platforms that we want to support (like Web + Axis2) can be generated
during the builds?
Should we also deploy some of the Sample apps against each to verify the
runtime works?
-Donald
Lin Sun wrote:
> Hi,
>
> I'd like to enhance the assemble server portlet's usability.
> Currently it is hard to come up with a desired custom server assembly.
>
> For example, I want to create a custom server that provides similar
> function as tomcat. To do this, I picked the boilerplate-minimal,
> tomcat and tomcat-deployer to build my custom server. However, soon I
> found out that I am not able to deploy anything to the server, as I
> didn't select any plugins to enable command deployer or hot deployer
> or console deployer or gshell deployment. So I went back to the
> assemble server portlet and I saw so many plugins related to
> deployment, by looking at the plugins under the Deployment category-
>
> org.apache.geronimo.framework/upgrade-cli/2.1.2/car
> org.apache.geronimo.framework/jsr88-cli/2.1.2/car
> org.apache.geronimo.framework/jsr88-deploymentfactory/2.1.2/car
> org.apache.geronimo.framework/offline-deployer/2.1.2/car
> org.apache.geronimo.framework/online-deployer/2.1.2/car
> org.apache.geronimo.configs/jsr88-ear-configurer/2.1.2/car
> org.apache.geronimo.configs/jsr88-jar-configurer/2.1.2/car
> org.apache.geronimo.configs/jsr88-rar-configurer/2.1.2/car
> org.apache.geronimo.configs/jsr88-war-configurer/2.1.2/car
>
> Which one do I pick? I don't want to select any extra ones... I just
> want to enable command line deployer for war modules. By poking
> around the pom.xml files, I think I only need to select
> org.apache.geronimo.framework/jsr88-cli/2.1.2/car in addition to
> boilerplate-minimal, tomcat and tomcat-deployer.
>
> To improve the usability, I suggest the following:
>
>>>From the assemble server portlet, a user can choose what type of
> customer assembly he/she wants to build:
>
> - Functional custom assembly
> - Application scope custom assembly
> - Advanced configuration
>
> Selecting "Function custom assembly" will lead to selection of key
> functions of the server, and we can use the category of plugins to
> associate functions and plugins. Instead of displaying all the
> plugins, we group the plugins by their function(category) and display
> the function only. I think it would be nice to see some explanation
> of each function. For example:
> - Geronimo Core - plugins that provide the core service of the
> geronimo server...
> - Web Services - plugins that provides the web service stack of the
> geronimo server...
> - Deployment - plugins that enables you to deploy apps onto the server...
> ...
>
> If desired, users have the option to see what plugins are associated
> with a function, such as Geronimo Core. Also, if we want to provide
> detailed functions, we can update the category to be more accurate,
> such as Deployment: Offline Deployment, Deployment : Command Line
> Deployer, Deployment: Hot Deploy, etc.
>
> Selecting "Application scope custom assembly" will lead to selection
> of custom applications deployed to the server. We can also warn our
> users that the custom server may not be able to deploy anything.
>
> Selecting "Advanced configuration" will lead to the current assemble
> server page that allows a user to select plugins from all the plugins
> in local server. This assumes the user knows the plugins in local
> server well.
>
> For all options, we should always display the pre-selected
> boilerplate-minimal.
>
> Comments are welcome! If there is no objection, I'll start working on this.
>
> Lin
>