Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 13761 invoked from network); 25 Aug 2008 22:02:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Aug 2008 22:02:19 -0000 Received: (qmail 90625 invoked by uid 500); 25 Aug 2008 22:02:17 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 90572 invoked by uid 500); 25 Aug 2008 22:02:16 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 90561 invoked by uid 99); 25 Aug 2008 22:02:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Aug 2008 15:02:16 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.136.44.59] (HELO smtp104.prem.mail.sp1.yahoo.com) (98.136.44.59) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 25 Aug 2008 22:01:19 +0000 Received: (qmail 53342 invoked from network); 25 Aug 2008 22:00:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer; b=e4LSZDim3jSd4gVblq92CPR2iKJkSyTOzMssFsQIHuRUWr0CowCTvDXiVq3Ssuxx3x0i5xU7fLNWFG48Jz+aHdGtoAEsRn0Ft+pbwAOPa0CSnbs35eXx6gj9pxMc4eGPaQ8f4X70FEwanWNdqtlwUfUqNn8QhRATrrLSLjP6PDs= ; Received: from unknown (HELO ?192.168.1.104?) (david_jencks@76.105.175.1 with plain) by smtp104.prem.mail.sp1.yahoo.com with SMTP; 25 Aug 2008 22:00:47 -0000 X-YMail-OSG: 6lkvBIMVM1lSq.LNc3ETOUtchIpDDbZ7_41W05J5xVgpfltKs1m3PzTB7VdTsZXf5RLQl2MWSLJstTj0ZgVxU8Si5VJZovTuC6wUu60nfv9_EK8g8irXJEnbrkbI4OZUZHTDvSHQj2kFarU9HR2nWRkv X-Yahoo-Newman-Property: ymail-3 Message-Id: <12CE44D6-AB34-4B72-B6F7-FF20E53A645E@yahoo.com> From: David Jencks To: dev@geronimo.apache.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Subject: Re: [DISCUSS] enhance the assemble server portlet usability Date: Mon, 25 Aug 2008 15:00:46 -0700 References: <6B935242-7A76-4BCD-AB9C-4334F45A4E76@yahoo.com> <48A982EF.4000701@earthlink.net> <5e7fd1eb0808182017x366fe17ew7eec4c0192cf1f50@mail.gmail.com> <5eb405c70808212057w506eefc1o576ecf95f1944214@mail.gmail.com> <48B30426.2030609@gmail.com> X-Mailer: Apple Mail (2.926) X-Virus-Checked: Checked by ClamAV on apache.org 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 > 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: >> >> > >> 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 >>> 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 >>>> 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 - >>>>> >>>>> >>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"> >>>>> Geronimo Assemblies :: Minimal + Tomcat >>>>> WEB Profile >>>>> true >>>>> A minimal Geronimo server (Little-G) assembly using >>>>> the Tomcat web-container. >>>>> http://www.apache.org/ >>>>> Apache Software Foundation >>>>> The Apache Software License, >>>>> Version >>>>> 2.0 >>>>> >>>>> >>>>> org.apache.geronimo.assemblies >>>>> geronimo-tomcat6-minimal >>>>> 2.2-SNAPSHOT >>>>> car >>>>> >>>>> 2.2-SNAPSHOT >>>>> 1.5 >>>>> 1.6 >>>>> >>>>> >>>>> org.apache.geronimo.assemblies >>>>> geronimo-boilderplate-minimal >>>>> 2.2-SNAPSHOT >>>>> jar >>>>> >>>>> >>>>> >>>>> org.apache.geronimo.framework >>>>> upgrade-cli >>>>> 2.2-SNAPSHOT >>>>> car >>>>> >>>>> >>>>> >>>>> org.apache.geronimo.framework >>>>> rmi-naming >>>>> 2.2-SNAPSHOT >>>>> car >>>>> >>>>> >>>>> >>>>> org.apache.geronimo.framework >>>>> j2ee-security >>>>> 2.2-SNAPSHOT >>>>> car >>>>> >>>>> >>>>> >>>>> org.apache.geronimo.configs >>>>> tomcat6 >>>>> 2.2-SNAPSHOT >>>>> car >>>>> >>>>> ... >>>>> >>>>> 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 >>>>> >>