On Sep 28, 2005, at 9:52 AM, Aaron Mulder wrote:

On 9/28/05, David Jencks <[EMAIL PROTECTED]> wrote:
well, I looked at what was in the izpack config files and what is
configured to assemble geronimo and they don't have a very close
relationship to each other.  I think it's a safe conclusion that it
won't work.  I hope I'm wrong.

"Won't work", I can agree with.  But I don't think that it will be so
onerous to unbreak it.

I hope you're right :-)


Ok, how do I run the installer?  Where are the instructions for it?
How is it packaged?  At the moment we have no way of testing anything
from the installer, so are there any plans to certify a geronimo
distribution that includes the installer? Who is going to test it?  If
we don't certify it do we want to ship it?  How would we make it clear
that the geronimo-installer is not certified?

The basics are here:
http://wiki.apache.org/geronimo/Building_an_Installer  Note that RC
builds of IzPack 3.8.0 are available now, so it should be possible to
download a binary instead of building IzPack from source.

Can you send me one such or point me to it? I can't find anything after 3.7.2 on their site.

(Once those
are posted to Maven, we can incorporate it directly into our scripts.)
 And of course the text talks about altering plans, where in fact now
we can just substitute values into config.xml, but that's what the
installer configuration does at the moment so it shouldn't be a big
change.

If we changed the installer so all it does is produce  customized
config.list/xml files and does not change anything else in the
distribution I think we could include it with the standard certified
distro.  If it does anything else I think we would have to certify it
separately.

That should be the case.

I'm assuming we're going to distribute 2 Geronimo packages, 1 Tomcat,
and 1 Jetty. Likewise, we should have 2 installer packages, 1 Tomcat,
and 1 Jetty.  They'd probably use the exact same install sequence and
substitution variables, just slightly different config.xml/config.list
files.  This is no different than the non-installer builds.

I don't think we can do this for M5 based on how the tck stuff is
working.  I think we need to ship 1 geronimo package that can be run
with jetty, tomcat, or both.
I'm finishing up changes that will build configurations for the apps
for each of jetty and tomcat.
I think the most plausible thing we can do for M5 is supply sets of
config.list/xml files for jetty only, tomcat only, and both, and
include all the configurations.

Is it your position that this is a temporary aberration for M5 and
that starting with the next release we will ship separate Tomcat and
Jetty builds?  Or are you recommending this is a general approach
moving forward?  Because I am strongly opposed to this approach, but
I'll let it go if it's for M5 only.  I'll start a new thread with my
reasoning if you think this is a good way to go moving forward.

I don't know what the best approach is moving forward. I like some things about shipping both but it is obviously not something likely to be often used. I think it would be desirable to have some way of ending up with a geronimo installation that only supports one web container and doesn't include the other web container (even its classes) but I don't know the best way of attaining that goal.


I explained the current setup in more detail in another email.  I
originally thought we should have the installer remove unwanted
configurations but after more thought I think this might not be
consistent with the tck certification guidelines.

Yeah, I found that.  Again, if this is temporarry, fine, let's get it
out.  Otherwise, I think we need some discussion around this.

See the last point :-)  I'm fine with several end products so long as:
1. There isn't appreciable duplication of build stuff
2. each module has really only one output
3. single-web-container versions don't include the other web container at all. 4. there is some end product in which you can switch web containers just by changing some configuration files.

I wonder if an installer that removed configurations and repository jars would satisfy this.

thanks
david jencks

Reply via email to