[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-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/) -- Regards, Erik
[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] 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] 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-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] 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_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] 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/webconsole-tomcat dir/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_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-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] 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-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-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
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] 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 08:53, Dave Colasurdo wrote: Erik Daughtrey wrote: On Wednesday 01 February 2006 03:09, David Jencks wrote: On Jan 31, 2006, at 9:08 PM, John Sisson wrote: 1) In the 1.0 branch I noticed that an installer installation has geronimo/repository/geronimo/cars directory (containing approx 42 MB of car files) but the tomcat jetty assemblies don't have the car directory. Is this intended? Yes When are car files in the repository used? During final processing, the ConfigInstaller runs which installs the cars associated with the selected packs into the config-store. The ConfigInstaller reads var/config/configure.xml to determine which cars need to be installed. Configure.xml is created by the assembly plugin, but contains variables to be replaced at install time to inform ConfigInstaller of which cars need to be installed. Assuming these aren't needed after installation, can/should these files be deleted by the installer therefore saving 42M? I know diskpace is cheap, though it is one of the measurements that gets used when comparisons are done against other application servers. Already thinking about this. I was thinking that the ConfigInstaller could have an option to delete the cars when it's done. For the default install, this would be true always. JIRA 1568. I think DJ is probably glad we've gotten to the point where we can consider these cleanup options :) Does this directory need to be retained when advancedMode is true? For the advancedmode install, deletion of the cars could be an option. All this could be done with a new panel which queries for a disposition of the CAR files post install. Of course, the panel needs to explain that only CAR files for options actually installed will be available for use. Until we have a good way to use these CAR files after and install, it probably doesn't make sense to add this. I think this is an artifact of the way the installer is working right now, namely including a repo inside it and copying everything into the server under construction, whether or not it is used. I want it to install only the stuff you select. 2) I also noticed that in the installer installation using the default options, the following files (that are installed for the jetty/tomcat assemblies) are not installed: I fixed this with the patch on GERONIMO-1518. Originally, I had missed the dependency in project.xml and the files were not copied to target. geronimo/repository/jars/geronimo-javamail-transport-1.0.1- SNAPSHOT.jar geronimo/repository/jars/geronimo-mail-1.0.1-SNAPSHOT.jar What happens if the user initially does not select SMTP transport (the default) in the installer and then after installation changes their mind? How are we expecting the user to get it installed? Interesting question. There are some interesting options here. 1. If one uses the installer in default mode, the situation mentioned will occur. For instance, if javamail is not selected, then it will not be installed and the easiest remedy is a reinstall. 2. If, however, one uses the -Dadvancedmode=true mode of the the installer, then it's possible to install the configuration, but have it inactive at runtime. It'll be in the config, but not running in the server. Of course, with item #1, it's possible to install everything and disable unwanted items in config.xml manually and achieve the same goal. 3. There's actually a third option that's not exposed well (yet?). One might install everything with the advanced installer then delete everything in config-store, modify configure.xml, run ConfigInstaller to get a new configuration and modify config.xml accordingly. Of course, this would be for very advanced folks. In the future, it may be worth considering late-feature addition. The user can rerun the installer, it detects what is already installed and allows the user to select and install additional components. Of course, I realize that izpack probably doesn't lend itself to this and am not suggesting this for any current release. Just wanted to throw out the idea for the future. For now, option 1 seems fine. Yes, as the installer matures, these types of features should be considered. I'd also like to see us build an online installer. Coupling an online capability with the ability to add new features would make this even more powerful. Additionally, an online installer could allow for a very small download footprint for the installer. Then the installer would download only what is selected for install. Due to my theory about (1), I think that these are simply left out of the installers internal repo and so the mail config may not work. As noted in (1) in my opinion these should get copied into the server under construction only if you select the mail configuration for installation. 1518 accomplishes this. thanks david jencks
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-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
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
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 DONT 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 or enabling the config to use just certain portions of the same config-store). Isn't it just simpler/easier to have them lay down two separate *isolated* installations for their comparisons? IMHO, the confusion of someone accidentally laying down two web containers outweighs any potential benefit. Concerning the enable/disable of selected components. It seems quite strange to select installation options on panel 1 and then have panel 4 and panel 5 ask if you want the options that you selected on panel 1 enabled. I would guess that an average user might think Didn't I already tell the installer I want these options installed? What
[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
[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-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
[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: - 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
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 izpack-user-input.xml need to be updated. This results in a panel that seems to show the hierarchy visually. Though adding the spaces for each element in the xml files is a real hack and does seem troublesome. There should be an easier way to accomplish this without unnaturally padding or creating a custom panel. I'll post a question on this subject on the izpack mailing list. 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. Will also post this on the izpack mailing list. Are they responsive to suggestions? 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
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
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
[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] 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] 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
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. laf name=liquid os family=unix/ /laf 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: 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
[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-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-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-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-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
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 to the server selection and removing the other comment
[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
[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-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-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-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] 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] 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-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] 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] 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-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-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-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 j:file 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 j:file 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 j:file 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_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 j:file 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-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/geronimo-assembly-plugin/plugin.jelly from
pack
[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
[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
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: 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 -- 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: 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
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
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
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] 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
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] 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
[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] 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-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-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-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
[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] 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] 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
[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
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:/Users/sppatel/maven_repo/izpack/jars/standalone-compiler-3.8.0.jar!/b i n/panels/FinishPanel .jar [java] - Fatal error :
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
[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
[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] 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-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
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] Commented: (GERONIMO-1189) [PATCH] Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=comments#action_12359432 ] erik daughtrey commented on GERONIMO-1189: -- Thanks for applying the patches and fixing the other two problems. This JIRA can be closed now. [PATCH] Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, geronimo_banner_vert.gif, geronimo_med_vert.gif, installer.jar, jira1189_200512060118.patch It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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-1189) Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] erik daughtrey updated GERONIMO-1189: - Summary: Installer should be built from its own module in assemblies. (was: [PATCH] Installer should be built from its own module in assemblies.) Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, geronimo_banner_vert.gif, geronimo_med_vert.gif, installer.jar, jira1189_200512060118.patch It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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-1188) Get necessary izpack jars into Maven repository for access during build
[ http://issues.apache.org/jira/browse/GERONIMO-1188?page=comments#action_12359433 ] erik daughtrey commented on GERONIMO-1188: -- This issue can be closed. MAVENUPLOAD-598 was completed on 11/22 and the needed files are now in the repository. Get necessary izpack jars into Maven repository for access during build --- Key: GERONIMO-1188 URL: http://issues.apache.org/jira/browse/GERONIMO-1188 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: maven and maven repository Reporter: erik daughtrey As Aaron points out, there's probably only one jar needed. David J would like to see this in a public repository such as ibiblio. -- 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-1190) usability: Install should not display configuration screens for packs not being installed
[ http://issues.apache.org/jira/browse/GERONIMO-1190?page=comments#action_12359434 ] erik daughtrey commented on GERONIMO-1190: -- This issue can be closed now. Fixed by David Jencks. usability: Install should not display configuration screens for packs not being installed - Key: GERONIMO-1190 URL: http://issues.apache.org/jira/browse/GERONIMO-1190 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: installer runtime on all platforms Reporter: erik daughtrey It's possible that the createForPack element, when properly leveraged, may allow this capability. -- 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-1189) [PATCH] Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] erik daughtrey updated GERONIMO-1189: - Attachment: jira1189_200512060118.patch The 20051206018 patch requires two additional gif files The gifs go into geronimo/assemblies/j2ee-installer/src/izpack/ The files are geronimo_banner_vert.gif and geronimo_med_vert.gif They're appended in follow-on attachments (the patch may or may not svn add them). [PATCH] Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, installer.jar, jira1189_200512060118.patch It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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-1189) [PATCH] Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] erik daughtrey updated GERONIMO-1189: - Attachment: geronimo_banner_vert.gif [PATCH] Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, geronimo_banner_vert.gif, geronimo_med_vert.gif, installer.jar, jira1189_200512060118.patch It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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-1189) [PATCH] Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] erik daughtrey updated GERONIMO-1189: - Attachment: geronimo_med_vert.gif [PATCH] Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, geronimo_banner_vert.gif, geronimo_med_vert.gif, installer.jar, jira1189_200512060118.patch It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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-1189) [PATCH] Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] erik daughtrey updated GERONIMO-1189: - Geronimo Info: [Patch Available] [PATCH] Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, geronimo_banner_vert.gif, geronimo_med_vert.gif, installer.jar, jira1189_200512060118.patch It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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
Installer status
I put a patch out for JIRA 1189 which will create the installer from the output of David Jencks' assemblies work. The installer is created from a new plugin (plugins/geronimo-izpack-installer). There's still a good deal of work to do though. -- Regards, Erik
[jira] Commented: (GERONIMO-1188) Get necessary izpack jars into Maven repository for access during build
[ http://issues.apache.org/jira/browse/GERONIMO-1188?page=comments#action_12359162 ] erik daughtrey commented on GERONIMO-1188: -- This issue can be closed. MAVENUPLOAD-598 was completed on 11/22 and the needed files are now in the repository. Get necessary izpack jars into Maven repository for access during build --- Key: GERONIMO-1188 URL: http://issues.apache.org/jira/browse/GERONIMO-1188 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: maven and maven repository Reporter: erik daughtrey As Aaron points out, there's probably only one jar needed. David J would like to see this in a public repository such as ibiblio. -- 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 progress
I'm taking David's framework and will be building the installer such that it includes the internal repository and lays down only the desired configurations at install time. $ erik On Tuesday 22 November 2005 04:46, David Jencks wrote: I've been working with Eric on the installer. I think we have quite a few of the pieces in place, although there is still a lot to do with izpack. I modified the assembly plugin to allow subclasses to set the source repository, the target repository, and the target config-store. One the the classes now accepts a configuration car file, and copies it an all its dependencies into another repository. My idea is that this will be the main step in building the installer. We will supply a list of all the configurations we want available, and get a repository that we will pack up into the installer that contains all the car files and all their dependencies. (We'll also need the lib and bin directories at least, but the contents of these are fixed). I created a new modules assemblies/j2ee-installer that does this (although the list of configs is copied directly from the jetty server and needs all the tomcat specific cars added to it). I'm assuming that we will be able to package this repo into the installer jar without much trouble, but I don't know how to do that yet. We should be able to use the regular assembly plugin LocalConfigInstaller class when the installer is run to install, from the repository inside the installer jar, the configurations into the target config store and all their dependencies into the target repository. I haven't figured out how to do that yet either. I'm not sure if a custom action is sufficient or if we have to write some kind of custom panel as well. I beileve the LocalConfigInstaller will be able to copy stuff out of a jar file if we supply a jar URI for the sourceRepositoryURI. thanks david jencks -- Regards, Erik
[jira] Commented: (GERONIMO-1188) Get necessary izpack jars into Maven repository for access during build
[ http://issues.apache.org/jira/browse/GERONIMO-1188?page=comments#action_12358193 ] erik daughtrey commented on GERONIMO-1188: -- Submitted Jira to Codehaus. MAVENUPLOAD-598 Get necessary izpack jars into Maven repository for access during build --- Key: GERONIMO-1188 URL: http://issues.apache.org/jira/browse/GERONIMO-1188 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: maven and maven repository Reporter: erik daughtrey As Aaron points out, there's probably only one jar needed. David J would like to see this in a public repository such as ibiblio. -- 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-1189) Installer should be built from its own module in assemblies.
[ http://issues.apache.org/jira/browse/GERONIMO-1189?page=all ] erik daughtrey updated GERONIMO-1189: - Attachment: geronimo-1189.patch The patch is a first cut toward a build for the installer. Currently, the build is still disabled through a dummy build target since the installer compile jar dependency is not yet resolvable. There's a codehaus JIRA (mavenupload-598) pending to resolve the dependency. Installer should be built from its own module in assemblies. Key: GERONIMO-1189 URL: http://issues.apache.org/jira/browse/GERONIMO-1189 Project: Geronimo Type: Improvement Components: installer Versions: 1.0 Environment: Maven Reporter: erik daughtrey Attachments: geronimo-1189.patch, installer.jar It would be best to build using a Maven plugin. Otherwise, if impractical, use jelly. There seems to be an installer plugin for Maven 2, but not for the current build. -- 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
