There's one other thing to consider here related to the console that
I'll toss out. It appears that it may not always be feasible to have a
single, common management portlet (or API) to always address the needs
of both containers. I know this is another controversial topic (to have
common management or not). However I'm not convinced we can achieve
100% common management or that we would even want to in all cases. This
probably makes sense 90%+ of the time ... but we're starting to see some
differences in particular areas where things are not as standardized.
One example on the tomcat and jetty front appears to be in the type
performance/measurement statistics available. Until we can get a more
dynamic console (possibly by using a more robust Portal server) we can't
fully accommodate the different possible configurations in a clean
manner (even for tomcat and jetty). I think that the two assemblies is
the right approach anyway, but we might not have a choice when it comes
to the console requirements.
David Jencks wrote:
On Sep 19, 2005, at 10:24 PM, Aaron Mulder wrote:
I think we need to finalize our plan for Tomcat and Jetty for M5 (or
whatever we call it).
I'll call it M5 for the purposes of this reply :-)
I believe we agreed earlier to produce separate Tomcat and Jetty
releases.
I would like to revisit this decision for M5. I think it will produce
an unwarranted amount of disruption for essentially no gain.
Currently, our "modules/assembly" build creates a distribution with
BOTH Tomcat and Jetty, and I believe even starts both by default
(though I'm not sure of that).
It shouldn't, only one should start.
I don't like that solution very much, for reasons which I think I've
covered in other threads. I'd like to actually remove the
configuration(s) for the product not included in the desired
distribution. The most pressing reason for this is so that the
console can safely assume that only one web container is present.
While we need to correct it to handle multiple web containers, I think
that's a lot of unnecessary work for M5, compared to limiting
ourselves to deploying one web container in each build.
So the question is, how to we get two different builds for Jetty and
Tomcat? The short-term options (e.g. not switching to assemblies/*,
which I assume would be a major undertaking) seem to be:
- Change "modules/assembly" so that the Jetty/Tomcat decision
actually doesn't deploy or undeploys the non-matching web container
configuration(s), instead of just changing the list of modules to
start by default.
I am strongly against trying to get one module to produce two
barely-related outputs. This is really against maven principles. If
we want separate jetty and tomcat distros, we need to have two
assembly modules, one for each. IMO the "dual use" one has some
utility, so that means 3 assembly modules.
- Create two wrapper modules that each take the output of
"modules/assembly" and one strips the Tomcat stuff and configures it
for Jetty and the other does vice versa.
this is sort of ridiculous IMO.
The former is certainly the quick+dirty solution, but it results in us
needing to run the build twice and creates two output artifacts with
the same name but different contents. I suspect that will be
objectionable, which leads me to believe that the second option would
be preferable. Anyone else have thoughts on this (or the best way to
do this)?
Using our current ad-hoc assembly module, we would have 3 copies of
essentially the same code and be generating mostly the same
configurations 3 times over. This is pretty silly and extremely hard
to maintainable. IMO the only reasonable approach that is compatible
with maven principles is to separate building the configurations and
assembling them into the distros.
I think this is a good idea, but I think we should get what we have
now out. My understanding of the main purpose of M5 was to
demonstrate tomcat integration rather than a complete web console.
What we have now, with both jetty and tomcat included, demonstrates
that to my mind. I think certification is plenty to work for.
thanks
david jencks
--
Joe Bohn
[EMAIL PROTECTED]
"He is no fool who gives what he cannot keep, to gain what he cannot lose."
-- Jim Elliot
