geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <dwo...@apache.org>
Subject Re: [DISCUSS] enhance the assemble server portlet usability
Date Tue, 12 Aug 2008 12:56:44 GMT
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 <dwoods@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
>>>
> 

Mime
View raw message