geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: M5: is the izpack installer anywhere near alive?
Date Wed, 28 Sep 2005 18:50:51 GMT

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

> On 9/28/05, David Jencks <> 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:
>  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.

david jencks

View raw message