I would love to have a way where people can download the uber tar
ball which includes all the bits we have at the time and let the user
choose their server type and personality. I believe that a majority
of our users are looking more for a server assembly that is a Java EE
5 server with the bits they need to develop Java EE applications (and
or deploy them). What seems manageable to me is that we choose a
finite set of Java EE 5 assemblies (no more than two based on Jetty
and Tomcat given our history, that are certified. Dain made a
comment and I've heard similar things that to be certified all modes
of operation must be exercised and I think that someone might
reasonably apply it to all the pieces of the uber server.
Based on feedback I've gotten from users I know that I often hear
Tomcat and OpenJPA as a combo they are interested in. As far as the
web services piece I haven't really heard a strong preference one way
or another. however, since that's not my strong suit that's not a
good indication of anything. Do others have feedback in this area?
For purposes of this discussion I'll throw out the following combos
for discussion:
Tomcat, CXF and OpenJPA
Jetty, Axis 2 and Cayenne
The benefits are that it pretty much does cover all the major
technologies in terms of fitting them together. Using DayTrader, we
should be able to deploy DT unchanged (app or DDs) on both
assemblies. The desire would be that we have a common abstraction
point so that if someone wants to use Jetty, CXF and OpenJPA that it
should be a simple matter of selecting the appropriate plugins. That
said, I'd prefer to not try and provide the universal adapter that
can configure everything in the world and lose site of delivering a
Java EE 5 container for users to look at in time for Java One (my
personal desire I'll admit).
I'll defer to the guys actually working on TCK to tell us what they
are planning on certifying as they are doing the bulk of the work.
What makes sense to me is to have at least one that is certified
(more is nice) and that we keep the train moving and offer additional
certifications over time as interest and TCKing deliver. To make the
proposal concrete our download page would have:
*Java EE 5 Certified*
Tomcat, CXF, OpenJPA
Jetty, Axis2, Cayenne
Windows and *nix versions. An uber (you can create your own
personality would be awesome.
On Feb 11, 2007, at 12:40 AM, Jason Dillon wrote:
On Feb 10, 2007, at 9:25 PM, Paul McMahan wrote:
I agree that this approach would avoid network dependency but I'm not
as convinced that network access presents a problem. Most of the
installers I've used lately depend on network access in one way or
another. I also suspect that users will customize their server right
after downloading it.
Many installers I've seen allow for light version which rely on the
network to fetch components, and have a complete version which
includes all of the components.
From an automation perspective it would be best not to add more
network dependency, so that once we have a distro zip, we can
assume that personality configuration will function with-out
unexpected failures due to network issues.
Besides a smaller download size, the plugin approach has the
advantage
that the CLI and admin console are already available for driving the
server customization process. Should we invest additional effort in
providing the user with another way to achieve effectively the same
results? If so then will it be clear to users when to use the plugin
installer vs. when to use this alternative mechanism?
IMO, the personality bits are simply collections of plugins
(perhaps a few non-plugin cars) to be applied to a base
installation. I think the concept is complementary with what we
have now.
One other factor to consider is that the "one big assembly" approach
would only deactivate components when they are replaced and not
actually uninstall them (at least if I understand your proposal
correctly). If the deactivated components were later reactivated
from
the admin console or from an environmental dependency then the server
could enter an unusable state.
Sure, that is a danger... though that danger exists today. I was
not suggesting any specific implementation, but one solution would
be to ship all of the extra components for personalities in a
different repository dir, then the personality application tool
would install from one repo to another.
But, really, we probably need to create some mechanism to classify
types of plugins, and then warn the user if they are attempting to
enable/install a plugin which collides with another plugin already
installed. For example, if there a Jetty plugin already installed,
trying to install Tomcat would warn strongly that a duplicate
"webcontainer" plugin was already installed (and let them install
it if they know better than we do).
RPMs do something similar with its 'provides' tag in spec files...
so for example, the apache httpd RPM package might provide
'webserver', fnord (another light http server) might also provide
'webserver' and when apache httpd is already installed, attempts to
install fnord will barf with a conflict (which can be forced to
override).
--jason
