Do you think we might be able to package JMRI as a JavaFX application? As of JavaFX 2.2, Oracle has bundles cross-platform application packaging into the JDK. (see https://blogs.oracle.com/talkingjavadeployment/entry/native_packaging_for_javafx).
On 29 Jul 2012, at 13:05, david d zuhn <zoo@...> wrote:
> I've been using a CloudBees hosted instance of Jenkins for a little
> while now, testing out hosted Continuous Integration.
> You can check out what I have so far at https://jmri.ci.cloudbees.com/
> Why do this? Well, a few different reasons.
> First of all, if I can push off the administration of a Jenkins
> instance to professionals, I'm happy with that. This is normally a
> for-pay service at CloudBees, but they support Free/Open Source
> Software projects with free CI services.
> Second, I might get the system load off of my box at home. It's a 5
> year old Mac mini, and the rest of family is starting to do more with
> this machine, and thus the Jenkins work is being noticed. It's not an
> end-of-the-world situation, but anything I can do to resolve this is
> for the better.
> Next, the hosted CI is being run on Linux systems. This allows me to
> run a virtual X server (Xvnc) for each build, and to run ALL of the
> tests, not just the headless tests. So we can get better CI test
> coverage. But it also means that we might see more errors for a
> little while, until we get the environment squared away.
> Lastly, by moving this resource to a hosted service, we'd be
> future-proofing the JMRI project from my direct management of the CI
> services. I think we (as a project) have seen value from these
> builds, and while I'm not planning on leaving, I'd rather not be a
> sole-source bottleneck in the release process. As such, if I move
> the primary CI engine to CloudBees, I will be asking for a few
> volunteers to become co-administrators of the CI engine.
> There are a couple of downsides to this configuration, at least as it
> stands today. Both are tied to the installer packages.
> I am still exploring how to provide the NSIS installer creation
> software for making the Windows .exe packages. This doesn't look like
> anything beyond configuration work, so while I can't create a Windows
> installer today, I don't expect serious problems making this work.
> The hard one is dealing with Mac OS X packages. Right now, the CI
> engine is hosted on Mac OS X, so it has the appropriate software
> installed to manipulating .dmg disk images. No problem. But Linux
> does not have this software available. There are other tools for
> working with the .dmg files which are available for Linux. But these
> do not create the compressed disk images we have today, and (far more
> importantly) they require root permissions to mount disk images. We
> would not have root permissions at CloudBees, and not likely at any
> other hosted CI service either.
> A couple of possible solutions to this:
> Split the CI services -- run the regular tests, FindBugs, and such on
> the CloudBees server and the installation package creation on my
> server. This would move most of the CPU intensive work to the hosted
> site. But it would mean we have two servers to monitor. This is the
> easiest move to make, and is fairly likely as a minimum change that is
> likely to occur.
> Find another CI hosting service -- one that runs on Mac OS X would be
> best. I'm not holding my breath for even finding such a service.
> Unless we find a JMRI developer with spare CPU cycles on a personally
> owned Mac. I'd be willing to help someone set up the service.
> Change the Mac OS X installation mechanism to create a zip file
> instead of a .dmg file. Creation of the zip file is completely cross
> platform, and results in a distribution file that pretty closely
> matches the .dmg file in size (the Linux created .dmg file is
> significantly larger).
> david d zuhn Saint Paul Bridge & Terminal Ry.
> zoo @ stpaulterminal.org
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> Jmri-developers mailing list