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: differences between installer installation and tomcat/jetty
 installations
Date: Wed, 1 Feb 2006 09:09:04 -0500
User-Agent: KMail/1.8.2
References: <43E04269.8050809@gmail.com>
 <200602010551.07700.erikd@schemacity.org> <43E0BD41.3060105@earthlink.net>
In-Reply-To: <43E0BD41.3060105@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602010909.05357.erikd@schemacity.org>


 On Wednesday 01 February 2006 08:53, Dave Colasurdo wrote:
> Erik Daughtrey wrote:
> >  On Wednesday 01 February 2006 03:09, David Jencks wrote:
> >> On Jan 31, 2006, at 9:08 PM, John Sisson wrote:
> >>> 1) In the 1.0 branch I noticed that an installer installation has
> >>> geronimo/repository/geronimo/cars directory (containing approx 42
> >>> MB of car files) but the tomcat & jetty assemblies don't have the
> >>> car directory. Is this intended?
> >
> > Yes
> >
> >>> When are car files in the repository used?
> >
> > During final processing, the ConfigInstaller runs which installs the cars
> > associated with the selected packs into the config-store. The
> > ConfigInstaller reads var/config/configure.xml to determine which cars
> > need to be installed. Configure.xml is created by the assembly plugin,
> > but contains
> > variables to be replaced at install time to inform ConfigInstaller
> > of which cars need to be installed.
>
> Assuming these aren't needed after installation, can/should these files
> be deleted by the installer therefore saving 42M?  I know diskpace is
> cheap, though it is one of the measurements that gets used when
> comparisons are done against other application servers.
Already thinking about this. I was thinking that the ConfigInstaller
could have an option to delete the cars when it's done.  For the 
default install, this would be true always.
I think DJ is probably glad we've gotten to the point where we can consider 
these cleanup options :)

>
> Does this directory need to be retained when advancedMode is true?
For the advancedmode install, deletion of the cars could be an option.
There's some doc that needs to accompany this option though since
one should install all packs for options that might ever be configured.
All this could probably be incorporated into a new panel which 
explains the options and queries for disposition.
>
> >> I think this is an artifact of the way the installer is working right
> >> now, namely including a repo inside it and copying everything into
> >> the server under construction, whether or not it is used.  I want it
> >> to install only the stuff you select.
> >>
> >>> 2) I also noticed that in the installer installation using the
> >>> default options, the following files (that are installed for the
> >>> jetty/tomcat assemblies) are not installed:
> >
> > I fixed this with the patch on GERONIMO-1518.  Originally,
> > I had missed the dependency in project.xml and the files
> > were not copied to target.
> >
> >>> geronimo/repository/jars/geronimo-javamail-transport-1.0.1-
> >>> SNAPSHOT.jar
> >>> geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar
> >>>
> >>> What happens if the user initially does not select SMTP transport
> >>> (the default) in the installer and then after installation changes
> >>> their mind?  How are we expecting the user to get it installed?
> >
> > Interesting question. There are some interesting options here.
> >
> > 1. If one uses the installer in default mode, the situation mentioned
> > will occur. For instance, if javamail is not selected, then it will not
> > be installed and the easiest remedy is a reinstall.
> >
> > 2. If, however, one uses the -Dadvancedmode=true mode of the
> > the installer, then it's possible to install the configuration, but have
> > it inactive at runtime. It'll be in the config, but not running in the
> > server. Of course, with item #1, it's possible to install everything and
> > disable unwanted items in config.xml manually and achieve the same goal.
> >
> > 3. There's actually a third option that's not exposed well (yet?). One
> > might install everything with the advanced installer then delete
> > everything in config-store, modify configure.xml, run ConfigInstaller to
> > get a new configuration and modify config.xml accordingly.  Of course,
> > this would be for very advanced folks.
>
> In the future, it may be worth considering "late-feature addition".  The
> user can rerun the installer, it detects what is already installed and
> allows the user to select and install additional components.  Of course,
> I realize that izpack probably doesn't lend itself to this and am not
> suggesting this for any current release.  Just wanted to throw out the
> idea for the future.  For now, option 1 seems fine.
>
Yes, as the installer matures, these types of features should be 
considered.  I'd also like to see us build an "online installer".
Coupling an online capability with the ability to add new features
would make this even more powerful.
Additionally, an online installer could allow for a very small
download footprint for the installer. Then the installer would
download only what is selected for install.
> >> Due to my theory about (1), I think that these are simply left out of
> >> the installers internal repo and so the mail config may not work.  As
> >> noted in (1) in my opinion these should get copied into the server
> >> under construction only if you select the mail configuration for
> >> installation.
> >
> > 1518 accomplishes this.
> >
> >> thanks
> >> david jencks
> >>
> >>> Thanks,
> >>>
> >>> John

-- 

Regards,

Erik