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




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to