Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 15071 invoked from network); 12 Aug 2008 01:37:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Aug 2008 01:37:46 -0000 Received: (qmail 7731 invoked by uid 500); 12 Aug 2008 01:37:43 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 7680 invoked by uid 500); 12 Aug 2008 01:37:43 -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 7669 invoked by uid 99); 12 Aug 2008 01:37:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Aug 2008 18:37:43 -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: domain of linsun.unc@gmail.com designates 74.125.44.29 as permitted sender) Received: from [74.125.44.29] (HELO yx-out-2324.google.com) (74.125.44.29) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Aug 2008 01:36:47 +0000 Received: by yx-out-2324.google.com with SMTP id 3so807594yxj.85 for ; Mon, 11 Aug 2008 18:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0jT/K5WTA108MrvofwF0X1me7u0oQPDadZbQNGtln+U=; b=QBeGR2kQdk13okv3Dxv2Y5dpPGalpaZpaUWeWCyEtMyBP2you5gTHk5ae7yXAte5rJ V5JrkigD+ZweI4RDjxhQRyI7O38VRcKilBwmnzpES2u3jF359W9OHU4tqrWgAJIqHBYI OGG70OxQ77dBnulrwhk1h/AOq8zjDCVvrw1rg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=stueK5J7pD9K/8gCWNfgQIDI5x+JTvNDGcBnvS4uP16Gy8xZ+9BkemWIm2XcOlMi3E Nq3Qwbsncge6oBzMVKKLr276Q9q2GTBf6XrPSXFBLbT9n/WR2Lr0vk2X3fMRi8gamm2M KvA/wdv1y4OPnIXLfa1KFcqUzssdiS5bE5X08= Received: by 10.151.12.4 with SMTP id p4mr13305955ybi.214.1218505034417; Mon, 11 Aug 2008 18:37:14 -0700 (PDT) Received: by 10.150.137.19 with HTTP; Mon, 11 Aug 2008 18:37:14 -0700 (PDT) Message-ID: Date: Mon, 11 Aug 2008 21:37:14 -0400 From: "Lin Sun" To: dev@geronimo.apache.org Subject: Re: [DISCUSS] enhance the assemble server portlet usability In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48A07BD5.7090904@apache.org> X-Virus-Checked: Checked by ClamAV on apache.org 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 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 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 >>> >> >