[DISCUSS] enhance the assemble server portlet usability

[Lin Sun-2]

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

[Donald Woods-2]

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
>

[Lin Sun-2]

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@...> 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
>>
>

[Lin Sun-2]

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@...> 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
>>
>

[Lin Sun-2]

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@...> 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
>>
>

[Lin Sun-2]

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 <linsun.unc@...> 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@...> 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
>>>
>>
>

[Donald Woods-2]

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@...> 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
>>>
>

[kevan]

On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:

> 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.

:-) I have had conversations where that was requested and seem to  
recall musing/wishing for this in the past...

Glad to see this discussion occurring.

I like the concept of profiles.

My one comment, at the moment, is the discussion may be too focused on  
the admin console. I'd like to be sure we also include command-based  
scenarios as well (and even maven?). IMO, we should permit the same  
basic abstractions (at least for the command-based scenario).

--kevan

[Lin Sun-2]

Thanks again for the valuable feedback - Donald and Kevan!

If profile is what people are interested in, we need to identify what
profiles we want to provide and the plugins that each profile
contains.   We also want to think what type(s) of deployment we want
to provide with these profiles.   Do we always provide the command
line deployment with the profiles, or hot deployment, or console
deployment or gshell deployment, or we always provide all the
deployment options for each of the profile?  I am sure there are other
options/variables.

Here are some possible profiles -

 - Web (our minimal assembly today)
 - Web + JMS
 - Web + EJB
 - Web + Web Services
 - Web + EJB + Persistence
 - Web + Admin Console
 - Web + JMS + Admin Console
 - Web + EJB + Admin Console
 - Web + JSF
 - Web + Clustering
...

I think it could be too much combinations than we can handle, unless
we can identify the exact profiles that users will likely want.

If we allow users to pick profiles, it is nice we provide users with
profiles that we can test and verify first.  However, the user may end
up not seeing the function combination he desires.

If we allow users to pick functions (a function is a group of
plugins), the user will have the maximum flexibility and we can still
test the common combination of functions (which is same as profiles).

Lin





On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller <kevan.miller@...> wrote:

>
> On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
>
>> 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.
>
> :-) I have had conversations where that was requested and seem to recall
> musing/wishing for this in the past...
>
> Glad to see this discussion occurring.
>
> I like the concept of profiles.
>
> My one comment, at the moment, is the discussion may be too focused on the
> admin console. I'd like to be sure we also include command-based scenarios
> as well (and even maven?). IMO, we should permit the same basic abstractions
> (at least for the command-based scenario).
>
> --kevan
>
>

[Lin Sun-2]

Yes I agree that we should also improve the usability of the command
based scenarios.   Whatever we discussed and agreed here can be used
for the command based scenarios.

Lin

On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller <kevan.miller@...> wrote:

> My one comment, at the moment, is the discussion may be too focused on the
> admin console. I'd like to be sure we also include command-based scenarios
> as well (and even maven?). IMO, we should permit the same basic abstractions
> (at least for the command-based scenario).
>
> --kevan
>
>

[djencks]

On Aug 12, 2008, at 12:47 PM, Lin Sun wrote:

> Thanks again for the valuable feedback - Donald and Kevan!
>
> If profile is what people are interested in, we need to identify what
> profiles we want to provide and the plugins that each profile
> contains.   We also want to think what type(s) of deployment we want
> to provide with these profiles.   Do we always provide the command
> line deployment with the profiles, or hot deployment, or console
> deployment or gshell deployment, or we always provide all the
> deployment options for each of the profile?  I am sure there are other
> options/variables.
>
> Here are some possible profiles -
>
> - Web (our minimal assembly today)
> - Web + JMS
> - Web + EJB
> - Web + Web Services
> - Web + EJB + Persistence
> - Web + Admin Console
> - Web + JMS + Admin Console
> - Web + EJB + Admin Console
> - Web + JSF
> - Web + Clustering

client profiles might be apropriate too.

I wonder how much of this is actually necessary?  e.g. if you install  
the jetty-deployer plugin you get jetty too.  If you install the jetty-
console you get jetty....

What if we had a "select the parts" page that was organized  
differently than the list of plugins.... e.g. checkboxes for web, ejb,  
webservices.  If you say yes to web, you get to choose jetty/tomcat,  
whether you want deployment, whether you want the console.

Choosing web or ejb gives you the opportunity to include openjpa ( or  
maybe toplink in the future)
Choosing webservices gives you the choice of cxf or axis2


Just some more or less random thoughts
david jencks

>
> ...
>
> I think it could be too much combinations than we can handle, unless
> we can identify the exact profiles that users will likely want.
>
> If we allow users to pick profiles, it is nice we provide users with
> profiles that we can test and verify first.  However, the user may end
> up not seeing the function combination he desires.
>
> If we allow users to pick functions (a function is a group of
> plugins), the user will have the maximum flexibility and we can still
> test the common combination of functions (which is same as profiles).
>
> Lin
>
>
>
>
>
> On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller  
> <kevan.miller@...> wrote:
>>
>> On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
>>
>>> 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.
>>
>> :-) I have had conversations where that was requested and seem to  
>> recall
>> musing/wishing for this in the past...
>>
>> Glad to see this discussion occurring.
>>
>> I like the concept of profiles.
>>
>> My one comment, at the moment, is the discussion may be too focused  
>> on the
>> admin console. I'd like to be sure we also include command-based  
>> scenarios
>> as well (and even maven?). IMO, we should permit the same basic  
>> abstractions
>> (at least for the command-based scenario).
>>
>> --kevan
>>
>>

[Donald Woods-2]

Sounds like a good approach.

-Donald


David Jencks wrote:

>
> On Aug 12, 2008, at 12:47 PM, Lin Sun wrote:
>
>> Thanks again for the valuable feedback - Donald and Kevan!
>>
>> If profile is what people are interested in, we need to identify what
>> profiles we want to provide and the plugins that each profile
>> contains.   We also want to think what type(s) of deployment we want
>> to provide with these profiles.   Do we always provide the command
>> line deployment with the profiles, or hot deployment, or console
>> deployment or gshell deployment, or we always provide all the
>> deployment options for each of the profile?  I am sure there are other
>> options/variables.
>>
>> Here are some possible profiles -
>>
>> - Web (our minimal assembly today)
>> - Web + JMS
>> - Web + EJB
>> - Web + Web Services
>> - Web + EJB + Persistence
>> - Web + Admin Console
>> - Web + JMS + Admin Console
>> - Web + EJB + Admin Console
>> - Web + JSF
>> - Web + Clustering
>
> client profiles might be apropriate too.
>
> I wonder how much of this is actually necessary?  e.g. if you install
> the jetty-deployer plugin you get jetty too.  If you install the
> jetty-console you get jetty....
>
> What if we had a "select the parts" page that was organized differently
> than the list of plugins.... e.g. checkboxes for web, ejb, webservices.  
> If you say yes to web, you get to choose jetty/tomcat, whether you want
> deployment, whether you want the console.
>
> Choosing web or ejb gives you the opportunity to include openjpa ( or
> maybe toplink in the future)
> Choosing webservices gives you the choice of cxf or axis2
>
>
> Just some more or less random thoughts
> david jencks
>
>>
>> ...
>>
>> I think it could be too much combinations than we can handle, unless
>> we can identify the exact profiles that users will likely want.
>>
>> If we allow users to pick profiles, it is nice we provide users with
>> profiles that we can test and verify first.  However, the user may end
>> up not seeing the function combination he desires.
>>
>> If we allow users to pick functions (a function is a group of
>> plugins), the user will have the maximum flexibility and we can still
>> test the common combination of functions (which is same as profiles).
>>
>> Lin
>>
>>
>>
>>
>>
>> On Tue, Aug 12, 2008 at 2:01 PM, Kevan Miller <kevan.miller@...>
>> wrote:
>>>
>>> On Aug 12, 2008, at 8:56 AM, Donald Woods wrote:
>>>
>>>> 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.
>>>
>>> :-) I have had conversations where that was requested and seem to recall
>>> musing/wishing for this in the past...
>>>
>>> Glad to see this discussion occurring.
>>>
>>> I like the concept of profiles.
>>>
>>> My one comment, at the moment, is the discussion may be too focused
>>> on the
>>> admin console. I'd like to be sure we also include command-based
>>> scenarios
>>> as well (and even maven?). IMO, we should permit the same basic
>>> abstractions
>>> (at least for the command-based scenario).
>>>
>>> --kevan
>>>
>>>
>
>

[Lin Sun-2]

I appreciate your valuable feedback!

Currently, a user doesn't have that much choices, as we only allow the
user to assemble a new server out of plugins in local server, unless
we want to change this behavior.

So if a user installs the geronimo-tomcat-javaee5 assembly, he can
only choose tomcat + axis2.   If a user installs the
geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.

To simplify things, here is what I suggest.  We allow the users to choose from -

__ Web
__ JMS
__ Web Services
__ EJB
__ OpenJPA
__ Deployment
__ Admin Console
__ Cluster (tomcat only?)

Then the user can just select one or more functions they need and
request for the customer assembly server to be created.   Optionally,
the user can add on additional deployed apps or other system modules
then request for the customer assembly server to be created.

Lin

On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <david_jencks@...> wrote:

>
> client profiles might be apropriate too.
>
> I wonder how much of this is actually necessary?  e.g. if you install the
> jetty-deployer plugin you get jetty too.  If you install the jetty-console
> you get jetty....
>
> What if we had a "select the parts" page that was organized differently than
> the list of plugins.... e.g. checkboxes for web, ejb, webservices.  If you
> say yes to web, you get to choose jetty/tomcat, whether you want deployment,
> whether you want the console.
>
> Choosing web or ejb gives you the opportunity to include openjpa ( or maybe
> toplink in the future)
> Choosing webservices gives you the choice of cxf or axis2
>
>
> Just some more or less random thoughts
> david jencks
>

[djencks]

On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:

> I appreciate your valuable feedback!
>
> Currently, a user doesn't have that much choices, as we only allow the
> user to assemble a new server out of plugins in local server, unless
> we want to change this behavior.
>
> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
> only choose tomcat + axis2.   If a user installs the
> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.

true... for now :-)
>
>
> To simplify things, here is what I suggest.  We allow the users to  
> choose from -
>
> __ Web
__jsp
>
> __ JMS
> __ Web Services
> __ EJB
> __ OpenJPA
> __ Deployment
> __ Admin Console
> __ Cluster (tomcat only?)
__wadi clustering
>
>
> Then the user can just select one or more functions they need and
> request for the customer assembly server to be created.   Optionally,
> the user can add on additional deployed apps or other system modules
> then request for the customer assembly server to be created.

I wonder if we can think bigger :-)

What if we distributed something with _all_ the cars in it and  
customizable profiles for the servers we ship now?  So, you wouldn't  
unpack a particular server, but the server construction kit.  You  
could pick a profile and optionally modify it, then spit out the  
desired server.  Then you would be able to pick jetty/tomcat and cxf/
axis2 and however much deployment you wanted.

Alternatively maybe the "assemble a server" can show plugins from more  
than just the current server.

thanks
david jencks

>
>
> Lin
>
> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks  
> <david_jencks@...> wrote:
>>
>> client profiles might be apropriate too.
>>
>> I wonder how much of this is actually necessary?  e.g. if you  
>> install the
>> jetty-deployer plugin you get jetty too.  If you install the jetty-
>> console
>> you get jetty....
>>
>> What if we had a "select the parts" page that was organized  
>> differently than
>> the list of plugins.... e.g. checkboxes for web, ejb, webservices.  
>> If you
>> say yes to web, you get to choose jetty/tomcat, whether you want  
>> deployment,
>> whether you want the console.
>>
>> Choosing web or ejb gives you the opportunity to include openjpa  
>> ( or maybe
>> toplink in the future)
>> Choosing webservices gives you the choice of cxf or axis2
>>
>>
>> Just some more or less random thoughts
>> david jencks
>>

[kevan]

On Aug 12, 2008, at 6:11 PM, David Jencks wrote:

>
> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>
>> I appreciate your valuable feedback!
>>
>> Currently, a user doesn't have that much choices, as we only allow  
>> the
>> user to assemble a new server out of plugins in local server, unless
>> we want to change this behavior.
>>
>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>> only choose tomcat + axis2.   If a user installs the
>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>
> true... for now :-)
>>
>>
>> To simplify things, here is what I suggest.  We allow the users to  
>> choose from -
>>
>> __ Web
> __jsp
>>
>> __ JMS
>> __ Web Services
>> __ EJB
>> __ OpenJPA
>> __ Deployment
>> __ Admin Console
>> __ Cluster (tomcat only?)
> __wadi clustering
>>
>>
>> Then the user can just select one or more functions they need and
>> request for the customer assembly server to be created.   Optionally,
>> the user can add on additional deployed apps or other system modules
>> then request for the customer assembly server to be created.
>
> I wonder if we can think bigger :-)
>
> What if we distributed something with _all_ the cars in it and  
> customizable profiles for the servers we ship now?  So, you wouldn't  
> unpack a particular server, but the server construction kit.  You  
> could pick a profile and optionally modify it, then spit out the  
> desired server.  Then you would be able to pick jetty/tomcat and cxf/
> axis2 and however much deployment you wanted.
>
> Alternatively maybe the "assemble a server" can show plugins from  
> more than just the current server.

Sounds similar (same?) to something I've been thinking of... I was  
thinking we could include multiple config.xml files. These files could  
be specified when starting a server. E.g.:

./gsh geronimo/start-server -c jee-config.xml
./gsh geronimo/start-server -c minimal-config.xml
./gsh geronimo/start-server -c joes-custom-config.xml

If server footprint is a concern, you can still create custom  
assemblies based on these "profiles".

I'm not sure we'd want to include *all* cars and include a wide  
variety of possible config files. We certainly could, but I might  
stick with current tomcat/axis2 and jetty/cxf specific variants and  
maintain a "server" focus, rather than a "server construction" focus.  
I also don't think that such a capability would necessarily replace  
the function that Lin is proposing.

--kevan

[Lin Sun-2]

Thanks for updating the key function list.

Your big idea is very interesting... Also, It is possible we just
distribute the server construction kit, and a user could just select
profiles/plugins from a remote repo to assemble a desired custom
server.    I wonder if we could revisit this post 2.2, or after we
finish the usability improvement of the custom assembly.

Lin

On Tue, Aug 12, 2008 at 6:11 PM, David Jencks <david_jencks@...> wrote:

>
> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>
>> I appreciate your valuable feedback!
>>
>> Currently, a user doesn't have that much choices, as we only allow the
>> user to assemble a new server out of plugins in local server, unless
>> we want to change this behavior.
>>
>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>> only choose tomcat + axis2.   If a user installs the
>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>
> true... for now :-)
>>
>>
>> To simplify things, here is what I suggest.  We allow the users to choose
>> from -
>>
>> __ Web
>
> __jsp
>>
>> __ JMS
>> __ Web Services
>> __ EJB
>> __ OpenJPA
>> __ Deployment
>> __ Admin Console
>> __ Cluster (tomcat only?)
>
> __wadi clustering
>>
>>
>> Then the user can just select one or more functions they need and
>> request for the customer assembly server to be created.   Optionally,
>> the user can add on additional deployed apps or other system modules
>> then request for the customer assembly server to be created.
>
> I wonder if we can think bigger :-)
>
> What if we distributed something with _all_ the cars in it and customizable
> profiles for the servers we ship now?  So, you wouldn't unpack a particular
> server, but the server construction kit.  You could pick a profile and
> optionally modify it, then spit out the desired server.  Then you would be
> able to pick jetty/tomcat and cxf/axis2 and however much deployment you
> wanted.
>
> Alternatively maybe the "assemble a server" can show plugins from more than
> just the current server.
>
> thanks
> david jencks
>
>
>
>>
>>
>> Lin
>>
>> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <david_jencks@...>
>> wrote:
>>>
>>> client profiles might be apropriate too.
>>>
>>> I wonder how much of this is actually necessary?  e.g. if you install the
>>> jetty-deployer plugin you get jetty too.  If you install the
>>> jetty-console
>>> you get jetty....
>>>
>>> What if we had a "select the parts" page that was organized differently
>>> than
>>> the list of plugins.... e.g. checkboxes for web, ejb, webservices.  If
>>> you
>>> say yes to web, you get to choose jetty/tomcat, whether you want
>>> deployment,
>>> whether you want the console.
>>>
>>> Choosing web or ejb gives you the opportunity to include openjpa ( or
>>> maybe
>>> toplink in the future)
>>> Choosing webservices gives you the choice of cxf or axis2
>>>
>>>
>>> Just some more or less random thoughts
>>> david jencks
>>>
>
>

[Lin Sun-2]

I think footprint could be a concern for users in developing
countries.   A user may only want to download what he needs.

I also agree such capability doesn't overlap what I am proposing, as a
user could still want to build custom assembly server out of his
current server.

Lin

> Sounds similar (same?) to something I've been thinking of... I was thinking
> we could include multiple config.xml files. These files could be specified
> when starting a server. E.g.:
>
> ./gsh geronimo/start-server -c jee-config.xml
> ./gsh geronimo/start-server -c minimal-config.xml
> ./gsh geronimo/start-server -c joes-custom-config.xml
>
> If server footprint is a concern, you can still create custom assemblies
> based on these "profiles".
>
> I'm not sure we'd want to include *all* cars and include a wide variety of
> possible config files. We certainly could, but I might stick with current
> tomcat/axis2 and jetty/cxf specific variants and maintain a "server" focus,
> rather than a "server construction" focus. I also don't think that such a
> capability would necessarily replace the function that Lin is proposing.
>
> --kevan
>
>

[Jack Cai]

Thanks Lin for bringing this up! This is a very valuable improvement to make the custom server assembly feature truly usable.

I really like the idea of grouping functions and describing them in a language that is understandable to users. I think we can organize them in a hierachy, similar to the way how we select features to install during a desktop application installation. Grabbed a random snapshot here: http://www.tenouk.com/clabworksheet/windowspsdk_files/windowssdkpsdk008.png

As to the proposed list, I would suggest the following changes/additions
* Break down Web further into JSP+Servlet and JSF
* Change OpenJPA to JPA. I guess user does not have to care about whether it's OpenJPA or whatever else.
* Add JTA, JavaMail. Suppose Security is by default included...

Last but not least, if a user uses the custom server assembly function in a customized server (say, without JPA), will we allow the user to select JPA?

- Jack

[Rex Wang-2]

So, I think it is not necessary to limit that
" if a user installs the geronimo-tomcat-javaee5 assembly, he can
only choose tomcat + axis2.   If a user installs the
geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf."

We can list all the function here, and user also can choose them all,
If the plugin does not stay in current server, then before the assembling process,
a page show a list of the missing plugins and tell that it will download them from the repo on internet to complete the assembly, and also will provide an estimated cost of time for user.

Make sense?

Rex.

2008/8/13 Jack <greensight@...>

Thanks Lin for bringing this up! This is a very valuable improvement to make the custom server assembly feature truly usable.

I really like the idea of grouping functions and describing them in a language that is understandable to users. I think we can organize them in a hierachy, similar to the way how we select features to install during a desktop application installation. Grabbed a random snapshot here: http://www.tenouk.com/clabworksheet/windowspsdk_files/windowssdkpsdk008.png

As to the proposed list, I would suggest the following changes/additions
* Break down Web further into JSP+Servlet and JSF
* Change OpenJPA to JPA. I guess user does not have to care about whether it's OpenJPA or whatever else.
* Add JTA, JavaMail. Suppose Security is by default included...

Last but not least, if a user uses the custom server assembly function in a customized server (say, without JPA), will we allow the user to select JPA?

- Jack

[Donald Woods-2]

David Jencks wrote:

>
> On Aug 12, 2008, at 2:59 PM, Lin Sun wrote:
>
>> I appreciate your valuable feedback!
>>
>> Currently, a user doesn't have that much choices, as we only allow the
>> user to assemble a new server out of plugins in local server, unless
>> we want to change this behavior.
>>
>> So if a user installs the geronimo-tomcat-javaee5 assembly, he can
>> only choose tomcat + axis2.   If a user installs the
>> geronimo-jetty-javaee5 assembly, he can only choose jetty + cxf.
>
> true... for now :-)
>>
>>
>> To simplify things, here is what I suggest.  We allow the users to
>> choose from -
>>
>> __ Web
> __jsp
>>
>> __ JMS
>> __ Web Services
>> __ EJB
>> __ OpenJPA
>> __ Deployment
>> __ Admin Console
>> __ Cluster (tomcat only?)
> __wadi clustering
>>
>>
>> Then the user can just select one or more functions they need and
>> request for the customer assembly server to be created.   Optionally,
>> the user can add on additional deployed apps or other system modules
>> then request for the customer assembly server to be created.
>
> I wonder if we can think bigger :-)
>
> What if we distributed something with _all_ the cars in it and
> customizable profiles for the servers we ship now?  So, you wouldn't
> unpack a particular server, but the server construction kit.  You could
> pick a profile and optionally modify it, then spit out the desired
> server.  Then you would be able to pick jetty/tomcat and cxf/axis2 and
> however much deployment you wanted.

Couldn't we consider the maven repos as our server construction kit?
Seems that if users want this level of customization (building a server
from pieces instead of from an already working server) then using the
car-maven-plugin to build a server would be the preferred path.

>
> Alternatively maybe the "assemble a server" can show plugins from more
> than just the current server.
>
> thanks
> david jencks
>
>
>
>>
>>
>> Lin
>>
>> On Tue, Aug 12, 2008 at 4:10 PM, David Jencks <david_jencks@...>
>> wrote:
>>>
>>> client profiles might be apropriate too.
>>>
>>> I wonder how much of this is actually necessary?  e.g. if you install
>>> the
>>> jetty-deployer plugin you get jetty too.  If you install the
>>> jetty-console
>>> you get jetty....
>>>
>>> What if we had a "select the parts" page that was organized
>>> differently than
>>> the list of plugins.... e.g. checkboxes for web, ejb, webservices.  
>>> If you
>>> say yes to web, you get to choose jetty/tomcat, whether you want
>>> deployment,
>>> whether you want the console.
>>>
>>> Choosing web or ejb gives you the opportunity to include openjpa ( or
>>> maybe
>>> toplink in the future)
>>> Choosing webservices gives you the choice of cxf or axis2
>>>
>>>
>>> Just some more or less random thoughts
>>> david jencks
>>>
>
>