You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by John Sisson <jr...@gmail.com> on 2006/02/01 06:08:57 UTC

differences between installer installation and tomcat/jetty installations

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?

When are car files in the repository used?

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:

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?

Thanks,

John

Re: differences between installer installation and tomcat/jetty installations

Posted by Erik Daughtrey <er...@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

Re: differences between installer installation and tomcat/jetty installations

Posted by Erik Daughtrey <er...@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. JIRA 1568.
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.
All this could be done with a new panel which queries for a 
disposition of the CAR files post install.  Of course, the panel
needs to explain that only CAR files for options actually 
installed will be available for use. Until we have a good way
to use these CAR files after and install, it probably doesn't 
make sense to add this.
>
> >> 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

Re: differences between installer installation and tomcat/jetty installations

Posted by Dave Colasurdo <da...@earthlink.net>.
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
> 

Re: differences between installer installation and tomcat/jetty installations

Posted by Erik Daughtrey <er...@schemacity.org>.
 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.
>
> 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.
>
> 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

Re: differences between installer installation and tomcat/jetty installations

Posted by David Jencks <da...@yahoo.com>.
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?
>
> When are car files in the repository used?

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:
>
> 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?

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.

thanks
david jencks

>
> Thanks,
>
> John