Yeah, having looked at both, the "Windows" look is obviously ok for Windows and probably ok for Linux (since Linux installers usually look and feel like ass anyway), but for OS X having a real pkg installer would be best.
Here's another topic for discussion...when installing JRuby in a global location, should we force all installed binaries to have the "j" prefix? MacRuby does this already with "macgem", and it's just a matter of twiddling a default in RubyGems to make it install all scripts with a "j" prefix. So you'd install "jruby" somewhere global, it would have its own gem root, and all executables it installs would be "jrails", "jspec", "jwarbler" and so on. I don't know of a better way to avoid the inevitable conflict between JRuby and other Ruby installs on the same system. It's a systemic problem for Ruby and RubyGems, of course. - Charlie On Tue, Jul 21, 2009 at 8:28 PM, Yehuda Katz<[email protected]> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
