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 > > > > -- > > > > Regards, > > > > Erik -- Regards, Erik
