Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
From: Erik Daughtrey <erikd@schemacity.org>
To: dev@geronimo.apache.org
Subject: Re: The Installer
Date: Wed, 16 Nov 2005 13:01:29 -0500
User-Agent: KMail/1.8.2
References: <5f55533d23f45d4b6f59b1a635ac319c@yahoo.com>
 <200511161211.20766.erikd@schemacity.org>
 <74e15baa0511160945x118147b8qdc1a8307b731f348@mail.gmail.com>
In-Reply-To: <74e15baa0511160945x118147b8qdc1a8307b731f348@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200511161301.29822.erikd@schemacity.org>


Thanks for the ibiblio information.  

I'm not keen on pushing changes into IZPack at this point. The statement was 
more of a nod at the possibility that IZPack may not have all the capability 
we'd like.  After looking at the documentation a little more, I see that it 
probably won't be necessary. 

I'll plan on having the installer impose an either-or policy on web container 
installation.

Regards,

erik

 On Wednesday 16 November 2005 12:45, Aaron Mulder wrote:
> I don't want to discourage you, but I don't think the timing will work
> out too well on IzPack improvements.  Their releases are pretty
> infrequent and I think the main developer is on vacation at the
> moment.  I didn't have much luck getting other Geronimo folks
> interested in using my custom hacked IzPack build, which is why it was
> so nice to see 3.8.0 released.  So let's make the best of what we've
> got in the standard build, and perhaps keep a list of improvements
> we'd like to see to IzPack in the post-Geronimo-1.0 time frame.  (A
> hook to validate an entire user entry screen at a time is on my list.)
>
> Anyway, the Maven instructions (from John Sission, sorry John) are:
>
> http://maven.apache.org/maven-1.x/reference/repository-upload.html
>
> And as for the radios, I think we should definitely enforce only 1 web
> container through the installer.  That will save us a whole world of
> pain.  If people want 2 web containers, let them take some manual
> steps!
>
> Aaron
>
> On 11/16/05, Erik Daughtrey <erikd@schemacity.org> wrote:
> > I read the "Building an Installer" wiki page. It helped me get going. 
> > It's getting a little crusty, but it was still very helpful.
> >
> > I'd be interested in the ibiblio information.  Please send it along.  I
> > had already figured that I'd be researching this based on David's post.
> >
> > I'll look into the port validation issues and see if there's something
> > easily done from within IZPack.  I'm not averse to helping improve IZPack
> > if it can help both projects and there's actually time to do the work.
> >
> > I am assuming I should create JIRAs for each of the issues raised. Unless
> > someone disagrees, I'll do this.
> >
> > Regards,
> >
> > erik
> >
> >  On Wednesday 16 November 2005 11:03, Aaron Mulder wrote:
> > > 1) I think the standalone compiler is the only necessary JAR, and I
> > > had volunterred to try to get it onto iBiblio at one point, but didn't
> > > actually get around to it.  It would be great if someone else could do
> > > that.  Someone (Jacek?) pointed me to a writeup on how to get
> > > arbitrary JARs onto ibiblio, and I can pass that along if it would be
> > > helpful.
> > >
> > > 5) I think port validation was tricky, because IIRC, each field is
> > > validated independently.  I don't think there's a good way to validate
> > > a whole screen at a time, much less a group of ports on a group of
> > > screens, some of which you may not have seen yet.  If this turns out
> > > to be hard, I don't think it would be the end of the world to skip it
> > > for now, since presumably the user knows not to create port conflicts.
> > >
> > > 7) I think we could safely install all the schemas if you install J2EE
> > > features, and none of the schemas otherwise.  It's not quite perfect,
> > > but close enough.
> > >
> > > The other problem we need to think about, related to the port issue,
> > > is setting the default web port.  If you install only Jetty or Tomcat,
> > > whichever one you install should default to 8080.  But if you install
> > > both, they should default to different ports.  I would be OK saying
> > > that the installer will not install both, which would make this
> > > easier, but I don't think there's that kind of exclusivity in the
> > > feature selection screen.
> > >
> > > Then again, I haven't worked with IzPack for a while now so my
> > > information may be a little out of date.  :)
> > >
> > > Aaron
> > >
> > > On 11/16/05, Erik Daughtrey <erikd@schemacity.org> wrote:
> > > > Hey David,  I'll start working on these items.
> > > >
> > > > erik
> > > >
> > > >  On Wednesday 16 November 2005 03:24, David Jencks wrote:
> > > > > It would be good if we could get the installer working well for
> > > > > 1.0. Here are some of the things I think need to happen.
> > > > >
> > > > > 1. The necessary izpack jars need to get into some maven repo,
> > > > > preferably a public one such as ibiblio.  They might be on there
> > > > > way there already, otherwise we should figure out which jars are
> > > > > needed and file an upload request.
> > > > >
> > > > > 2. Installer building should occur in its own module in assemblies.
> > > > >  It would be best if the installer can be built using a maven
> > > > > plugin, but if that seems impractical we can use a bunch of jelly
> > > > > for now.  There is an izpack plugin but I think it is maven 2 only
> > > > > (??).
> > > > >
> > > > > 3. The installer currently has a page where you check the major
> > > > > features you want, and on the following pages you configure them. 
> > > > > This seems like a basically acceptable paradigm to me, but there is
> > > > > a problem in that all the "following pages" display even if they
> > > > > are empty.  I've been told that moving the <createForPack> element
> > > > > out  one level to the panel element will fix this.
> > > > >
> > > > > 4. The installer currently works by installing everything in a full
> > > > > geronimo install, and not starting the pieces you don't want.  This
> > > > > is rather unsatisfactory unless you sell disk space.  The geronimo
> > > > > assembly is moving to use of the packaging and assembly plugins,
> > > > > and we can leverage that with the installer.  What I am thinking of
> > > > > is including a maven repository inside  the installer jar that
> > > > > includes everything from a full geronimo install with everything,
> > > > > including all the .car files for the configurations.  Then  we can
> > > > > imitate or use the assembly plugin to copy the configuration
> > > > > dependencies into the install target and install the actual
> > > > > configurations.
> > > > >
> > > > > 5.  We should find a way to check that no port conflicts have been
> > > > > configured.
> > > > >
> > > > > 6. We need to construct a config.xml file for the target install. 
> > > > > This could be done by adding bits associated with each
> > > > > configuration, or by removing chunks from a "universal" config.xml
> > > > > for the configurations we didnt' install.
> > > > >
> > > > > 7.  Somewhat similarly, we need to include the schema files (for
> > > > > human reference, they aren't used by geronimo) for the bits that
> > > > > are included in the install target.  This should proceed by fixing
> > > > > the xmlbeans plugin to put schemas in the same place the xmlbeans
> > > > > ant task does, and by extracting all such schemas from our
> > > > > dependencies.  This needs to be added to the assembly plugin: it is
> > > > > not installer specific.
> > > > >
> > > > > There's probably more to do, but this is what I've thought of so
> > > > > far.
> > > > >
> > > > > thanks
> > > > > david jencks
> > > >
> > > > --
> > > >
> > > > Regards,
> > > >
> > > > Erik
> >
> > --
> >
> > Regards,
> >
> > Erik

-- 

Regards,

Erik