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