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 + Clusteringclient 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). LinOn 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/testedprofiles to use for assembling servers (like Web + JMS). If we provide application and advanced paths, then we also need to provide aprofile/function path, which would allow companies/ISVs to create custompackages 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
smime.p7s
Description: S/MIME Cryptographic Signature