Jeff Genender wrote:
> Jeremy Boynes wrote:
Ugly :-) Should work. May run into problems with paths and/or
resolving. What base are the includes relative to (hate it if you had
to be in a specific directory)?
We should make sure to include all the plans in the final distribution
(after velocity post-processing for version info).
The include base in the example was just that...an example...I think
there are a few ways to handle it or even rename the included files to
not end in xml. ;-)
Actually I am not sure what is more ugly at this
point...commenting/uncommenting all the places to remove Jetty and add
Tomcat, or adding a couple of includes, then having only to
comment/uncomment 3 places. Also this would provide for Tomcat to
auto-launch since its plan would be a part of the j2ee-server-plan (like
Jetty is now)...no longer needing to specifically start Tomcat from the
command line.
However...this is moot if you have (or are close to having) a
configuration builder or we just package up a Tomcat ready
j2ee-server-plan.xml/configuration.
If we weren't close to this, I was going to suggest doing the includes
so that users can swap out the web containers completely with a minimum
of commenting/uncommenting. It also places all the Jetty and Tomcat
stuff in one location (which may be cleaner to some degree).
What do you think?
I think it is a step in the right direction. Getting the plans broken
down will give us a conceptual model of how they go together even if for
now they end up in one big one.
Supporting separate bundles will mean changes to the configuration
classloader model (to support something like export/import) which is a
change I think we need to discuss esp. if we are going to put it in 1.0.
I would suggest packaging up Tomcat as a separate assembly so that we
can certify both. I think people would want to download one or the other
and would not really be interested in a hybrid release capable of
supporting both.
--
Jeremy
