I've explained what is currently implemented. I'm willing to make it
so selecting jetty or tomcat does not start the other configuration,
but where both configurations are present. If anyone wants to build
separate jetty and tomcat distributions that are actually missing the
other container, for m5, I will not stand in their way so long as they
keep the tck running at least as smoothly as it is now, but I do not
have the time or interest to put into it. I have no expectations that
the console will do anything in particular in M5. I do wonder how you
determine which container is running.
I will say that I think that the current assembly module approach to
building geronimo distributions is really bad and that something based
on the packaging and assembly plugins should be much more maintainable.
I am aware that this opinion is shall we say controversial.
Using the same module to build two unrelated versions of the geronimo
distribution definitely violates the maven philosophy, and I suggest if
anyone wants to build separate distributions that they do so in two
separate modules.
On Sep 9, 2005, at 10:11 AM, Bill Stoddard wrote:
Aaron Mulder wrote:
I really believe that choice is a bad thing.
umm, really? why aren't we using jboss? or jonas?
I don't believe we should offer 2 options to a user. How are they
supposed to decide? How are we supposed to guide them?
So we should just drop support for jetty or tomcat completely? Which
one?
I'll grant you that there may (*may*) be some possible reason for
a very advanced user to want to run 2 different web containers. I
really
believe this should be an advanced manual process (e.g. download
Tomcat
build, then deploy Jetty plan). I really really really don't want to
encumber every user with both Jetty and Tomcat in order to support
this
dual-container feature.
We have been including all the jar files for both jetty and tomcat for
some time. Adding the configurations to run them is a tiny step
compared to this. I think if we remove one of the configurations we
need to remove the jar files that are only used with it.
+1
Gratuitous feature creep is evil and this particular feature violates
the "principle of least astonishment".
From my point of view, we are finally seeing some partial benefits from
being able to use some of the fundamental architectural features of
geronimo. I don't really care how we present the choice of container
to the user in M5 so long as it doesn't complicate the build or running
the tck. I've taken the approach that seems to me to most clearly
express geronimo principles and provides (in my opinion) the simplest
build and test path. I don't think that the possible benefits of
providing two builds that each include only one container outweigh the
additional project management complexity involved.
thanks
david jencks
