I've been pretty unimpressed with the OSX versions of both installers under consideration. Would it have been too hard to wire up PackageMaker? An OSX installer should look and smell like other OSX installers, not a reskinned Windows installer :( -- Yehuda
On Tue, Jul 21, 2009 at 6:08 PM, Micah Martin <[email protected]> wrote: > Just to be clear.... I didn't purchase Install4j. I just asked for a free > open source license. So it's no sweat off my back if you choose not to use > it. I've been meaning to chip in on JRuby for a while. I'm just happy to > help. > > The installers I built with Install4j are just quick stab, so you could get > a feel for what Install4J installers are like. They would require more work > before releasing. > > I'm curious what BitRock feels like. Daniel, could you whip up some BitRock > installers for each platform? They don't have to be complete... just enough > to get a feel for it. Then I'd suggest we try them both out and see which > option offers the best experience. Maybe a combination of both installers > for different platforms is the best route. > > Micah > > > On Jul 21, 2009, at 4:40 PM, Charles Oliver Nutter wrote: > > Since Micah already purchased and built an installer...maybe we just >> point people to both of them? I think Install4J is more focused on >> Windows, is that correct? >> >> Both options sound really great...so I don't know how to choose which >> one to make the "official" installer. >> >> My key points would be: >> >> 1. cross-platform install and *build*, so we don't need a Windows box >> to build the Windows installer, etc >> 2. options to fetch or bundle a JVM, or to select existing JVMs >> 3. "we" on the JRuby team can build installers at will, like when >> we're about to release >> 4. ideally, automated as much as possible, like part of the jruby >> "dist" ant target or a new "dist-installers" target >> >> Thanks to everyone for looking into this. What do you guys think we should >> do? >> >> On Tue, Jul 21, 2009 at 9:27 AM, Daniel Lopez<[email protected]> >> wrote: >> >>> Hi Stephen, everybody >>> >>> Do you have any (or know of any) open examples of a scripts for creating >>>> and >>>> easily maintaining a JRubyStack-type of deployment. >>>> >>> >>> We can share the JRubyStack XML project files, but since you are >>> interested just in JRuby and that is relatively straightforward, they >>> will not really help as the real complexity is in the additional >>> components of the stack. >>> >>> Some comments below regarding your notes. >>> >>> >>>> http://svn.concord.org/svn/projects/trunk/common/java/deploy/bitrock-installers >>>> >>>> and is being documented in a series of confluence pages here: >>>> >>>> http://confluence.concord.org/display/CSP/Java+Installable+Launcher >>>> >>> >>> >>> General BitRock Questions >>> >>> 1. try setting an environment variable (is a reboot needed before that >>> variable is visible?) >>> * Usually reboot is not required. A message is broadcasted that the >>> environment changed on Windows, if that is what you mean. Also, are >>> you referring to system or user-level environment variables? >>> >>> >>> 2. See if bitrock can support signing files >>> >>> Yes we do. You will need to use MS code-signing tools. You can drive >>> them from IB in a <postInstallationActionList> >>> >>> >>> http://support.bitrock.com/article/i-get-an-unkown-publisher-warning-popup-on-windows >>> >>> >>> 3. See if bitrock can support online installers that are small and >>> then download just the files that are needed. >>> >>> We do not (yet) have direct support. Though with some shortcomings, >>> you can build your own in the mean time using httpGet, we will be >>> happy to help you with that. >>> >>> Mac >>> >>> 1. Support for creating Mac packages >>> >>> We can create .deb and .rpm for Linux, but is not possible to create >>> .pkg OS X packages (only regular .app installer that you can launch) >>> >>> Java >>> >>> 1. It has actions for finding the java executable, but it doesn't find >>> the java.home just the executable. >>> >>> You can just use the parent directory of the binary as the JAVA_HOME. >>> The problem is that in some scenarios a Java binary is available but >>> no JAVA_HOME is defined, you can only guess it. Regarding this and the >>> issues you raise of environment vs. java.properties in JAVA_HOME, why >>> not simply define the variables you need in a wrapper script or >>> launcher for your application? >>> >>> 2. Common data folder across distributions >>> >>> We have now implemented in 6.2.0 ability to filter Windows XP, based >>> on your feedback. We will also implement installer variables for >>> finding out the location of data folder across operating systems (and >>> simplifying your current installer logic) >>> >>> Please let me know if there is any question I did not address >>> >>> Best regards >>> >>> Daniel >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325
