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.

Does this directory need to be retained when advancedMode is true?

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.

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

Reply via email to