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, but this is what I've thought of so far. > >>> > >>> thanks > >>> david jencks > >> > >> -- > >> > >> Regards, > >> > >> Erik -- Regards, Erik
