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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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
