[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer_dev_notes.jar Unfortunately, I will no longer be able to work on the installer. I need to move to other, more pressing projects. Hopefully, someone will be able to pick up the work. I'm not sure if the plan would be to continue with IzPack, but if so, then the attached document will help someone come up to speed on the changes I made. The document was originally intended as a way to start a dialog with the IzPack folks so that we could come to an understanding on how best to move forward with IzPack. I hope that if the work is continued that interaction with the IzPack team will proceed so that both projects may benefit. Good luck to all. Erik > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: installer > Versions: 1.2, 1.1 > Reporter: erik daughtrey > Attachments: installer-G1518.patch.gz, installer-jar-refactor-1.0.1.patch, > installer-jar-refactor.patch, installer.G1518-2.patch.gz, > installer_dev_notes.jar > > Install configuration using installer jar as source repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer.G1518-2.patch.gz This patch includes everything from G1518.patch as well as adjustments for recent repository changes. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: installer > Versions: 1.2, 1.1 > Reporter: erik daughtrey > Attachments: installer-G1518.patch.gz, installer-jar-refactor-1.0.1.patch, > installer-jar-refactor.patch, installer.G1518-2.patch.gz > > Install configuration using installer jar as source repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Please welcome the newest committer - Hernan Cunico
Way to go, Hernan!
On Friday 24 February 2006 09:53, Bruce Snyder wrote:
> In recognition of his contributions, the Geronimo PMC has extended an
> offer of committer karma to Hernan Cunico and he has accepted. Please
> welcome me in congratulating Hernan for his contributions thus far and
> many more to come.
>
> Keep up the great work, Hernan!
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E
> Apache Geronimo (http://geronimo.apache.org/)
>
> Castor (http://castor.org/)
--
Regards,
Erik
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer-G1518.patch.gz > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-G1518.patch.gz, installer-jar-refactor-1.0.1.patch, > installer-jar-refactor.patch > > Install configuration using installer jar as source repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Description: Install configuration using installer jar as source repository. (was: Change this issue to only apply to 1.0.1. Another issue will be created to address 1.1.) Version: 1.1 The new patch: 1. Installs the configuration using the installer jar as a repository. 2. Fixes the problem with the console (extra line added to Pluto xml). 3. Properly includes javamail dependency in project.xml. 4. Adds additional logging capabilities to FixTextLines (-DTRACE=true). 5. Executes configuration installer and FixTextLines as extensions of the installer rather than external java executables. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Install configuration using installer jar as source repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=all ] erik daughtrey updated GERONIMO-1614: - Geronimo Info: (was: [Patch Available]) Please close this JIRA. The patch for GERONIMO-1518 fixes this problem in a better way than completely bypassing config-store. FixTextLines inserts an extra line. This behavior is changed with G1518 and fixes the problem. > Installer - Console portal servlet fails to load properly after install > --- > > Key: GERONIMO-1614 > URL: http://issues.apache.org/jira/browse/GERONIMO-1614 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0.1, 1.1 > Reporter: erik daughtrey > Attachments: installer-console-textline-fix.patch > > The FixTextLines function "fixes" all CRLFs in xml and other file types > across the Geronimo > install tree. Apparently, the version of the Pluto portal being used does > not > appreciate its XML files being adjusted. > The fix will cause FixTextLines to bypass the config-store directory when > fixing line endings. > Additionally the fix blends in some new error/trace logging functionality > which may > be enabled with -DTRACE=true on the installer command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=comments#action_12366397 ] erik daughtrey commented on GERONIMO-1568: -- Please close this JIRA > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-delete-car-files.patch > > Changed version. Deleting the car files is a work-around > for now and will be done for 1.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=all ] erik daughtrey updated GERONIMO-1568: - Geronimo Info: (was: [Patch Available]) GERONIMO-1518 fixes this problem by not installing the car files in the first place. Don't apply this patch. > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-delete-car-files.patch > > Changed version. Deleting the car files is a work-around > for now and will be done for 1.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=comments#action_12365819 ] erik daughtrey commented on GERONIMO-1614: -- FixTextLines does append an extra line. There's some possibility that this is causing the problem. As I recall, the specific problem was with the xml files in: config-store//geronimo-console-framework-1.0.1-SNAPSHOT.war/WEB-INF/data > Installer - Console portal servlet fails to load properly after install > --- > > Key: GERONIMO-1614 > URL: http://issues.apache.org/jira/browse/GERONIMO-1614 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-console-textline-fix.patch > > The FixTextLines function "fixes" all CRLFs in xml and other file types > across the Geronimo > install tree. Apparently, the version of the Pluto portal being used does > not > appreciate its XML files being adjusted. > The fix will cause FixTextLines to bypass the config-store directory when > fixing line endings. > Additionally the fix blends in some new error/trace logging functionality > which may > be enabled with -DTRACE=true on the installer command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=comments#action_12365783 ] erik daughtrey commented on GERONIMO-1518: -- The fix for JIRA 1614 fixes the problem with the console. The fix for copying the dependencies by hand is still in the works. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
[ http://issues.apache.org/jira/browse/GERONIMO-1614?page=all ] erik daughtrey updated GERONIMO-1614: - Attachment: installer-console-textline-fix.patch Change to bypass target install's config-store directory when fixing line endings. Added trace feature. > Installer - Console portal servlet fails to load properly after install > --- > > Key: GERONIMO-1614 > URL: http://issues.apache.org/jira/browse/GERONIMO-1614 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0.1, 1.1 > Reporter: erik daughtrey > Attachments: installer-console-textline-fix.patch > > The FixTextLines function "fixes" all CRLFs in xml and other file types > across the Geronimo > install tree. Apparently, the version of the Pluto portal being used does > not > appreciate its XML files being adjusted. > The fix will cause FixTextLines to bypass the config-store directory when > fixing line endings. > Additionally the fix blends in some new error/trace logging functionality > which may > be enabled with -DTRACE=true on the installer command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1614) Installer - Console portal servlet fails to load properly after install
Installer - Console portal servlet fails to load properly after install --- Key: GERONIMO-1614 URL: http://issues.apache.org/jira/browse/GERONIMO-1614 Project: Geronimo Type: Bug Components: installer Versions: 1.0.1, 1.1 Reporter: erik daughtrey The FixTextLines function "fixes" all CRLFs in xml and other file types across the Geronimo install tree. Apparently, the version of the Pluto portal being used does not appreciate its XML files being adjusted. The fix will cause FixTextLines to bypass the config-store directory when fixing line endings. Additionally the fix blends in some new error/trace logging functionality which may be enabled with -DTRACE=true on the installer command line. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=comments#action_12365314 ] erik daughtrey commented on GERONIMO-1518: -- Ok, I'll go ahead and get this going then. Thanks. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=all ] erik daughtrey updated GERONIMO-1568: - Attachment: installer-delete-car-files.patch This patch applies to branches/1.0 only. The resultant cleanup after an installer based install is about 25MB. > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-delete-car-files.patch > > Changed version. Deleting the car files is a work-around > for now and will be done for 1.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=all ] erik daughtrey updated GERONIMO-1568: - Geronimo Info: [Patch Available] Description: Changed version. Deleting the car files is a work-around for now and will be done for 1.0.1. was: Version: (was: 1.1) > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > > Changed version. Deleting the car files is a work-around > for now and will be done for 1.0.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer-jar-refactor-1.0.1.patch This patch applies to 1.0.1 only. Disregard prior patch i.e. DO NOT USE installer-jar-refactor.patch. Thanks. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor-1.0.1.patch, installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Description: Change this issue to only apply to 1.0.1. Another issue will be created to address 1.1. was: Version: (was: 1.1) > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor.patch > > Change this issue to only apply to 1.0.1. Another issue will be created > to address 1.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
[ http://issues.apache.org/jira/browse/GERONIMO-1568?page=comments#action_12364805 ] erik daughtrey commented on GERONIMO-1568: -- The installer should be modified to tell the configinstaller to delete the cars after a default mode install. Add functionality to the advanced mode of the installer to make this an option. > Installer - Have ConfigInstaller optionally delete CARs after configuration > is complete. > > > Key: GERONIMO-1568 > URL: http://issues.apache.org/jira/browse/GERONIMO-1568 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: differences between installer installation and tomcat/jetty installations
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 mature
Re: differences between installer installation and tomcat/jetty installations
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
[jira] Created: (GERONIMO-1568) Installer - Have ConfigInstaller optionally delete CARs after configuration is complete.
Installer - Have ConfigInstaller optionally delete CARs after configuration is complete. Key: GERONIMO-1568 URL: http://issues.apache.org/jira/browse/GERONIMO-1568 Project: Geronimo Type: Improvement Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: differences between installer installation and tomcat/jetty installations
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
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Geronimo Info: [Patch Available] Version: 1.0.1 > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer-jar-refactor.patch Refactored the installer xml to install the correct jars for each pack. > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1 > Reporter: erik daughtrey > Attachments: installer-jar-refactor.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Reopened: (GERONIMO-1287) IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms
I tested the Installer and FixTextLines function on windows, but had not seen this problem there. I'll do some more testing to see if I can replicate the problem. Regards, erik On Monday 30 January 2006 23:47, John Sisson (JIRA) wrote: > [ http://issues.apache.org/jira/browse/GERONIMO-1287?page=all ] > > John Sisson reopened GERONIMO-1287: > --- > > > Ran installer on windows and found the following message at the end of the > output in the IzPack processing window: > > Installed configuration geronimo/shutdown/1.0.1-SNAPSHOT/car > Configuration complete. > FixTextLines: C:\test\ginstall\var\temp\config.xml final rename failed. > FixTextLines processing complete. > > Can others reproduce this issue on Windows? > > > IzPack Installer does not set line endings to CRLF on windows and LF on > > non-Windows platforms > > - > > > > > > Key: GERONIMO-1287 > > URL: http://issues.apache.org/jira/browse/GERONIMO-1287 > > Project: Geronimo > > Type: Bug > > Components: installer > > Versions: 1.0-M5, 1.0-M4, 1.0 > > Reporter: John Sisson > > Fix For: 1.1, 1.0.1 > > Attachments: installer-fix-crlf.patch > > > > Currently we build one IzPack installer that is used on Windows and > > non-Windows platforms. IzPack does not provide any fixcrlf type > > functionality when copying files from its packs to the install location. > > IzPack needs to be enhanced to be able to do this "easily". -- Regards, Erik
[jira] Updated: (GERONIMO-1554) Installer - Move advanced features to non-default installer path (simplify default installation)
[ http://issues.apache.org/jira/browse/GERONIMO-1554?page=all ] erik daughtrey updated GERONIMO-1554: - Attachment: installer-separate-advanced-features.patch.gz This patch is for trunk and branches/1.0. The patch simplifies the default path through the installer and changes the default path so that either Jetty or Tomcat may be installed, but not both. An advanced path may be enabled using -Dadvancedmode=true which enables the ability to install both containers and selectively disable installed configurations using checkboxes. > Installer - Move advanced features to non-default installer path (simplify > default installation) > > > Key: GERONIMO-1554 > URL: http://issues.apache.org/jira/browse/GERONIMO-1554 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-separate-advanced-features.patch.gz > > Installer is too complex for new users. > Simplify default path and disable advanced features or move > them to a non-default path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1554) Installer - Move advanced features to non-default installer path (simplify default installation)
[ http://issues.apache.org/jira/browse/GERONIMO-1554?page=all ] erik daughtrey updated GERONIMO-1554: - Geronimo Info: [Patch Available] > Installer - Move advanced features to non-default installer path (simplify > default installation) > > > Key: GERONIMO-1554 > URL: http://issues.apache.org/jira/browse/GERONIMO-1554 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > > Installer is too complex for new users. > Simplify default path and disable advanced features or move > them to a non-default path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1554) Installer - Move advanced features to non-default installer path (simplify default installation)
Installer - Move advanced features to non-default installer path (simplify default installation) Key: GERONIMO-1554 URL: http://issues.apache.org/jira/browse/GERONIMO-1554 Project: Geronimo Type: Improvement Components: installer Versions: 1.0.1, 1.1 Reporter: erik daughtrey Installer is too complex for new users. Simplify default path and disable advanced features or move them to a non-default path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: v1.x Installer comments - Long
David, Thank you. The installer now has two modes. The default mode removes the advanced features which allow overriding of the config.xml load variables and defaults the values to true for the packs selected. In this mode, the operator must select either Jetty or Tomcat for install and cannot install both. If -Dadvancedmode=true is specified on the command line, then it is possible to install both web containers, but only one may be active at runtime. Additionally, the various components can be set to load=false as desired. The program enforces the dependencies. It's not possible to enable CORBA if J2EE features are not enabled. We can choose not to document this. Sorry if this situation has folks rattled. I'm not rattled about this, nor at anyone. Apologies if anyone thinks so. I'll be posting a patch after I do some more testing. Thanks. note: the property is not case sensitive. Regards, erik On Friday 27 January 2006 12:49, David Jencks wrote: > I'm afraid that there is a temptation we might be succumbing to to > gold plate the installer since only eric is actually doing the > work.We can easily turn the installer into a permanent full time > job for as many people as we can get to work on it. > > Working on the installer is no fun IMNSHO based on my experience. I > want this part of the project to end really soon so eric can do > something a bit more fun. > > My point of view about the function of the installer is that it is > the primary means we can show the component oriented nature of > geronimo and let people build their own server. It is considerably > harder to set up geronimo using the installer than to unpack one of > the prebuilt servers, and nothing we can do can change that. > > I want the installer to show that you can build a lot of different > servers out of the configurations we supply. This means to me that > it should include exactly the parts you specify and that the > configuration options for those parts you specify should be able to > be set in the installer. One of those configuration options is very > definitely whether the configuration is started, so IMO it should be > shown in the installer. > > My preference would be to fix the icons, make the changes so only the > jars for the configs you select are installed, and declare victory. > > If we want more, I would prefer to insert warnings rather than > disable functionality. For instance, put a divider in between the > ports etc and the check boxes for activating the configs that says > "ADVANCED FUNCTIONALITY KEEP OUT" (obviously bad wording) and perhaps > a warning page if you select 2 web containers "YOU PROBABLY DON"T > WANT TO DO THAT". > > That's more than enough of a rant. To me the only critical missing > piece in the installer is including only the needed jars. > > thanks > david jencks > > On Jan 27, 2006, at 8:22 AM, Dave Colasurdo wrote: > > David Jencks wrote: > >> On Jan 27, 2006, at 5:54 AM, Erik Daughtrey wrote: > >>> Given the comments I've gotten, I'm going to change the installer > >>> and go back > >>> to the behavior where it does not allow the selection of both web > >>> container > >>> packs to install. I'm going to ditch the additional buttons which > >>> allow > >>> selected features to be inactive at runtime. > >>> > >>> We could put this up for a vote, but since there have been very > >>> few comments > >>> on this topic, I assume that most folks just want an installer > >>> that works > >>> well. > >> > >> I pretty much strongly prefer the way the installer works now, I > >> think I asked for it to be this way :-) > >> I won't stand in anyones way though. > >> My view is that the installer should present all the options > >> reasonably available. They are MUCH easier to configure in the > >> installer than in any other way, and I think that the additional > >> confusion while using the installer is minimal. > > > > I think most folks agree that the vast majority of users will never > > want > > to run with two web containers installed. The exceptions that I can > > think of are: > > > > 1) Geronimo developers - who most likely won't ever use the installer > > > > 2) Novice users who aren't sure which web container to use and want to > > try them both out. Rather than confusing them with instructions on how > > to setup ports for simultaneous containers or instructions on how to > > switch between web containers (creating two separate config stores o
Re: v1.x Installer comments - Long
Yes, I remember :) regards, erik On Friday 27 January 2006 10:46, Aaron Mulder wrote: > I would prefer if we did not let a user install both web containers. :) > > I'd like to try out the installer soon. > > Thanks, > Aaron > > On 1/27/06, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > Ah, I knew that you'd asked for this, but I didn't realize that you had a > > strong conviction. I suppose I should've asked ;) > > > > I'll leave it alone for now and focus on cleaning up a few things left. > > > > It would be great if a few others could try the installer and provide > > some feedback quickly. > > > > Feedback is welcome. Thanks. > > > > regards, > > > > Erik > > > > On Friday 27 January 2006 10:19, David Jencks wrote: > > > On Jan 27, 2006, at 5:54 AM, Erik Daughtrey wrote: > > > > Given the comments I've gotten, I'm going to change the installer > > > > and go back > > > > to the behavior where it does not allow the selection of both web > > > > container > > > > packs to install. I'm going to ditch the additional buttons which > > > > allow > > > > selected features to be inactive at runtime. > > > > > > > > We could put this up for a vote, but since there have been very few > > > > comments > > > > on this topic, I assume that most folks just want an installer that > > > > works > > > > well. > > > > > > I pretty much strongly prefer the way the installer works now, I > > > think I asked for it to be this way :-) > > > > > > I won't stand in anyones way though. > > > > > > My view is that the installer should present all the options > > > reasonably available. They are MUCH easier to configure in the > > > installer than in any other way, and I think that the additional > > > confusion while using the installer is minimal. > > > > > > thanks > > > david jencks -- Regards, Erik
[jira] Updated: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] erik daughtrey updated GERONIMO-1544: - Geronimo Info: [Patch Available] Once these patches are applied, this issue can be closed. > Installer - Straighten out licensing issues for IzPack sub-components. > -- > > Key: GERONIMO-1544 > URL: http://issues.apache.org/jira/browse/GERONIMO-1544 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Priority: Critical > Attachments: installer-icon-license-fix.patch, installer-icons.tgz > > Although IzPack itself is licensed under the ASF 2.0 license, apparently, > some sub-components > of IzPack are licensed under GPL or LGPL which is incompatible with the > Apache Software Foundation licensing. > Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] erik daughtrey updated GERONIMO-1544: - Attachment: installer-icons.tgz These icons are basically renamed icons from Apache HTTP. The icons are in the public domain. Expand the tar in the base geronimo build directory. This creates: modules/installer-support/src/images/img/*.png A README file will be created by a follow-on patch in the same directory. The README will be placed into the jars with the PNGs at build time. > Installer - Straighten out licensing issues for IzPack sub-components. > -- > > Key: GERONIMO-1544 > URL: http://issues.apache.org/jira/browse/GERONIMO-1544 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Priority: Critical > Attachments: installer-icons.tgz > > Although IzPack itself is licensed under the ASF 2.0 license, apparently, > some sub-components > of IzPack are licensed under GPL or LGPL which is incompatible with the > Apache Software Foundation licensing. > Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] erik daughtrey updated GERONIMO-1544: - Attachment: installer-icon-license-fix.patch Both the icons.tgz previously uploaded and this patch apply to both trunk and branches/1.0. Install the tar first, then the patch. This patch changes modules/installer-support/maven.xml so that it injects the icons into the appropriate places within the generated JARs. Additionally, the patch changes the IzPack XML so that fewer icons are used and disables the look and feel extensions. These patches resolve this issue. The JGoodies "Looks" look and feel is licensed under the BSD license and could possibly be used. It has a good text format and provides a similar look and feel between both windows and unix. However, at this time, it is not used to avoid licensing issues. No look and feel jars/classes get copied to Geronimo jars. > Installer - Straighten out licensing issues for IzPack sub-components. > -- > > Key: GERONIMO-1544 > URL: http://issues.apache.org/jira/browse/GERONIMO-1544 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Priority: Critical > Attachments: installer-icon-license-fix.patch, installer-icons.tgz > > Although IzPack itself is licensed under the ASF 2.0 license, apparently, > some sub-components > of IzPack are licensed under GPL or LGPL which is incompatible with the > Apache Software Foundation licensing. > Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: v1.x Installer comments - Long
Ah, I knew that you'd asked for this, but I didn't realize that you had a strong conviction. I suppose I should've asked ;) I'll leave it alone for now and focus on cleaning up a few things left. It would be great if a few others could try the installer and provide some feedback quickly. Feedback is welcome. Thanks. regards, Erik On Friday 27 January 2006 10:19, David Jencks wrote: > On Jan 27, 2006, at 5:54 AM, Erik Daughtrey wrote: > > Given the comments I've gotten, I'm going to change the installer > > and go back > > to the behavior where it does not allow the selection of both web > > container > > packs to install. I'm going to ditch the additional buttons which > > allow > > selected features to be inactive at runtime. > > > > We could put this up for a vote, but since there have been very few > > comments > > on this topic, I assume that most folks just want an installer that > > works > > well. > > I pretty much strongly prefer the way the installer works now, I > think I asked for it to be this way :-) > > I won't stand in anyones way though. > > My view is that the installer should present all the options > reasonably available. They are MUCH easier to configure in the > installer than in any other way, and I think that the additional > confusion while using the installer is minimal. > > thanks > david jencks >
Re: Roadmap, tasks and things to do?
Dain, Uh, what I meant to say was: I'd also like to see a list of tasks and roadmap. It would be great if the set of tasks and topics could be broken down into major areas such that it's easy to see what tasks are necessary for spec compliance as opposed to general Geronimo functionality related to non-spec compliance. regards, erik On Thursday 26 January 2006 17:18, Dain Sundstrom wrote: > Ever since we shipped 1.0, I have been getting a surprising number of > private emails from old fiends, old Geronimo contributers, companies, > and just random people telling me that the are excited about Geronimo > and want to join in. They all inevitably ask me for advise on what > to work on, and I really have no idea other than "look at JIRA". So > I'd like to solicit the community to help me create a roadmap, tasks, > things to do list, what ever we call it. > > Before we get into building this, I'd like to focus the discussion, > so we don't end up in mailing-list fantasy land :) Lets agree to not > talk about the technology used to track the tasks; once we have the > content we can discuss using JIRA, wiki, html or creating a Gopher > site. Secondly, lets focus on things that are reasonable to do in > the next 9 months. Finally, don't worry about someone else working > on something you want to work on. With open communication on the > mailing list, I think everyone will be able to work something they > find interesting without stepping on toes. Oh, one final thing, > please don't try to "take a task" until we have this list complete. > > Without further delay, here are some things off the top of my head: > > o Conversion to Maven 2 - Very important and a huge task > > o Ant versions of the Geronimo plugins > > o XDoclet for all configurations > > o Integration tests that cover servlets, webservices and jms > > o Little-G - Geronimo with a small foot print > > o Global non-persistent JNDI implementation > > o EJB 2.x - Once I get my refractor committed, it will be obvious > where the 2.x implementation needs work like better caching > > o JEE 5 - There is a ton of stuff under this, but it would be good to > start with a list of what is required for JEE 5 > > > > I don't want to speak for the other ares of Geronimo I don't work on > regularly, but I am sure that there are good opportunities to help in > the console, jms, javamail, ejb, clustering, esb/jbi/bpm, tooling, > performance, build, testing, samples, documentation, so if you are > more familiar with one of those areas, please post. > > I think this is a "once in a project chance" to build a big vibrant > community of developers, and let's not let it pass us by. > > Thanks in advance, > > -dain -- Regards, Erik
Re: v1.x Installer comments - Long
Given the comments I've gotten, I'm going to change the installer and go back to the behavior where it does not allow the selection of both web container packs to install. I'm going to ditch the additional buttons which allow selected features to be inactive at runtime. We could put this up for a vote, but since there have been very few comments on this topic, I assume that most folks just want an installer that works well. regards, erik On Wednesday 25 January 2006 21:53, Matt Hogstrom wrote: > David Jencks wrote: > > On Jan 25, 2006, at 2:48 PM, Joe Bohn wrote: > >> I agree with Dave on the issue of multiple containers. We had many > >> discussions on this list concerning the number of containers in an > >> image. The result was that we agreed to deliver 2 different > >> assemblies rather than having multiple containers in one assembly. > >> If that was the decision for the assemblies then I would think it > >> makes sense to do the same in the installer. > > +1 One container per instance will satisfy 99% of the users I suspect. > > >> I also agree with Dave that we should revisit the issue of presenting > >> the list of components twice: once to include them in the image and > >> once to activate them in the runtime. I doubt that most users would > >> understand this distinction when initially installing Geronimo. Most > >> other packages consider the activation/ inactivation of components to > >> be post-install setup and choose the defaults that make the most > >> sense. In our case I would expect that all components selected > >> during install would be active by default. > > > > I think that is what we have now. I don't see why we shouldn't let > > people turn them off if they want to. > > I think for now we should dump them all to disk and then allow them to > assemble the user. I don't think were sophisticated enough yet to help > users understand the difference. One can refer to them as options > available for later configuration (disk bloat) and options for runtime > configuration (memory bloat). I'd leave it simple for now. > > > david jencks > > > >> Joe > >> > >> Dave Colasurdo wrote: > >>> Erik Daughtrey wrote: > >>>> Dave, Thanks for the comments... > >>>> > >>>> I made comments below. Would you create installer component JIRAs > >>>> for the items that make sense? > >>> > >>> Yep. BTW, has it been decided if the installer is a 1.0.1 or 1.1 > >>> item? > >>> > >>>> On Thursday 19 January 2006 17:02, Dave Colasurdo wrote: > >>>>> Looks like the Installer has made quite a bit of progress. Thanks > >>>>> Erik!! > >>>>> > >>>>> I'd like to suggest a few Usabality changes to the current > >>>>> installer.. > >>>>> I'm sure you are already aware of many of these and have plans to > >>>>> update > >>>>> them. Just wanted to provide some input based on my first > >>>>> impression. > >>>>> BTW, I've attempted to provide input based on my thoughts on how > >>>>> this would be perceived from the perspective of a first time user. > >>>>> > >>>>> *Package Selection Panel* > >>>>> 1)The available selections are really a hierarchy > >>>>> -Server > >>>>> --J2EE Features > >>>>> ---Jetty Web Container > >>>>> Jetty Sample Applications > >>>>> > >>>>> ---Tomcat Web Container > >>>>> Tomcat Sample Applications > >>>>> > >>>>> > >>>>> Does Izpack allow you to capture the hierarchy graphically? > >>>> > >>>> Not that I've seen. It looks like it's strictly a list box. > >>>> > >>>>> If not, anyway to insert padding to the front of entries to show the > >>>>> hierarchy to the user? I think this would be a better solution > >>>>> than the > >>>> > >>>> Inserting spaces is something worth trying. > >>> > >>> I experimented with inserting spaces in front of the pack names and it > >>> seemed to work fine. As expected, this also requires that all > >>> references > >>> to the pack name in geronimo-izpack.xml, izpack-process.xml and >
Re: Roadmap, tasks and things to do?
Once I'm finished with this infernal installer, I'm working on web services -- period -- unless someone stops me. BTW, do I have any f'ing karma yet? Sorry, bad day. regards, erik On Thursday 26 January 2006 17:18, Dain Sundstrom wrote: > Ever since we shipped 1.0, I have been getting a surprising number of > private emails from old fiends, old Geronimo contributers, companies, > and just random people telling me that the are excited about Geronimo > and want to join in. They all inevitably ask me for advise on what > to work on, and I really have no idea other than "look at JIRA". So > I'd like to solicit the community to help me create a roadmap, tasks, > things to do list, what ever we call it. > > Before we get into building this, I'd like to focus the discussion, > so we don't end up in mailing-list fantasy land :) Lets agree to not > talk about the technology used to track the tasks; once we have the > content we can discuss using JIRA, wiki, html or creating a Gopher > site. Secondly, lets focus on things that are reasonable to do in > the next 9 months. Finally, don't worry about someone else working > on something you want to work on. With open communication on the > mailing list, I think everyone will be able to work something they > find interesting without stepping on toes. Oh, one final thing, > please don't try to "take a task" until we have this list complete. > > Without further delay, here are some things off the top of my head: > > o Conversion to Maven 2 - Very important and a huge task > > o Ant versions of the Geronimo plugins > > o XDoclet for all configurations > > o Integration tests that cover servlets, webservices and jms > > o Little-G - Geronimo with a small foot print > > o Global non-persistent JNDI implementation > > o EJB 2.x - Once I get my refractor committed, it will be obvious > where the 2.x implementation needs work like better caching > > o JEE 5 - There is a ton of stuff under this, but it would be good to > start with a list of what is required for JEE 5 > > > > I don't want to speak for the other ares of Geronimo I don't work on > regularly, but I am sure that there are good opportunities to help in > the console, jms, javamail, ejb, clustering, esb/jbi/bpm, tooling, > performance, build, testing, samples, documentation, so if you are > more familiar with one of those areas, please post. > > I think this is a "once in a project chance" to build a big vibrant > community of developers, and let's not let it pass us by. > > Thanks in advance, > > -dain -- Regards, Erik
Re: Licensing of some files included in the Geronimo IzPack installer assembly (included by the IzPack installer)
Thanks for looking into this. I've created JIRA 1544 to address the issue and believe that I have a work-around. Regards, erik On Wednesday 25 January 2006 18:44, John Sisson wrote: > Hi Erik, > > There appears there are some issues with the licensing of some files in > the installer JAR file for the upcoming Geronimo 1.0.1 release. > > Although the IzPack installer itself is supposed to be under an ASF 2 > license, it appears that the generated Geronimo installer JAR contains > some files that may not be under the ASF 2 license or compatible with > the ASF 2 license. > > There are two groups of files/libraries that are included that are > potentially suspect: > > 1) A number of images are included in the installer JAR in the /img > directory. The IzPack installer history page ( > http://www.izforge.com/izpack/index.php?page=history ) says that the > 3.5.0 version switched to the Crystal icons from KDE 3.2. I found that > some of the images in the installer jar binary match images (e.g. > ascii.png and bookmark.png) from "Crystal SVG for Linux" download on > http://www.everaldo.com/crystal.html . Some images also looked the same > but differed in a binary comparison (maybe I am comparing a different > version of the icons). A google of crystal icons reveals (from various > discussions) that they are under a LGPL license. So the use of the > icons is not suitable in ASF projects. > > This issue should probably be raised with the IzPack project. It may > take a while for the IzPack project or ourselves to obtain images from > another source that are suitable replacements. > > 2) Liquid look and feel files under the package com\birosoft\liquid . > The liquidlnf project's page displays a LGPL license ( > https://liquidlnf.dev.java.net/ ). > Removing the following lines from the geronimo-izpack.xml file prevented > the liquid files being included. > > >Therefore the liquid LGPL issue appears to be solvable. > > The removal of the laf configuration the geronimo-izpack.xml file does > not affect the images that are in the jar under the /img directory. > > > FYI: Henry Yandell confirmed that the NanoXML files in the installer JAR > under the package net\n3\nanoxml under a zlib/libpng License are > compatible with the ASF 2 license. ( > http://nanoxml.cyberelf.be/download.html ). > > Regards, > > John -- Regards, Erik
Re: Licensing of some files included in the Geronimo IzPack installer assembly (included by the IzPack installer)
I created JIRA 1544 to address the issue. I've grabbed the apache web server icons and am mapping them to IzPack's. There are 32 icons in the /img directory of the output jar. I've verified that if I replace them that the new ones will appear properly. I have not done too much mapping yet, but it looks promising. The icon selection isn't all that good, but at least we're really not using the whole set of 32 anyway. I will replace them all or delete the ones not used. There's a look and feel called JGoodies Looks which is BSD licensed that looks preferable over the default, so unless there's some objection, I'll set the LAF to "Looks". Regards, erik On Wednesday 25 January 2006 21:47, Matt Hogstrom wrote: > Great research John. Do you think we should defer the installer to 1.1 > given these issues? It would certainly make a bigger splash I think. > Erik, thoughts? > > Matt > > John Sisson wrote: > > Hi Erik, > > > > There appears there are some issues with the licensing of some files in > > the installer JAR file for the upcoming Geronimo 1.0.1 release. > > > > Although the IzPack installer itself is supposed to be under an ASF 2 > > license, it appears that the generated Geronimo installer JAR contains > > some files that may not be under the ASF 2 license or compatible with > > the ASF 2 license. > > > > There are two groups of files/libraries that are included that are > > potentially suspect: > > > > 1) A number of images are included in the installer JAR in the /img > > directory. The IzPack installer history page ( > > http://www.izforge.com/izpack/index.php?page=history ) says that the > > 3.5.0 version switched to the Crystal icons from KDE 3.2. I found that > > some of the images in the installer jar binary match images (e.g. > > ascii.png and bookmark.png) from "Crystal SVG for Linux" download on > > http://www.everaldo.com/crystal.html . Some images also looked the same > > but differed in a binary comparison (maybe I am comparing a different > > version of the icons). A google of crystal icons reveals (from various > > discussions) that they are under a LGPL license. So the use of the > > icons is not suitable in ASF projects. > > > > This issue should probably be raised with the IzPack project. It may > > take a while for the IzPack project or ourselves to obtain images from > > another source that are suitable replacements. > > > > 2) Liquid look and feel files under the package com\birosoft\liquid . > > The liquidlnf project's page displays a LGPL license ( > > https://liquidlnf.dev.java.net/ ). > > Removing the following lines from the geronimo-izpack.xml file prevented > > the liquid files being included. > > > > > > Therefore the liquid LGPL issue appears to be solvable. > > > > The removal of the laf configuration the geronimo-izpack.xml file does > > not affect the images that are in the jar under the /img directory. > > > > > > FYI: Henry Yandell confirmed that the NanoXML files in the installer JAR > > under the package net\n3\nanoxml under a zlib/libpng License are > > compatible with the ASF 2 license. ( > > http://nanoxml.cyberelf.be/download.html ). > > > > Regards, > > > > John -- Regards, Erik
[jira] Updated: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=all ] erik daughtrey updated GERONIMO-1544: - Priority: Critical (was: Blocker) > Installer - Straighten out licensing issues for IzPack sub-components. > -- > > Key: GERONIMO-1544 > URL: http://issues.apache.org/jira/browse/GERONIMO-1544 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Priority: Critical > > Although IzPack itself is licensed under the ASF 2.0 license, apparently, > some sub-components > of IzPack are licensed under GPL or LGPL which is incompatible with the > Apache Software Foundation licensing. > Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
[ http://issues.apache.org/jira/browse/GERONIMO-1544?page=comments#action_12364094 ] erik daughtrey commented on GERONIMO-1544: -- I have verified that the Crystal icons can be replaced by injecting new icons into /img in the output jar file. I have found new icons in the apache web server which I'll map to their equivalent in the installer, check them into svn (via a patch) and change the izpack plugin to inject these icons. As to the use of a look and feel, I'd prefer to override the LAF with JGoodies "Looks" which is BSD licensed. If this is not appropriate, then we can just not override the LAF. I believe this will get us over this hurdle. > Installer - Straighten out licensing issues for IzPack sub-components. > -- > > Key: GERONIMO-1544 > URL: http://issues.apache.org/jira/browse/GERONIMO-1544 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0.1 > Reporter: erik daughtrey > Priority: Blocker > > Although IzPack itself is licensed under the ASF 2.0 license, apparently, > some sub-components > of IzPack are licensed under GPL or LGPL which is incompatible with the > Apache Software Foundation licensing. > Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1544) Installer - Straighten out licensing issues for IzPack sub-components.
Installer - Straighten out licensing issues for IzPack sub-components. -- Key: GERONIMO-1544 URL: http://issues.apache.org/jira/browse/GERONIMO-1544 Project: Geronimo Type: Task Components: installer Versions: 1.0.1 Reporter: erik daughtrey Priority: Blocker Although IzPack itself is licensed under the ASF 2.0 license, apparently, some sub-components of IzPack are licensed under GPL or LGPL which is incompatible with the Apache Software Foundation licensing. Iron out the issues ASAP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1537) Installer - IzPack assembly does not qualify plugin version for code copied to installer assembly for use at install time
[ http://issues.apache.org/jira/browse/GERONIMO-1537?page=all ] erik daughtrey updated GERONIMO-1537: - Attachment: installer-qualify-config-code-version.patch Should be applied to both branches/1.0 and trunk > Installer - IzPack assembly does not qualify plugin version for code copied > to installer assembly for use at install time > - > > Key: GERONIMO-1537 > URL: http://issues.apache.org/jira/browse/GERONIMO-1537 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-qualify-config-code-version.patch > > The installer uses the geronimo-assembly-plugin java code at install time to > install the configurations. > Currently all plugin jars are incorrectly copied to the installer which may > lead to incorrect behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1537) Installer - IzPack assembly does not qualify plugin version for code copied to installer assembly for use at install time
Installer - IzPack assembly does not qualify plugin version for code copied to installer assembly for use at install time - Key: GERONIMO-1537 URL: http://issues.apache.org/jira/browse/GERONIMO-1537 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey The installer uses the geronimo-assembly-plugin java code at install time to install the configurations. Currently all plugin jars are incorrectly copied to the installer which may lead to incorrect behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1536) Installer - j2ee-installer assembly project.xml fix
[ http://issues.apache.org/jira/browse/GERONIMO-1536?page=all ]
erik daughtrey updated GERONIMO-1536:
-
Attachment: installer-fix-project-var.patch
This patch should be applied to both branches/1.0 and trunk.
> Installer - j2ee-installer assembly project.xml fix
> ---
>
> Key: GERONIMO-1536
> URL: http://issues.apache.org/jira/browse/GERONIMO-1536
> Project: Geronimo
> Type: Bug
> Components: installer
> Versions: 1.0.1, 1.1
> Reporter: erik daughtrey
> Attachments: installer-fix-project-var.patch
>
> Project XML incorrectly refers to ${Sample.Database.Pool} variable rather
> than ${J2EE.Features} pack variable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1536) Installer - j2ee-installer assembly project.xml fix
Installer - j2ee-installer assembly project.xml fix
---
Key: GERONIMO-1536
URL: http://issues.apache.org/jira/browse/GERONIMO-1536
Project: Geronimo
Type: Bug
Components: installer
Versions: 1.0.1, 1.1
Reporter: erik daughtrey
Project XML incorrectly refers to ${Sample.Database.Pool} variable rather
than ${J2EE.Features} pack variable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1287) IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms
[ http://issues.apache.org/jira/browse/GERONIMO-1287?page=all ] erik daughtrey updated GERONIMO-1287: - Geronimo Info: [Patch Available] This patch is applicable to trunk and branches/1.0. We should ensure that this is available for 1.0.1. > IzPack Installer does not set line endings to CRLF on windows and LF on > non-Windows platforms > - > > Key: GERONIMO-1287 > URL: http://issues.apache.org/jira/browse/GERONIMO-1287 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0-M5, 1.0-M4, 1.0 > Reporter: John Sisson > Fix For: 1.1 > Attachments: installer-fix-crlf.patch > > Currently we build one IzPack installer that is used on Windows and > non-Windows platforms. IzPack does not provide any fixcrlf type > functionality when copying files from its packs to the install location. > IzPack needs to be enhanced to be able to do this "easily". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1287) IzPack Installer does not set line endings to CRLF on windows and LF on non-Windows platforms
[ http://issues.apache.org/jira/browse/GERONIMO-1287?page=all ] erik daughtrey updated GERONIMO-1287: - Attachment: installer-fix-crlf.patch This patch adds a main (FixTextLines) which runs during IzPack processing after the files are laid down to ensure that text file line terminators are correct. > IzPack Installer does not set line endings to CRLF on windows and LF on > non-Windows platforms > - > > Key: GERONIMO-1287 > URL: http://issues.apache.org/jira/browse/GERONIMO-1287 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0-M5, 1.0-M4, 1.0 > Reporter: John Sisson > Fix For: 1.1 > Attachments: installer-fix-crlf.patch > > Currently we build one IzPack installer that is used on Windows and > non-Windows platforms. IzPack does not provide any fixcrlf type > functionality when copying files from its packs to the install location. > IzPack needs to be enhanced to be able to do this "easily". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=all ] erik daughtrey updated GERONIMO-1517: - Geronimo Info: [Patch Available] > Installer - Install Derby with base J2EE Features > - > > Key: GERONIMO-1517 > URL: http://issues.apache.org/jira/browse/GERONIMO-1517 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-derby-as-j2ee-feature.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
[ http://issues.apache.org/jira/browse/GERONIMO-1517?page=all ] erik daughtrey updated GERONIMO-1517: - Attachment: installer-derby-as-j2ee-feature.patch Apply this fix to both trunk and branches/1.0. > Installer - Install Derby with base J2EE Features > - > > Key: GERONIMO-1517 > URL: http://issues.apache.org/jira/browse/GERONIMO-1517 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.1, 1.0.1 > Reporter: erik daughtrey > Attachments: installer-derby-as-j2ee-feature.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1514) Fix installer license statements
[ http://issues.apache.org/jira/browse/GERONIMO-1514?page=all ] erik daughtrey updated GERONIMO-1514: - Attachment: installer-license-text-fix.patch This patch fixes the installer license statements. The patch should be applied to both branches/1.0 and trunk. Thanks. > Fix installer license statements > > > Key: GERONIMO-1514 > URL: http://issues.apache.org/jira/browse/GERONIMO-1514 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0 > Reporter: erik daughtrey > Attachments: installer-license-text-fix.patch > > They need to be fixed for both branches/1,0 and trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1514) Fix installer license statements
[ http://issues.apache.org/jira/browse/GERONIMO-1514?page=all ] erik daughtrey updated GERONIMO-1514: - Geronimo Info: [Patch Available] > Fix installer license statements > > > Key: GERONIMO-1514 > URL: http://issues.apache.org/jira/browse/GERONIMO-1514 > Project: Geronimo > Type: Task > Components: installer > Versions: 1.0 > Reporter: erik daughtrey > > They need to be fixed for both branches/1,0 and trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1517) Installer - Install Derby with base J2EE Features
Installer - Install Derby with base J2EE Features - Key: GERONIMO-1517 URL: http://issues.apache.org/jira/browse/GERONIMO-1517 Project: Geronimo Type: Bug Components: installer Versions: 1.1, 1.0.1 Reporter: erik daughtrey -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
Installer - only copy jars needed by selected configuration --- Key: GERONIMO-1518 URL: http://issues.apache.org/jira/browse/GERONIMO-1518 Project: Geronimo Type: Improvement Components: installer Versions: 1.1 Reporter: erik daughtrey -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1516) Installer - add new components to install: openejb, openejb-builder, axis and axis-builder
Installer - add new components to install: openejb, openejb-builder, axis and axis-builder -- Key: GERONIMO-1516 URL: http://issues.apache.org/jira/browse/GERONIMO-1516 Project: Geronimo Type: Task Components: installer Versions: 1.1 Reporter: erik daughtrey New configurations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1515) Installer - some GBeans do not start correctly after install
Installer - some GBeans do not start correctly after install Key: GERONIMO-1515 URL: http://issues.apache.org/jira/browse/GERONIMO-1515 Project: Geronimo Type: Bug Components: installer Versions: 1.1 Reporter: erik daughtrey This seems to be happening in trunk and not on branches/1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1514) Fix installer license statements
Fix installer license statements Key: GERONIMO-1514 URL: http://issues.apache.org/jira/browse/GERONIMO-1514 Project: Geronimo Type: Task Components: installer Versions: 1.0 Reporter: erik daughtrey They need to be fixed for both branches/1,0 and trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: v1.x Installer comments - Long
Dave, Thanks for the comments... I made comments below. Would you create installer component JIRAs for the items that make sense? On Thursday 19 January 2006 17:02, Dave Colasurdo wrote: > Looks like the Installer has made quite a bit of progress. Thanks Erik!! > > I'd like to suggest a few Usabality changes to the current installer.. > I'm sure you are already aware of many of these and have plans to update > them. Just wanted to provide some input based on my first impression. > BTW, I've attempted to provide input based on my thoughts on how this > would be perceived from the perspective of a first time user. > > *Package Selection Panel* > 1)The available selections are really a hierarchy > -Server > --J2EE Features > ---Jetty Web Container > Jetty Sample Applications > > ---Tomcat Web Container > Tomcat Sample Applications > > > Does Izpack allow you to capture the hierarchy graphically? Not that I've seen. It looks like it's strictly a list box. > If not, anyway to insert padding to the front of entries to show the > hierarchy to the user? I think this would be a better solution than the Inserting spaces is something worth trying. > "Dependencies" box and would more clearly convey the relationship > between selections. Also, we should remove the dependencies box and the I don't think it's possible to remove the dependencies box and keep the overall look and feel. > other righthand box that contains the Logo. The description box should I agree that the 2nd graphic is redundant at this point. However, one thing we have not explored is the fact that the graphic on the right is actually different for each pack although for now each is a distinct instance of the same bitmap. There is the potential to enhance each bitmap - possibly by making the Geronimo image subdued while overlaying something related to the pack. I have not tried removing the graphic, but I don't think it's possible to remove it and keep this look and feel. > be located directly to the right of the main selection box OR below it > on the left. I doubt that this is easy to change. We can look into making some of these changes in more detail at some point. Anything is actually possible depending on the capabilities of IzPack itself and how much we're willing to diverge the Geronimo installer from the IzPack codebase. It may actually be possible to make some of the changes without changing IzPack, but based on what I know right now, I don't think so. We've already diverged from the IzPack codebase and we need to factor these changes into IzPack as we move forward or we may run into problems related to these changes later as IzPack itself diverges. I'm struggling a little with this at this point given that IzPack is a generalized installer and some of the changes made are specific to Geronimo. I tried to keep the changes separated, but our requirements are reflected in code I wanted to keep generalized anyway. I don't want to boil the ocean, but I'd also like to minimize problems occurring from the two distinct dev paths as much as possible. Graphical look and feel changes might be less painful to push back into IzPack, but it's still a little worrisome. > > I like the way the dependant boxes interact (turning off something at > the top of the hierarchy automatically trickles down to the dependant > choices).. > > 2) It seems that we are allowing the user to choose two web containers? > I thought we would limit the choice to just one? The operator can install both containers, but they cannot activate both at runtime. > > 3) It seems that it is currently possible to pick-and-choose selections > that result in a server that won't start. We need to decide which > choices are valid and assure that the resulting installations all work. >Flexibility is great, but we don't want to give users the ability to > choose non-working installations. The intent is to prevent the building of a non-working server. There's only one instance I'm aware of that will result in problems and it will be fixed soon. If daytrader is selected, with no database, then obviously there will be problems. David Jencks has suggested that we just go ahead and install Derby when the J2EE Features are selected -- and I plan to do this. If you're aware of other instances please enumerate them... > > 4) The available disk space seems to only be specified for "Server". I > assume the other selections will eventually be updated. IzPack only displays this for packs which have files associated. This is one of the current issues about the installer. It installs everything. This will be addressed. > > 5) Should the "Server" selection be re-labeled as Geronimo kernel or > Geronimo base infrastructure or something to better reflect what it is? > I don't have a real opinion on this. > 6) The "Greyed out packs are required" comment is somewhat confusing.. > Perhaps just adding the word (Required) next t
[jira] Updated: (GERONIMO-1505) Installer should default Tomcat on at runtime if Jetty pack is not selected
[ http://issues.apache.org/jira/browse/GERONIMO-1505?page=all ] erik daughtrey updated GERONIMO-1505: - Attachment: installer-tomcat-only-wc-config-fix.patch This patch is for both branches/1.0 and trunk. It's been tested against both. This fix selects Tomcat to run by default if Jetty is not selected to install. > Installer should default Tomcat on at runtime if Jetty pack is not selected > --- > > Key: GERONIMO-1505 > URL: http://issues.apache.org/jira/browse/GERONIMO-1505 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0 > Reporter: erik daughtrey > Attachments: installer-tomcat-only-wc-config-fix.patch > > When both Jetty and Tomcat are selected for install, the installer will > default Jetty to active > at runtime and Tomcat as off by default. > If Jetty is not selected for install and Tomcat is, then Tomcat should > default to active > at runtime. Currently it does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1505) Installer should default Tomcat on at runtime if Jetty pack is not selected
Installer should default Tomcat on at runtime if Jetty pack is not selected --- Key: GERONIMO-1505 URL: http://issues.apache.org/jira/browse/GERONIMO-1505 Project: Geronimo Type: Bug Components: installer Versions: 1.0 Reporter: erik daughtrey When both Jetty and Tomcat are selected for install, the installer will default Jetty to active at runtime and Tomcat as off by default. If Jetty is not selected for install and Tomcat is, then Tomcat should default to active at runtime. Currently it does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1502) Installer does not install docs on 1.0.1
[ http://issues.apache.org/jira/browse/GERONIMO-1502?page=all ] erik daughtrey updated GERONIMO-1502: - Attachment: installer-1.0.1-docs.patch This patch just uncomments docs install that was commented out for trunk patch because trunk docs are unavailable to installer. > Installer does not install docs on 1.0.1 > > > Key: GERONIMO-1502 > URL: http://issues.apache.org/jira/browse/GERONIMO-1502 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0 > Reporter: erik daughtrey > Attachments: installer-1.0.1-docs.patch > > Disabled docs install for trunk checkin. However, it should be re-enabled for > 1.0.1 (branches/1.0). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1502) Installer does not install docs on 1.0.1
Installer does not install docs on 1.0.1 - Key: GERONIMO-1502 URL: http://issues.apache.org/jira/browse/GERONIMO-1502 Project: Geronimo Type: Bug Components: installer Versions: 1.0 Reporter: erik daughtrey Disabled docs install for trunk checkin. However, it should be re-enabled for 1.0.1 (branches/1.0). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1495) Installer build failure when using Maven 1.0.2
[ http://issues.apache.org/jira/browse/GERONIMO-1495?page=comments#action_12363201 ] erik daughtrey commented on GERONIMO-1495: -- The patch has been tested against trunk and branches/1.0. It should be applied to both. > Installer build failure when using Maven 1.0.2 > -- > > Key: GERONIMO-1495 > URL: http://issues.apache.org/jira/browse/GERONIMO-1495 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0 > Environment: any > Reporter: erik daughtrey > Attachments: installer-trunk-maven102-fix.patch > > Maven 1.0.2 embeds an older version of Jelly which doesn't understand append="true"> > Maven 1.1 beta 2 does not have this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1495) Installer build failure when using Maven 1.0.2
[ http://issues.apache.org/jira/browse/GERONIMO-1495?page=comments#action_12363200 ] erik daughtrey commented on GERONIMO-1495: -- This patch should be applied to both trunk and branches/1.0. it's been tested on both. > Installer build failure when using Maven 1.0.2 > -- > > Key: GERONIMO-1495 > URL: http://issues.apache.org/jira/browse/GERONIMO-1495 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0 > Environment: any > Reporter: erik daughtrey > Attachments: installer-trunk-maven102-fix.patch > > Maven 1.0.2 embeds an older version of Jelly which doesn't understand append="true"> > Maven 1.1 beta 2 does not have this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1495) Installer build failure when using Maven 1.0.2
[ http://issues.apache.org/jira/browse/GERONIMO-1495?page=all ] erik daughtrey updated GERONIMO-1495: - Attachment: installer-trunk-maven102-fix.patch This patch fixes the build and works with both Maven 1.0.2 and 1.1 beta 2. > Installer build failure when using Maven 1.0.2 > -- > > Key: GERONIMO-1495 > URL: http://issues.apache.org/jira/browse/GERONIMO-1495 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0 > Environment: any > Reporter: erik daughtrey > Attachments: installer-trunk-maven102-fix.patch > > Maven 1.0.2 embeds an older version of Jelly which doesn't understand append="true"> > Maven 1.1 beta 2 does not have this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1495) Installer build failure when using Maven 1.0.2
Installer build failure when using Maven 1.0.2 -- Key: GERONIMO-1495 URL: http://issues.apache.org/jira/browse/GERONIMO-1495 Project: Geronimo Type: Bug Components: installer Versions: 1.0 Environment: any Reporter: erik daughtrey Maven 1.0.2 embeds an older version of Jelly which doesn't understand Maven 1.1 beta 2 does not have this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1194) Installer should only install packs(features) selected at install time
[
http://issues.apache.org/jira/browse/GERONIMO-1194?page=comments#action_12362670
]
erik daughtrey commented on GERONIMO-1194:
--
Installer Dev Notes
* Built with IzPack ( http://izforge/izpack ), currently based on 3.8.0
* Added images based on work done by EPiC
* Extends IzPack UserInputPanel type: ValidatePackSelections
- modules/installer-support component
IzPack requires that any extensions be in the
standalone-compiler jar at the time of the
installer. The maven.xml of this project copies
the (izpack)standalone-compiler-3.8.0.jar from
the maven repo and injects the output of the
compile into a copy of the jar and stores it
in the local repo as
(geronimo)standalone-compiler-custom-3.8.0.jar.
The step which builds the installer
(plugins/geronimo-izpack-plugin) has a
dependency on this new jar. The assembly step
assemblies/j2ee-installer has a dependency on
the plugin.
- added intra-panel port validation
Up to 7 port port conflicts are reported
on the "Configuation Checkpoint" panel.
The limit is imposed by real estate limiateions.
- added fixes for IzPack auto-install xml processing
(need to check 3.8.1 for possible fixes)
The problem was that the default processing
provided by IzPack caused the embedded xml for
each panel to be duplicated each time the panel
is exited. This was easy to fix for
ValidatePackSelections, but required a work-around
for the pack selection screen since we don't want
to change that portion of IzPack. To fix the
pack selection xml the code detects exit from
the last panel and gets hold of the ImgPacksPanel
xml and a reference to the ImgPacksPanel panel
itself via the global InstallData. The code
deletes all the dependent (duplicated) xml
and calls the ImgPacksPanel to generate new xml.
- extended use of JCheckBox (VCheckBox)
Added dependency checking for config.xml elements,
i.e. can't select Jetty web container if
J2EE features is selected. Note that pack (feature)
selections already work this way, but this adds
the capability to correctly enable/disable config.xml
runtime features based on what's installed.
- Fixed IzPack *feature* of adding/removing
checkboxes from panel based on whether the pack
is selected.
Add/remove caused the checkboxes to walk off the screen
when the related pack is selected/deselected/selected.
The change simply makes unselected pack related fields
invisible and vice-versa.
- Added support for a "configuration complete" panel
to display list of port conflicts to repair or "success".
The forward button is disabled when conflicts exist. The
operator is expected to fix any port conflicts before
continuing.
* Added plugin for izpack to build the installer
- plugins/geronimo-izpack-plugin builds the installer.
Assemblies/j2ee-installer uses the
plugins/geronimo-assembly-plugin to create the
install image which IzPack embeds into the installer
jar.
* IzPack variables
- Throughout the install, IzPack variables are
updated which may be used by IzPack to replace
values in "parsable" files (geronimio-izpack.xml).
Config.xml and configure.xml include variables
to be replaced by IzPack after the install image
is created. Extension code creates variables
for each pack, e.g. ${J2EE.Features}, which are
set according to whether the pack is selected
or not.
- izpack-user-input.xml creates variables like the
pack variables, but named like
${J2EE.Features.enable}. These variables are
set/reset by the VCheckBoxes based on whether
each feature is to be enabled at runtime
(config.xml).
- The pack variables are used in the project.xml of
assemblies/j2ee-installer (see config-store
handling below) to map configuration archives
to packs.
* Config-store handling
- Built module (modules/installer-processing) in
org.apache.geronimo.installer.processing called
ConfigInstaller which builds the config store after
the install image is laid down by the installer.
ConfigInstaller.java reads
${INSTALL_PATH}/var/config/configure.xml
to determine which configuration archive (CAR) files
should be installed into the configuration.
- Configure.xml is created by
plugins/
[jira] Updated: (GERONIMO-1194) Installer should only install packs(features) selected at install time
[ http://issues.apache.org/jira/browse/GERONIMO-1194?page=all ] erik daughtrey updated GERONIMO-1194: - Geronimo Info: [Patch Available] Version: 1.0 (was: 1.0-M5) > Installer should only install packs(features) selected at install time > -- > > Key: GERONIMO-1194 > URL: http://issues.apache.org/jira/browse/GERONIMO-1194 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0 > Environment: Maven, installer runtime > Reporter: erik daughtrey > Assignee: David Jencks > Fix For: 1.1 > Attachments: installer-ph2-trunk.patch.gz > > DJ: 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1194) Installer should only install packs(features) selected at install time
[ http://issues.apache.org/jira/browse/GERONIMO-1194?page=all ] erik daughtrey updated GERONIMO-1194: - Attachment: installer-ph2-trunk.patch.gz This patch includes all the features of the last patch posted to GERONIMO-1192 as well as: patch is for trunk. 1. Fixes/work-arounds for IzPack autoinstall xml handling bug 2. config-store update by installer based on pack selections by operator -- config-store is created at install time rather than assembly time 3. GUI handling of dependencies for selected runtime options and the ability to install a feature, but not activate it at runtime -- effective use of config.xml > Installer should only install packs(features) selected at install time > -- > > Key: GERONIMO-1194 > URL: http://issues.apache.org/jira/browse/GERONIMO-1194 > Project: Geronimo > Type: Improvement > Components: installer > Versions: 1.0-M5 > Environment: Maven, installer runtime > Reporter: erik daughtrey > Assignee: David Jencks > Fix For: 1.1 > Attachments: installer-ph2-trunk.patch.gz > > DJ: 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Installer -- Phase 2
I'm about 70% complete with the code changes for phase 2. I still have to add some validation and control for the new config.xml generation approach. The GUI panels and the actual config.xml generation are done. I probably won't be able to pick this back up until later this week since I'm traveling. I hope to post a patch for p2 later this week. On Monday 19 December 2005 15:57, Erik Daughtrey wrote: > Hmm, Well, usability aside, it sure changes the code I've written so far :) > > Actually, I think it is quite a good approach. > > IzPack allows any package to be selected on the pack selection panel as > long as it's prereqs are satisfied (can't install Tomcat console without > installing Tomcat). > > This all worked fairly well except that we have a condition not directly > supported by IzPack which is that the operator is not allowed to configure > both Jetty and Tomcat. The installer has override code to prevent the > selection of both, but it does not run until the pack selection panel is > exited. > > To some extent, the proposed change would change the semantics of the pack > selection screen into something more in accordance with the way IzPack > normally works. > > The changes I'd make to pull this off would be to: > 1. Remove the Tomcat/Jetty "Configuration Problem" panel which shows when > both are selected. > 2. Add check boxes to each related configuration panel asking whether the > config should be active. > 3. Assume that any packs not selected should be marked false in the config. > 4. Allow either Jetty or tomcat to be marked active, but not both. For > ease of programming, some static text on the screen could warn of the > inability to configure both (hmm, but only if both are to be installed). > 5. Do the magic to build the config-store for the installed components. > 6. probably lots of other things I have not thought of yet > > It's not too bad really. It probably is clearer. I'll do it this way. > > On Monday 19 December 2005 14:06, David Jencks wrote: > > On Dec 19, 2005, at 6:52 AM, Erik Daughtrey wrote: > > > The next phase of the installer is supposed to only install selected > > > components as well as activating them in config.xml. Currently, the > > > installer installs all components and modifies config.xml to only > > > start those > > > selected at install time. > > > > > > My current plan is to make this an optional feature by adding > > > somthing like a > > > "Lean install" pack that can be selected. This way folks who > > > happen to want > > > everything installed, but only some parts configured can have the > > > current > > > functionality. > > > > > > Does anyone vehemently disagree with this approach? > > > > I think the maximum flexibility would come with: > > > > check boxes on the first page select which configurations are > > actually included in the installed server. > > check boxes (?? or something) on configuration-specific page controls > > whether the configuration is turned on (load="true"/"false") in > > config.xml. > > > > Would this be too hard to use? > > > > thanks > > david jencks > > > > > -- > > > > > > Regards, > > > > > > Erik -- Regards, Erik
Re: Apache mini Geronimo (mini-G)
Agreed. I was a just a little predisposed to an answer given the particular project I'm undertaking. On Monday 19 December 2005 20:41, Aaron Mulder wrote: > In truth, I think we can go further in allowing for a "mini-Geronimo". > For example, right now IIRC the core J2EE configuration contains > OpenEJB, and we could probably break out OpenEJB into a separate > configuration to let you easily configure a server without it. I > think I've been convinced that more/smaller configurations is the way > to go, though we haven't figured out for sure how granular they should > get. > > Thanks, > Aaron > > On 12/19/05, Jan Bartel <[EMAIL PROTECTED]> wrote: > > Faisal, > > > > You can use either standalone Tomcat or Jetty containers to give > > you web container plus a couple of j2ee frills like jndi, resource > > mapping etc etc. > > > > However, if you want to keep within the geronimo idiom, then Erik's > > answer re cut-down installation is the way to go. > > > > regards > > Jan > > > > Wade Chandler wrote: > > > --- Faisal Akeel <[EMAIL PROTECTED]> wrote: > > >>If you look at the top reason that FireFox more > > >>preferred over Mozilla > > >>suite, this is because its small size and limited > > >>focus feature. > > >>So, Is there way to customize Geronimo to a simple > > >>web container (jetty) and > > >>small foot print database (derby) only, instead of > > >>big J2EE application and > > >>if it possible can anyone provide guide or a demo > > >>example on the wiki web > > >>site. > > >>Some people like mini cooper over big SUV car. > > > > > > That's what Tomcat is for. > > > > > > Wade -- Regards, Erik
Re: Installer -- Phase 2
Heinz, I'm not in control of when this function gets pulled into the product. The 1.0 cutoff passed me by, but the current code should make it into 1.0.1. The code that David's suggesting should not take too long, but this functionality was slated for 1.1. If you're willing to do a build, you could pull the latest patch off the JIRA GERONIMO-1192, apply it against branches/1.0, build it and give it a whirl. The patch is: installer-branches-1.0-200512181734.patch.gz. gunzip it and apply it in the geronimo directory: patch -p0 < installer-branches-1.0-200512181734.patch. Otherwise, I believe an installer will hit 1.0.1. On Monday 19 December 2005 14:05, Heinz Drews wrote: > I will try to be patient. > > Can I get the Installer as Xmas gift :-) > > On 12/19/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > In principal, I agree with your comments about minimal, default and > > custom install, but I don't think this approach is necessary yet. > > Once you have the opportunity to try the installer I think you'll see > > what I mean. I could explain, but "a picture is worth a thousand words" > > as they say. > > There really are just a few options to select. Mixing and matching these > > options into various configuration matrices might actually be more > > confusing. > > > > On Monday 19 December 2005 12:41, Heinz Drews wrote: > > > Hello Erik, > > > > > > the approach sounds just perfect. > > > > > > It would be great if the Installer would support a number of standard > > > configurations. > > > > > > e.g "Minimal", "Default", ... "Custom". > > > > > > Best regards, > > > Heinz > > > > > > On 12/19/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > > > The next phase of the installer is supposed to only install selected > > > > components as well as activating them in config.xml. Currently, the > > > > installer installs all components and modifies config.xml to only > > > > start those selected at install time. > > > > > > > > My current plan is to make this an optional feature by adding > > > > somthing like a "Lean install" pack that can be selected. This way > > > > folks who happen to want everything installed, but only some parts > > > > configured can have the current functionality. > > > > > > > > Does anyone vehemently disagree with this approach? > > > > > > > > -- > > > > > > > > Regards, > > > > > > > > Erik > > > > -- > > > > Regards, > > > > Erik -- Regards, Erik
Re: Installer -- Phase 2
Hmm, Well, usability aside, it sure changes the code I've written so far :) Actually, I think it is quite a good approach. IzPack allows any package to be selected on the pack selection panel as long as it's prereqs are satisfied (can't install Tomcat console without installing Tomcat). This all worked fairly well except that we have a condition not directly supported by IzPack which is that the operator is not allowed to configure both Jetty and Tomcat. The installer has override code to prevent the selection of both, but it does not run until the pack selection panel is exited. To some extent, the proposed change would change the semantics of the pack selection screen into something more in accordance with the way IzPack normally works. The changes I'd make to pull this off would be to: 1. Remove the Tomcat/Jetty "Configuration Problem" panel which shows when both are selected. 2. Add check boxes to each related configuration panel asking whether the config should be active. 3. Assume that any packs not selected should be marked false in the config. 4. Allow either Jetty or tomcat to be marked active, but not both. For ease of programming, some static text on the screen could warn of the inability to configure both (hmm, but only if both are to be installed). 5. Do the magic to build the config-store for the installed components. 6. probably lots of other things I have not thought of yet It's not too bad really. It probably is clearer. I'll do it this way. On Monday 19 December 2005 14:06, David Jencks wrote: > On Dec 19, 2005, at 6:52 AM, Erik Daughtrey wrote: > > The next phase of the installer is supposed to only install selected > > components as well as activating them in config.xml. Currently, the > > installer installs all components and modifies config.xml to only > > start those > > selected at install time. > > > > My current plan is to make this an optional feature by adding > > somthing like a > > "Lean install" pack that can be selected. This way folks who > > happen to want > > everything installed, but only some parts configured can have the > > current > > functionality. > > > > Does anyone vehemently disagree with this approach? > > I think the maximum flexibility would come with: > > check boxes on the first page select which configurations are > actually included in the installed server. > check boxes (?? or something) on configuration-specific page controls > whether the configuration is turned on (load="true"/"false") in > config.xml. > > Would this be too hard to use? > > thanks > david jencks > > > -- > > > > Regards, > > > > Erik -- Regards, Erik
Re: Installer -- Phase 2
In principal, I agree with your comments about minimal, default and custom install, but I don't think this approach is necessary yet. Once you have the opportunity to try the installer I think you'll see what I mean. I could explain, but "a picture is worth a thousand words" as they say. There really are just a few options to select. Mixing and matching these options into various configuration matrices might actually be more confusing. On Monday 19 December 2005 12:41, Heinz Drews wrote: > Hello Erik, > > the approach sounds just perfect. > > It would be great if the Installer would support a number of standard > configurations. > > e.g "Minimal", "Default", ... "Custom". > > Best regards, > Heinz > > On 12/19/05, Erik Daughtrey <[EMAIL PROTECTED]> wrote: > > The next phase of the installer is supposed to only install selected > > components as well as activating them in config.xml. Currently, the > > installer installs all components and modifies config.xml to only start > > those selected at install time. > > > > My current plan is to make this an optional feature by adding somthing > > like a "Lean install" pack that can be selected. This way folks who > > happen to want everything installed, but only some parts configured can > > have the current functionality. > > > > Does anyone vehemently disagree with this approach? > > > > -- > > > > Regards, > > > > Erik -- Regards, Erik
Installer -- Phase 2
The next phase of the installer is supposed to only install selected components as well as activating them in config.xml. Currently, the installer installs all components and modifies config.xml to only start those selected at install time. My current plan is to make this an optional feature by adding somthing like a "Lean install" pack that can be selected. This way folks who happen to want everything installed, but only some parts configured can have the current functionality. Does anyone vehemently disagree with this approach? -- Regards, Erik
Re: Apache mini Geronimo (mini-G)
Faisal, Once the installer is available(soon as the code for phase 1 is complete) this will be fairly simple to do. Currently, the installer actually places all the components of Geronimo in the config repository and customizes config.xml to only load the services requested in the install. The install selections will be easy to repeat since the installer allows for saving the selections in an XML file which can be fed to the installer to repeat the same installation on another machine(a nice feature of IzPack). The plan for the future of the installer is to also have it only install the selected components into the repository. I was just about to start a little discussion on the subject when I saw this note. Anyway, I think this should be optional since it's currently good for experimentation that the installer configures only a subset of the functionality, but actually installs all. This way, folks who want to experiment with features by turning them on and off in config.xml are free to do so. regards, erik p.s. To build a Mini-G at build time, look at the assemblies/j2ee-jetty(or tomcat)-server/project.xml. It should be possible to create a custom assemblies/j2ee-myconfig/project.xml which only includes the desired components. Note that the associated config.xml should be modified. I don't necessarily recommend this approach, but that's what's going on On Monday 19 December 2005 09:01, Faisal Akeel wrote: > If you look at the top reason that FireFox more preferred over Mozilla > suite, this is because its small size and limited focus feature. > So, Is there way to customize Geronimo to a simple web container (jetty) > and small foot print database (derby) only, instead of big J2EE application > and if it possible can anyone provide guide or a demo example on the wiki > web site. > Some people like mini cooper over big SUV car. -- Regards, Erik
Installer Status
Hello, The installer is basically done. Here's a rundown of what's included in the latest patch. 1. The webbuilder and ejbbuilder namespaces are set correctly depending on the web container selected. 2. Either Jetty(default) or Tomcat may be selected, but not both. 3. The LDAP realm is being configured 4. installed scripts are made executable 5. Jetty and Tomcat samples are selectable and install successfully 6. LDAP demo is selectable and installs 7. Port selections are validated against each other to prevent conflicts between installed services 8. The SMTP transport is configurable, but does not currently run(the config is not installed in config-store even though the deps in project.xml seem correct). The latest patch is posted to GERONIMO-1192. This JIRA has quite a few patches posted. For clarity, it might be a good idea to close 1192 and open another if more patches are required. -- Regards, Erik
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-branches-1.0-200512181734.patch.gz This patch should just about wrap up the installer. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.1 > Attachments: 20051214_jsisson_patch_installer.patch, > installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer-200512122002.patch, > installer-branches-1.0-12151601.patch.gz, > installer-branches-1.0-200512181734.patch.gz, > installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=comments#action_12360761 ] erik daughtrey commented on GERONIMO-1192: -- I have added Javamail and Daytrader configuration to the installer. However, javamail will not start, so the installer will configure it, but not mark it for starting. I have taken care of the issues raised in JSISSON's patch and ensured that all configs are inclued now. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.1 > Attachments: 20051214_jsisson_patch_installer.patch, > installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer-200512122002.patch, > installer-branches-1.0-12151601.patch.gz, installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1191) Installer should not allow conflicting configuration information
[ http://issues.apache.org/jira/browse/GERONIMO-1191?page=comments#action_12360580 ] erik daughtrey commented on GERONIMO-1191: -- The patch supplied with GERONIMO-1192 (installer-branches-1.0-12151601.patch.gz) addresses this problem. This JIRA can be closed. > Installer should not allow conflicting configuration information > > > Key: GERONIMO-1191 > URL: http://issues.apache.org/jira/browse/GERONIMO-1191 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime -- all platfoms > Reporter: erik daughtrey > Fix For: 1.x > > Currently, the installer does not verify that conflicting ports may have been > configured by the operator. Fixing this problem requires encoding of the > potential field conflicts on an inter-panel and intra-panel basis. > Ultimately, it would be great to factor environmental information into the > equation, but that's "boiling the ocean". -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-branches-1.0-12151601.patch.gz This patch includes: 1. Everything from the prior patches 2. Built against branches/1.0 3. Port validation (last missing feature) 4. Installs documentation 5. Code is re-factored to be cleaner and clearer We still need to validate the configs generated, but it does successfully install Tomcat and Jetty. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.1 > Attachments: 20051214_jsisson_patch_installer.patch, > installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer-200512122002.patch, > installer-branches-1.0-12151601.patch.gz, installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1362) Release notes changes just before 1.0 tag cut caused installer build errors
[ http://issues.apache.org/jira/browse/GERONIMO-1362?page=all ]
erik daughtrey updated GERONIMO-1362:
-
Attachment: installer-1.0-build.patch
This patch fixes the 1.0 build problem related to the IzPack based installer.
To apply the patch:
1. Download the patch to the root of the svn build tree
2. cd to the svn tree for geronimo i.e. the build root
3. run "patch -p0 < installer-1.0-build.patch"
> Release notes changes just before 1.0 tag cut caused installer build errors
> ---
>
> Key: GERONIMO-1362
> URL: http://issues.apache.org/jira/browse/GERONIMO-1362
> Project: Geronimo
> Type: Bug
> Components: installer
> Versions: 1.0
> Reporter: erik daughtrey
> Attachments: installer-1.0-build.patch
>
> The release notes for prior milestones were deleted and new release notes for
> 1.0 created.
> This caused the installer build to fail since it had hard coded references.
> The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
> exist as it now does. This seems reasonable as we move forward even into
> 1.1. We just need to ensure that a
> release notes version for the currentVersion exists.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1362) Release notes changes just before 1.0 tag cut caused installer build errors
[ http://issues.apache.org/jira/browse/GERONIMO-1362?page=all ]
erik daughtrey updated GERONIMO-1362:
-
Version: 1.0
(was: 1.0-M5)
> Release notes changes just before 1.0 tag cut caused installer build errors
> ---
>
> Key: GERONIMO-1362
> URL: http://issues.apache.org/jira/browse/GERONIMO-1362
> Project: Geronimo
> Type: Bug
> Components: installer
> Versions: 1.0
> Reporter: erik daughtrey
>
> The release notes for prior milestones were deleted and new release notes for
> 1.0 created.
> This caused the installer build to fail since it had hard coded references.
> The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
> exist as it now does. This seems reasonable as we move forward even into
> 1.1. We just need to ensure that a
> release notes version for the currentVersion exists.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1362) Release notes changes just before 1.0 tag cut caused installer build errors
Release notes changes just before 1.0 tag cut caused installer build errors
---
Key: GERONIMO-1362
URL: http://issues.apache.org/jira/browse/GERONIMO-1362
Project: Geronimo
Type: Bug
Components: installer
Versions: 1.0-M5
Reporter: erik daughtrey
The release notes for prior milestones were deleted and new release notes for
1.0 created.
This caused the installer build to fail since it had hard coded references.
The patch assumes that a RELEASE-NOTES-${pom.currentVersion}.txt will always
exist as it now does. This seems reasonable as we move forward even into 1.1.
We just need to ensure that a
release notes version for the currentVersion exists.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: building from 1.0 tag
I'll create a JIRA with a patch and instructions on applying the patch. On Wednesday 14 December 2005 02:24, Aaron Mulder wrote: > That happens on the continuum build machines, but so far not on my > machine. It's kind of not so bad since we aren't distributing the > installer yet. But I'm not sure why it's happening, and it would sure > be nice to figure it out and fix it. > > Aaron > > On 12/14/05, Christopher Chan <[EMAIL PROTECTED]> wrote: > > Has anyone experienced this in building from the 1.0 tag? > > > > [java] com.izforge.izpack.compiler.CompilerException: > > /home/cchan/OpenSource/geronimo/1.0tag/assemblies/j2ee-installer/target/g > >eronimo-1.0/geronimo-izpack.xml:23: Resource not found: > > /home/cchan/OpenSource/geronimo/1.0tag/assemblies/j2ee-installer/target/g > >eronimo-1.0/RELEASE-NOTES-1.0-M5.txt [java] at > > com.izforge.izpack.compiler.CompilerConfig.parseError(CompilerConfig.java > >:1518) [java] at > > com.izforge.izpack.compiler.CompilerConfig.findProjectResource(CompilerCo > >nfig.java:1447) [java] at > > com.izforge.izpack.compiler.CompilerConfig.addResources(CompilerConfig.ja > >va:1044) [java] at > > com.izforge.izpack.compiler.CompilerConfig.executeCompiler(CompilerConfig > >.java:313) [java] at > > com.izforge.izpack.compiler.CompilerConfig.main(CompilerConfig.java:1847) > > [java] at > > com.izforge.izpack.compiler.Compiler.main(Compiler.java:620) > > [java] > > [java] (tip : use -? to get the commmand line parameters) > > [java] [ERROR] Java Result: 1 -- Regards, Erik
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-200512122002.patch This patch fixes the additional problems with windows. Also, this patch is includes all the code from the other larger patches. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.0 > Attachments: installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer-200512122002.patch, > installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-200512121118.patch This patch fixes build problems and hopefully the merge problems with config.xml and geronimo-izpack.xml. Also, it should fix the problem with Validator.java not being found. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.0 > Attachments: installer-200512111301.patch, installer-200512112003.patch, > installer-200512121118.patch, installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-200512112003.patch regenerated patch after update. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.0 > Attachments: installer-200512111301.patch, installer-200512112003.patch, > installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1337) Add quotes around variable reference in geronimo.sh
Add quotes around variable reference in geronimo.sh --- Key: GERONIMO-1337 URL: http://issues.apache.org/jira/browse/GERONIMO-1337 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0-M5 Environment: linux Reporter: erik daughtrey geronimo.sh contains a statement - touch $GERONIMO_OUT - that needs quotes around it to prevent errors when the name contains spaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=comments#action_12360183 ] erik daughtrey commented on GERONIMO-1192: -- The patch uploaded today contains: 1. changes to config.xml in assemblies/j2ee-installer/src/var/config so that it has variables to be replaced by the installer for enabling various features. 2. A new set of code in modules/installer-support which extends the izpack functionality to allow additional control of the installation work flow. a) enables code to check if both jetty and tomcat are selected b) enables code to do variable manipulation and set variables in config.xml based on the packs selected. 3. Changes to assemblies/j2ee-installer/src/geronimo-izpack.xml to enable a few variables and enable the extensions made available by modules/installer-support. 4. Changes to assemblies/j2ee-installer/src/izpack-user-input.xml to add an error panel to be displayed if both tomcat and jetty are selected and to enable a panel at the end of configuration to give the operator a chance to review the config. Also the last panel is a trigger for the extension code to do some work. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: John Sisson > Fix For: 1.0 > Attachments: installer-200512111301.patch, installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer-200512111301.patch This patch updates the config xml and not allow Jetty and Tomcat to be installed together. The patch also fixes the web builder namespace and ejb listener name. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0-M5 > Environment: Installer runtime > Reporter: erik daughtrey > Assignee: David Jencks > Fix For: 1.0 > Attachments: installer-200512111301.patch, installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Does there need to be a default web container?
I may have phrased the original issue badly. The installer has both Jetty and Tomcat as options to install on the main pack selection page. It was decided that because of the complexity of installing two web containers that we should not install both, but allow the operator to select one or the other. In M5, the installer actually allowed both containers to be configured, but did not have a way to validate the ports selected. When configured correctly with no conflicting ports, both containers will start. There's some goofiness with offlineDeployer and runtimeDeployer since one of the containers will win the config.xml entries if more than one is selected -- looks like Tomcat wins. For 1.0, both containers will be listed on the first selection screen. However, it didn't make sense to default both to install when the plan was to only allow one. Allowing both requires the installer to validate the ports and ensure that the operator does not configure both containers to the same port. This problem exists for other port types as well, but is less likely to be a problem. IzPack does not support this inter-panel validation easily i.e. through normal XML based configuration. It requires that java code be built to extend the user input panels. On the other hand, limiting the operator to one web container is no panacea either. To effectively do this, I have configured the XML to set Jetty as the default to install (Tomcat can be selected) since it's confusing to do otherwise in this scenario (although the default could just as easily be Tomcat and it looks like the vote is going that way). This effectively starts down a good path for this scenario, but the operator can easily select both containers again. To stop this, I will extend a userinput panel to be invoked to check that both are selected and not allow the install to proceed past the first userinput screen -- the first screen after the major component selection. This again requires java code since IzPack does not have a parameter to apply to packs such as "exclusiveOf( packName )". This is interesting since it does have "depends( packname )" which allows us to require the Tomcat container when installing the Tomcat console, etc. This may be more than everyone wants to know, but to answer your question, I don't see any particular reason why the installer cannot allow installation of both. However, it's very late in the 1.0 cycle and the current design is that we'd allow one or the other, but not both. I have no particular preference myself. On Thursday 08 December 2005 18:30, Jeff Genender wrote: > This is obviously a hot topic and I hope that as a Geronimo PMC and user > community we are not forced to have to show preference of one over the > other. There is obviously some personal preferences on both sides and > we are a great open source project because we do not have to get behind > one *or* the other. We can get behind them both. > > May I ask why the installer/wizard cannot have a page called "Choose > Your Web Container" and have an option for Jetty and Tomcat, but neither > selected? Does there need to be a default? Can we just let the end > user choose? > > IMHO, I don't think we should provide a preference for one over the > other. I really like both. I think we should give the user the choice > without hinting a preference. > > Thoughts and comments? > > Jeff -- Regards, Erik
Re: Build errors
Sachin, Try regenerating the plugins. cd plugins/geronimo-assembly-plugin maven -o cd ../geronimo-izpack-plugin maven -o On Thursday 08 December 2005 15:54, Sachin Patel wrote: > I'm constantly failing during this goal. Any ideas? > > izpack:izpack-installer-build: > [echo] IZPack installer build is running. > [echo] IZPack Version is 3.8.0 > [java] > [java] .:: IzPack - Version 3.8.0 ::. > [java] > [java] < compiler specifications version : 1.0 > > [java] > [java] - Copyright (C) 2001-2005 Julien Ponge > [java] - Visit http://www.izforge.com/ for the latests releases > [java] - Released under the terms of the Apache Software License > version 2.0. > [java] > [java] -> Processing : > /Users/sppatel/geronimo/geronimo/assemblies/j2ee-installer/target/geronimo- >1 .0-SNAPSHOT/geronimo-izpac > k.xml > [java] -> Output : > /Users/sppatel/geronimo/geronimo/assemblies/j2ee-installer/target/geronimo- >i nstaller-1.0-SNAPSHOT.jar > [java] -> Base path : . > [java] -> Kind: standard > [java] -> Compression : default > [java] -> Compr. level: -1 > [java] > [java] Adding resource: IzPack.uninstaller > [java] Setting the installer information > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/l >i b/liquidlnf.jar > [java] Setting the GUI preferences > [java] Adding langpack: eng > [java] Adding resource: flag.eng > [java] Adding resource: Installer.image > [java] Adding resource: LicencePanel.licence > [java] Adding resource: InfoPanel.info > [java] Adding resource: userInputSpec.xml > [java] Adding resource: ImgPacksPanel.img.0 > [java] Adding resource: ImgPacksPanel.img.1 > [java] Adding resource: ImgPacksPanel.img.2 > [java] Adding resource: ImgPacksPanel.img.3 > [java] Adding resource: ImgPacksPanel.img.4 > [java] Adding resource: ImgPacksPanel.img.5 > [java] Adding resource: ImgPacksPanel.img.6 > [java] Adding resource: ImgPacksPanel.img.7 > [java] Adding resource: ImgPacksPanel.img.8 > [java] Adding resource: ImgPacksPanel.img.9 > [java] Adding resource: ImgPacksPanel.img.10 > [java] Adding resource: ImgPacksPanel.img.11 > [java] Adding resource: ImgPacksPanel.img.12 > [java] Adding resource: ImgPacksPanel.img.13 > [java] Adding resource: ImgPacksPanel.img.14 > [java] Adding resource: ImgPacksPanel.img.15 > [java] Adding resource: ImgPacksPanel.img.16 > [java] Adding resource: ImgPacksPanel.img.17 > [java] Adding resource: ImgPacksPanel.img.18 > [java] Adding resource: ImgPacksPanel.img.19 > [java] Adding resource: ImgPacksPanel.img.20 > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/HelloPanel. > jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/LicencePane > l.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/TargetPanel > .jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/ImgPacksPan > el.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/UserInputPa > nel.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/InstallPane > l.jar > [java] Adding content of jar: > file:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b >i n/panels/InfoPanel.j > ar > [java] Adding content of jar: > file:/U
[Vote] Installer: Default Web Container Selection
The installer should make either Tomcat or Jetty the default selection. The operator can always override and select the other. Vote: [ ] Make Jetty the default Web Container install selection [ ] Make Tomcat the default web container install selection We may run out of time before the votes can be tallied. For that reason, I'm making the default Jetty unless someone can provide a good reason why it shouldn't be. FYI - it's been decided that installation of both web containers via the installer will not be allowed. Manual configuration of both is possible though. -- Regards, Erik
Installer Status
The installer builds successfully under the new build process. The installer is built using the geronimo-izpack-plugin from assemblies/j2ee-installer. When the installer runs, it will create a runnable server, but the configuration is currently fixed to Jetty. I'm working to get the config.xml updated based on the configuration options selected and should complete the work tomorrow. Unfortunately, it's been a very long day and I won't make the midnight cutoff. There are two other additional pieces of work yet to do: 1. Inter-panel validation of conflicting configuration information i.e. conflicting ports 2. Selection of either Jetty or Tomcat, but not both -- Regards, Erik
[jira] Updated: (GERONIMO-1192) Installer should create a config.xml for the target install
[ http://issues.apache.org/jira/browse/GERONIMO-1192?page=all ] erik daughtrey updated GERONIMO-1192: - Attachment: installer_1192_200512080036.patch First patch of a few. This begins to address a combined config.xml, but does not allow configuration yet. This patch includes some small additional fixes. > Installer should create a config.xml for the target install > --- > > Key: GERONIMO-1192 > URL: http://issues.apache.org/jira/browse/GERONIMO-1192 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0 > Environment: Installer runtime > Reporter: erik daughtrey > Attachments: installer_1192_200512080036.patch > > DJ - "This could be done by adding bits associated with each configuration, > or by removing chunks from a 'universal' config.xml for the configuations we > didn't install." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1193) Installer should include schema files for components included in the install target
[ http://issues.apache.org/jira/browse/GERONIMO-1193?page=all ] erik daughtrey updated GERONIMO-1193: - Geronimo Info: [Patch Available] > Installer should include schema files for components included in the install > target > --- > > Key: GERONIMO-1193 > URL: http://issues.apache.org/jira/browse/GERONIMO-1193 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0 > Environment: Maven, installer runtime > Reporter: erik daughtrey > Attachments: installer_1193.patch > > DJ: "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." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1193) Installer should include schema files for components included in the install target
[ http://issues.apache.org/jira/browse/GERONIMO-1193?page=all ] erik daughtrey updated GERONIMO-1193: - Attachment: installer_1193.patch This patch installs car files during assembly and supplies a fixed config.xml for startup. The installer isn't really configurable yet and there's still a failure in processing at the end of install. However, processing may not even be used and the failed exec is just a placeholder for now. This fixed install will install jetty. > Installer should include schema files for components included in the install > target > --- > > Key: GERONIMO-1193 > URL: http://issues.apache.org/jira/browse/GERONIMO-1193 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0 > Environment: Maven, installer runtime > Reporter: erik daughtrey > Attachments: installer_1193.patch > > DJ: "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." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1266) Geronimo Izpack installer does not set shell scripts as executable
[ http://issues.apache.org/jira/browse/GERONIMO-1266?page=comments#action_12359623 ] erik daughtrey commented on GERONIMO-1266: -- This has been fixed and this JIRA can be closed. > Geronimo Izpack installer does not set shell scripts as executable > -- > > Key: GERONIMO-1266 > URL: http://issues.apache.org/jira/browse/GERONIMO-1266 > Project: Geronimo > Type: Bug > Components: installer > Versions: 1.0 > Reporter: John Sisson > Assignee: John Sisson > Fix For: 1.0 > > I will do this after my new shell scripts are checked in. > Basically we need to have an stage="never" os="unix" keep="true"> line for each file to be marked > executable. Unfortunately I don't think there is a way to have a wildcard > for all *.sh files, we need to name each one explicitly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1193) Installer should include schema files for components included in the install target
[ http://issues.apache.org/jira/browse/GERONIMO-1193?page=comments#action_12359600 ] erik daughtrey commented on GERONIMO-1193: -- This work is complete for 1.0. This JIRA can be closed. > Installer should include schema files for components included in the install > target > --- > > Key: GERONIMO-1193 > URL: http://issues.apache.org/jira/browse/GERONIMO-1193 > Project: Geronimo > Type: New Feature > Components: installer > Versions: 1.0 > Environment: Maven, installer runtime > Reporter: erik daughtrey > > DJ: "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." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
