[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: - Summary: [PATCH] Installer should be built from its own module in assemblies. (was: Installer should be built from its own module in assemblies.) [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 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
Re: The Installer
Hey David, I'll start working on these items. erik On Wednesday 16 November 2005 03:24, David Jencks wrote: It would be good if we could get the installer working well for 1.0. Here are some of the things I think need to happen. 1. The necessary izpack jars need to get into some maven repo, preferably a public one such as ibiblio. They might be on there way there already, otherwise we should figure out which jars are needed and file an upload request. 2. Installer building should occur in its own module in assemblies. It would be best if the installer can be built using a maven plugin, but if that seems impractical we can use a bunch of jelly for now. There is an izpack plugin but I think it is maven 2 only (??). 3. The installer currently has a page where you check the major features you want, and on the following pages you configure them. This seems like a basically acceptable paradigm to me, but there is a problem in that all the following pages display even if they are empty. I've been told that moving the createForPack element out one level to the panel element will fix this. 4. 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. 5. We should find a way to check that no port conflicts have been configured. 6. We need to construct a config.xml file for the target install. This could be done by adding bits associated with each configuration, or by removing chunks from a universal config.xml for the configurations we didnt' install. 7. Somewhat similarly, we need to include the schema files (for human reference, they aren't used by geronimo) for the bits that are included in the install target. 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. There's probably more to do, but this is what I've thought of so far. thanks david jencks -- Regards, Erik
Re: The Installer
I read the Building an Installer wiki page. It helped me get going. It's getting a little crusty, but it was still very helpful. I'd be interested in the ibiblio information. Please send it along. I had already figured that I'd be researching this based on David's post. I'll look into the port validation issues and see if there's something easily done from within IZPack. I'm not averse to helping improve IZPack if it can help both projects and there's actually time to do the work. I am assuming I should create JIRAs for each of the issues raised. Unless someone disagrees, I'll do this. Regards, erik On Wednesday 16 November 2005 11:03, Aaron Mulder wrote: 1) I think the standalone compiler is the only necessary JAR, and I had volunterred to try to get it onto iBiblio at one point, but didn't actually get around to it. It would be great if someone else could do that. Someone (Jacek?) pointed me to a writeup on how to get arbitrary JARs onto ibiblio, and I can pass that along if it would be helpful. 5) I think port validation was tricky, because IIRC, each field is validated independently. I don't think there's a good way to validate a whole screen at a time, much less a group of ports on a group of screens, some of which you may not have seen yet. If this turns out to be hard, I don't think it would be the end of the world to skip it for now, since presumably the user knows not to create port conflicts. 7) I think we could safely install all the schemas if you install J2EE features, and none of the schemas otherwise. It's not quite perfect, but close enough. The other problem we need to think about, related to the port issue, is setting the default web port. If you install only Jetty or Tomcat, whichever one you install should default to 8080. But if you install both, they should default to different ports. I would be OK saying that the installer will not install both, which would make this easier, but I don't think there's that kind of exclusivity in the feature selection screen. Then again, I haven't worked with IzPack for a while now so my information may be a little out of date. :) Aaron On 11/16/05, Erik Daughtrey [EMAIL PROTECTED] wrote: Hey David, I'll start working on these items. erik On Wednesday 16 November 2005 03:24, David Jencks wrote: It would be good if we could get the installer working well for 1.0. Here are some of the things I think need to happen. 1. The necessary izpack jars need to get into some maven repo, preferably a public one such as ibiblio. They might be on there way there already, otherwise we should figure out which jars are needed and file an upload request. 2. Installer building should occur in its own module in assemblies. It would be best if the installer can be built using a maven plugin, but if that seems impractical we can use a bunch of jelly for now. There is an izpack plugin but I think it is maven 2 only (??). 3. The installer currently has a page where you check the major features you want, and on the following pages you configure them. This seems like a basically acceptable paradigm to me, but there is a problem in that all the following pages display even if they are empty. I've been told that moving the createForPack element out one level to the panel element will fix this. 4. 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. 5. We should find a way to check that no port conflicts have been configured. 6. We need to construct a config.xml file for the target install. This could be done by adding bits associated with each configuration, or by removing chunks from a universal config.xml for the configurations we didnt' install. 7. Somewhat similarly, we need to include the schema files (for human reference, they aren't used by geronimo) for the bits that are included in the install target. 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. There's probably more to do, but this is what I've thought of so far. thanks david jencks
Re: The Installer
There's definitely a radio button capability. Do we want to enforce the configuration of only one web container? Regards, erik On Wednesday 16 November 2005 12:06, David Jencks wrote: On Nov 16, 2005, at 8:03 AM, Aaron Mulder wrote: 1) I think the standalone compiler is the only necessary JAR, and I had volunterred to try to get it onto iBiblio at one point, but didn't actually get around to it. It would be great if someone else could do that. Someone (Jacek?) pointed me to a writeup on how to get arbitrary JARs onto ibiblio, and I can pass that along if it would be helpful. 5) I think port validation was tricky, because IIRC, each field is validated independently. I don't think there's a good way to validate a whole screen at a time, much less a group of ports on a group of screens, some of which you may not have seen yet. If this turns out to be hard, I don't think it would be the end of the world to skip it for now, since presumably the user knows not to create port conflicts. This was the demise of the M5 installer: it was very easy to get port conflicts. I was thinking of some kind of verification class used at the end that made sure no property values matching some pattern had the same values. 7) I think we could safely install all the schemas if you install J2EE features, and none of the schemas otherwise. It's not quite perfect, but close enough. True, but I am hoping to move this into the assembly plugin and use a generic procedure to extract schemas rather than the somewhat custom code we use today. The other problem we need to think about, related to the port issue, is setting the default web port. If you install only Jetty or Tomcat, whichever one you install should default to 8080. But if you install both, they should default to different ports. I would be OK saying that the installer will not install both, which would make this easier, but I don't think there's that kind of exclusivity in the feature selection screen. I'd certainly like to know if there is some kind of radio button functionality. Then again, I haven't worked with IzPack for a while now so my information may be a little out of date. :) Aaron On 11/16/05, Erik Daughtrey [EMAIL PROTECTED] wrote: Hey David, I'll start working on these items. Excellent david jencks erik On Wednesday 16 November 2005 03:24, David Jencks wrote: It would be good if we could get the installer working well for 1.0. Here are some of the things I think need to happen. 1. The necessary izpack jars need to get into some maven repo, preferably a public one such as ibiblio. They might be on there way there already, otherwise we should figure out which jars are needed and file an upload request. 2. Installer building should occur in its own module in assemblies. It would be best if the installer can be built using a maven plugin, but if that seems impractical we can use a bunch of jelly for now. There is an izpack plugin but I think it is maven 2 only (??). 3. The installer currently has a page where you check the major features you want, and on the following pages you configure them. This seems like a basically acceptable paradigm to me, but there is a problem in that all the following pages display even if they are empty. I've been told that moving the createForPack element out one level to the panel element will fix this. 4. 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. 5. We should find a way to check that no port conflicts have been configured. 6. We need to construct a config.xml file for the target install. This could be done by adding bits associated with each configuration, or by removing chunks from a universal config.xml for the configurations we didnt' install. 7. Somewhat similarly, we need to include the schema files (for human reference, they aren't used by geronimo) for the bits that are included in the install target. 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. There's probably more to do
Re: The Installer
Thanks for the ibiblio information. I'm not keen on pushing changes into IZPack at this point. The statement was more of a nod at the possibility that IZPack may not have all the capability we'd like. After looking at the documentation a little more, I see that it probably won't be necessary. I'll plan on having the installer impose an either-or policy on web container installation. Regards, erik On Wednesday 16 November 2005 12:45, Aaron Mulder wrote: I don't want to discourage you, but I don't think the timing will work out too well on IzPack improvements. Their releases are pretty infrequent and I think the main developer is on vacation at the moment. I didn't have much luck getting other Geronimo folks interested in using my custom hacked IzPack build, which is why it was so nice to see 3.8.0 released. So let's make the best of what we've got in the standard build, and perhaps keep a list of improvements we'd like to see to IzPack in the post-Geronimo-1.0 time frame. (A hook to validate an entire user entry screen at a time is on my list.) Anyway, the Maven instructions (from John Sission, sorry John) are: http://maven.apache.org/maven-1.x/reference/repository-upload.html And as for the radios, I think we should definitely enforce only 1 web container through the installer. That will save us a whole world of pain. If people want 2 web containers, let them take some manual steps! Aaron On 11/16/05, Erik Daughtrey [EMAIL PROTECTED] wrote: I read the Building an Installer wiki page. It helped me get going. It's getting a little crusty, but it was still very helpful. I'd be interested in the ibiblio information. Please send it along. I had already figured that I'd be researching this based on David's post. I'll look into the port validation issues and see if there's something easily done from within IZPack. I'm not averse to helping improve IZPack if it can help both projects and there's actually time to do the work. I am assuming I should create JIRAs for each of the issues raised. Unless someone disagrees, I'll do this. Regards, erik On Wednesday 16 November 2005 11:03, Aaron Mulder wrote: 1) I think the standalone compiler is the only necessary JAR, and I had volunterred to try to get it onto iBiblio at one point, but didn't actually get around to it. It would be great if someone else could do that. Someone (Jacek?) pointed me to a writeup on how to get arbitrary JARs onto ibiblio, and I can pass that along if it would be helpful. 5) I think port validation was tricky, because IIRC, each field is validated independently. I don't think there's a good way to validate a whole screen at a time, much less a group of ports on a group of screens, some of which you may not have seen yet. If this turns out to be hard, I don't think it would be the end of the world to skip it for now, since presumably the user knows not to create port conflicts. 7) I think we could safely install all the schemas if you install J2EE features, and none of the schemas otherwise. It's not quite perfect, but close enough. The other problem we need to think about, related to the port issue, is setting the default web port. If you install only Jetty or Tomcat, whichever one you install should default to 8080. But if you install both, they should default to different ports. I would be OK saying that the installer will not install both, which would make this easier, but I don't think there's that kind of exclusivity in the feature selection screen. Then again, I haven't worked with IzPack for a while now so my information may be a little out of date. :) Aaron On 11/16/05, Erik Daughtrey [EMAIL PROTECTED] wrote: Hey David, I'll start working on these items. erik On Wednesday 16 November 2005 03:24, David Jencks wrote: It would be good if we could get the installer working well for 1.0. Here are some of the things I think need to happen. 1. The necessary izpack jars need to get into some maven repo, preferably a public one such as ibiblio. They might be on there way there already, otherwise we should figure out which jars are needed and file an upload request. 2. Installer building should occur in its own module in assemblies. It would be best if the installer can be built using a maven plugin, but if that seems impractical we can use a bunch of jelly for now. There is an izpack plugin but I think it is maven 2 only (??). 3. The installer currently has a page where you check the major features you want, and on the following pages you configure them. This seems like a basically acceptable paradigm to me, but there is a problem in that all the following pages display even if they are empty. I've been told that moving the createForPack
[jira] Created: (GERONIMO-1188) Get necessary izpack jars into Maven repository for access during build
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] Created: (GERONIMO-1189) 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 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] Created: (GERONIMO-1190) usability: Install should not display configuration screens for packs not being installed
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] Created: (GERONIMO-1191) Installer should not allow conflicting configuration information
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 Environment: Installer runtime -- all platfoms Reporter: erik daughtrey 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] Created: (GERONIMO-1192) Installer should create a config.xml for the target install
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 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-1193) Installer should include schema files for components included in the install target
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
Re: Contributors permission in JIRA
Do I have enough Karma to have JIRAs assigned to me? Specifically, I'm interested in 1188-1193 for the installer. Regards, erik On Tuesday 01 November 2005 18:24, Dain Sundstrom wrote: Since on one objected, I added a geronimo-contributers group that can assign, resolve and be assigned issues. If this is becomes an issue the group can be removed just as easily as it was added. If you are a contributor (i.e. you have submitted some patches) and would like to be able to be assigned issues, let us know and we can grant you karma. Please, only ask if you have actually contributed and need the ability to work on issues. Thanks, -dain On Oct 28, 2005, at 11:11 AM, Dain Sundstrom wrote: I'd like to create a geronimo-contributors group in jira. We would give contributors permission to assign, move, and resolve issues but not close them. This will let the committers know what everyone is working on, and will hopefully help those working on earning commit get used to JIRA. What do you think? -dain -- Regards, Erik
[jira] Created: (GERONIMO-1194) Installer should only install packs(features) selected at install time
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 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
