On Aug 28, 2008, at 2:30 AM, Rex Wang wrote:
Really an exciting roadmap on Customer Server Assembly! I'd like to
clear my understanding on this mission, and hope this helpful for
function centric server assembly.
Glossary:
Server template – a description of a customer server assembly, and
Lin, any thoughts on how we can automate testing of these new
profileplugins?
I saw you just converted the minimal assemblies over to use the web
profiles. Should we create a testsuite to verify that all of the other
platforms that we want to support (like Web + Axis2) can be generated
Comments/responses inline
Jay
Joe Bohn wrote:
Jay D. McHugh wrote:
Hey all,
I have been trying to get my thought straight on profiles/templates.
And, I think I just might have done it (we'll see). Warning, there is
very little 'implementation' here - mostly food for thought.
First of
Hey all,
I have been trying to get my thought straight on profiles/templates.
And, I think I just might have done it (we'll see). Warning, there is
very little 'implementation' here - mostly food for thought.
First of all, I think that it would be useful to have several ways of
thinking about
On Aug 25, 2008, at 12:12 PM, Jay D. McHugh wrote:
Hey all,
I have been trying to get my thought straight on profiles/templates.
And, I think I just might have done it (we'll see). Warning, there is
very little 'implementation' here - mostly food for thought.
First of all, I think that it
I agree with David that I think what you are proposing could be
achieved using the geronimo plugin group concept.
I have been working on/trying out things with the plugin group lately.
On my local machine, I can create a plugin group for the Web-tomcat
using c-m-p, and have it built into my
On Aug 25, 2008, at 2:30 PM, Lin Sun wrote:
I agree with David that I think what you are proposing could be
achieved using the geronimo plugin group concept.
I have been working on/trying out things with the plugin group lately.
On my local machine, I can create a plugin group for the
Jay D. McHugh wrote:
Hey all,
I have been trying to get my thought straight on profiles/templates.
And, I think I just might have done it (we'll see). Warning, there is
very little 'implementation' here - mostly food for thought.
First of all, I think that it would be useful to have several
On Aug 25, 2008, at 3:25 PM, Joe Bohn wrote:
Jay D. McHugh wrote:
Hey all,
I have been trying to get my thought straight on profiles/templates.
And, I think I just might have done it (we'll see). Warning, there
is
very little 'implementation' here - mostly food for thought.
First of all,
David Jencks wrote:
On Aug 25, 2008, at 3:25 PM, Joe Bohn wrote:
Jay D. McHugh wrote:
Hey all,
I have been trying to get my thought straight on profiles/templates.
And, I think I just might have done it (we'll see). Warning, there is
very little 'implementation' here - mostly food for
Right, I was thinking in that single plugin group, we can use the
other plugin groups. For example, if I want to build the plugin group
for tomcat-javaee5, instead of having individual geronimo plugins as
its dependencies, I can use web-tomcat, jms, webservices-axis2,
openejb, jsf, persistence,
Here is what I am thinking. Let me take the Web profile as an example:
So we want to allow users to check/select the Web profile to select
all the necessary geronimo plugins for little G. Users would only
see Web profile, instead the 10+ geronimo plugins.
This seems good, but don't we currently include both webservice
implementations in both javaee servers ,allowing you to swtich with a
command line property?
a small detail
david jencks
On Aug 22, 2008, at 6:24 AM, Lin Sun wrote:
Here is what I am thinking. Let me take the Web profile as
I actually forgot that - my bad. If that is the case, we'll let users
to pick web service Axis2 or web service CXF in both assemblies.
Lin
On Fri, Aug 22, 2008 at 12:05 PM, David Jencks [EMAIL PROTECTED] wrote:
This seems good, but don't we currently include both webservice
implementations
Hi David,
Thanks. I am able to come down to the following plugins to build
little G(tomcat based) and I tried to use transitive dependencies as
much as possible -
org.apache.geronimo.assemblies/geronimo-boilerplate/2.2-SNAPSHOT/jar
org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car
Hmm.. I'm not sure how this profile idea fits in with what the user
have to select in the assemble a server portlet. Would there be a
profile for axis2 that only has two plugins axis2 and axis2-deployer
defined? And there would be a similar profile with two plugins for
cxf? And the user would
On Aug 19, 2008, at 7:45 PM, Lin Sun wrote:
I have tried to come up with the minimum plugins to build little G.
In the case of tomcat, it needs the following plugins -
org.apache.geronimo.assemblies/geronimo-boilerplate/2.2-SNAPSHOT/jar
I have been thinking a bit more on how we achieve this. Here is my
idea and I welcome your input -
So we have a need to allow users to install groups of plugins(function
profile), instead of individual plugins. Install individual plugins
are nice for standalone apps, but for system modules, I
On Aug 19, 2008, at 1:20 PM, Lin Sun wrote:
I have been thinking a bit more on how we achieve this. Here is my
idea and I welcome your input -
So we have a need to allow users to install groups of plugins(function
profile), instead of individual plugins. Install individual plugins
are
David, thanks - if there is an easier way I'd love to learn that :)
Can you please explain a bit more on this function (leaving out
moduleid and get dependencies installed)? Does that mean that I build
a geronimo plugin without moduleId but with dependencies? If so, I'd
like to look at this
Looking good.
Seems that this would have to be part of our regular builds, otherwise
they would never be maintained if it requires manual editing of files.
I would like to see a profiles directory created in the build tree,
either as a peer to assemblies or as a child of assemblies. Also,
I have tried to come up with the minimum plugins to build little G.
In the case of tomcat, it needs the following plugins -
org.apache.geronimo.assemblies/geronimo-boilerplate/2.2-SNAPSHOT/jar
org.apache.geronimo.configs/jasper-deployer/2.2-SNAPSHOT/car
Kevan Miller wrote:
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
If we can make the customization process very easy in the first place, then
it won't be a pain to recreate the custom server due to a Geronimo upgrade.
Surely we can allow the user to export the config for a custom server, but
it might not be a good scenario for the users to edit this file by
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
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
Let's stay focused on what can be done for the current custom server
assemblies support in 2.2 for this thread versus new features, like the
server construction kit (which can be done today via c-m-p and the maven
repos.)
Need to also think about adding some unit tests in the testsuite to
I would be in favor of this - stay focus for the 2.2 release first.
I do appreciate many ideas proposed here which always challenge me to
think outside of the box! :) We should revisit these ideas (server
construction kit, assembly server from not only local current server,
but also local repo
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
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
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
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 [EMAIL PROTECTED] wrote:
My one comment, at the moment, is the discussion
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
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
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
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
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
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,
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
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
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
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
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
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
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
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 [EMAIL PROTECTED] wrote:
Thanks for the valuable feedback.
So basically, you are proposing to consolidate 3
46 matches
Mail list logo
