TODO: Easy Install Process

*PLEASE KEEP THIS THREAD ON TOPIC*

To make the software as easy to use as possible, it needs to be as easy to install as possible. if we can compress it to one 'executable' type file that would be ideal. is it possible to accomplish this with a .jar file?

To make it easy to roll out new builds, we need to setup a build system with Ant to automate it.

these look helpful:
[www.javaworld.com]
[ant.apache.org]

Also, if it is not possible due to include Java3D in the standalone app, then we may need to look into porting to JOGL. Art of Illusion distributes a JOGL library, and we should probably emulate them as they are a model for a successful, open source, java 3D program.

Edited 2 time(s). Last edit at 05/15/2007 08:52PM by Zach Hoeken.

I decided that I should also try and get familiar with the java stuff. I researched a bunch of things and attempted to write a build script for ANT.

anyway, it went pretty well. i was having troubles with it failing on java3d, but i found out how to do classpath stuff and fixed that problem.

unfortunately its failing on OSX. this is quite the bummer. the reason this time is due to java comms api not supporting OSX!! talk about lame. however, i've discovered this package called RxTx that is supposed to be a drop in replacement for the java comms stuff. and it supports all platforms. it looks like it would be worth investigating at some point in time.

for now, i guess i'll just get it working on my linux install and use the normal comms api.

anyway, heres my build.xml file. all the .jar files will need to be added to the repository if they arent already.

Hi all,

here is a tiny startup batch file for windows. It assumes compiled classes are in "classes". If we have a build file in place it can be easily adapted to a new directory structure. It should go to a "bin" directory. It is also prepared for log4j support, which I would like to add as well.

I can provide a bash version but I have no ability to test it here.

Regards,
Alex

ZachHoeken Wrote:
-------------------------------------------------------
> To make the software as easy to use as possible,
> it needs to be as easy to install as possible. if
> we can compress it to one 'executable' type file
> that would be ideal.
-------------------------------------------------------

It depends on your platform. "Ideal" is really what the users of each computing device expect and are familiar with. So for Windows it may well be a standalone .exe installer file, for Linux one or more .deb or .rpm files, of a quality that allows them to be in a well known online repository and so available to apt-get or yum or whatever, for FreeBSD it could mean getting the code into the ports collection...

A .jar containing the java code itself is a good way to go, IMO, but is not the expected or normal software distribution model end users will be familiar with on any common "PC" platform -- such a .jar file would presumably be installed into an appropriate location by whatever install mechanism is relevant, from inside a .deb or .rpm in an online repository in the case of Linux, from a .exe installer in the case of Windows, a .pkg installer inside a .zip or .dmg file for OS X. (Ask yourself: does the average Windows user know what to do with a .jar file? Or the average OS X user for that matter?).

I'm becoming interested in attempting a .deb package, for SDCC (should be simple to do) and then for the reprap host code (a bit harder). Probably for Ubuntu 7.04 initially. SDCC is only useful to developers, I know, but at the moment all reprap users *are* developers anyway, it seems!

I'm thinking there could be 4 packages per platform: for example, reprap-host.deb, reprap-firmware.deb, reprap-mechanics.deb, reprap-electronics.deb. The last two just put the relevant files in a standard place, probably under /usr/share/reprap/ or similar. Then you can make a meta-package reprap.deb which requires all the other 4, and a single command

apt-get install reprap

"does it all for you". Or a single install of the "reprap" package using a graphical package manager pulls in all the other required stuff. Obviously in the Windows world this model breaks down somewhat, you either need 4 .exe file installers, or just one big one!

Later, we might end up with alternatives reprap-host-gui.deb and reprap-host-cli.deb, either of which provide the reprap-host capability... and so two meta-packages, reprap.deb and reprap-cli.deb or similar.

For packaging up the Java stuff, fully understanding how redistributable the needed libraries (Java3D and the Comms stuff) are or are not is key. As a preliminary step, a .deb that goes out and grabs them over the Internet at its install time might be a partial workaround for that (poor design, because it needs live Internet access at time of install -- but still more convenient than what we have now!), until replacement libs which are fully redistributable are found and can be incorporated into the codebase. Porting to the [www.rxtx.org] code for serial comms looks appropriate to me, but I'm not an expert.

One more (blue sky) thought on ease-of-install: longer term, a bootable livecd that has all the relevant software already on it (including AoI and Kicad) could be an interesting way to eliminate the "install" process completely ... in theory it could even boot you directly into the reprap host GUI :-)

Jonathan

i think you hit it on the nail there.

the best/easiest route would be to follow the example of Art of Illusion. the way they distribute their software makes it very easy to install.

i dont have any experience making an installer for any of these operating systems, which is why i am asking for help here. seriously, if you're interested in this project and you'd like to help out, just dig into the code and get this thing working.

also, i looked into the Java3D license stuff, and basically it says we can redistribute it with our code!!!

[download.java.net]

2. Subject to the terms and conditions of this Agreement and
restrictions and exceptions set forth in the Software's documentation,
You may reproduce and distribute portions of Software identified as a
redistributable in the documentation ("Redistributable"), provided that:

(a) you distribute Redistributable complete and unmodified and only
bundled as part of Your Programs,

(b) your Programs add significant and primary functionality to the
Redistributable,

(c) you distribute Redistributable for the sole purpose of running
your Programs,

(d) you do not distribute additional software intended to replace any
component(s) of the Redistributable,

(e) you do not remove or alter any proprietary legends or notices
contained in or on the Redistributable.

(f) you only distribute the Redistributable subject to a license agreement
that protects Sun's interests consistent with the terms contained in
this Agreement, and

(g) you agree to defend and indemnify Sun and its licensors from and
against any damages, costs, liabilities, settlement amounts and/or
expenses (including attorneys' fees) incurred in connection with any
claim, lawsuit or action by any third party that arises or results from
the use or distribution of any and all Programs and/or Redistributable.

i would be in favor of switching to rxtx, mostly due to the fact that its osx compatible. apparently its supposed to be a drop-in replacement for the java comms api. should be pretty rad.

I suspect the average user doesn't know what to do with nudegirls.jpeg.exe

Fortunately, Norton and McCafee do.

If it's blue-sky, then presumably it's also 2.0. I'm for sticking that "live CD" in a memory stick, that's part of the reprap itself.
I've long felt that the drivers for USB components should be part of the component, whenever possible. So far, I've only encountered thumbdrives that are so equipped.

The bootable USB key idea could work, but not for older PCs with no boot from USB capability in their BIOS. Especially if we expect a non-3D-GUI-dependent host at some stage, it would be a pity to then limit the "easy" way to those with access to recent PC hardware. Once you have a liveCD image, making it into a bootable USB key image on a modern PC isn't that much extra work. The small Linux distros like DSL and Puppy and so forth have shown they way in that area.

On blue-sky being ~= 2.0: I suppose so. This is more a matter of who has the inclination and available developer time than on their being any significant new technology hurdles to cross, though -- put a couple of good people on it full time and it could be done in a few weeks... and no, I'm not available to test that theory, I need my paycheck!

Incidentally, when is the expected official RepRap "1.0" release date?? Is there one? Or does it release "when it's ready"?

Jonathan

i think the idea is to gradually get everything going, and then make an official announcement when its ready =)

There is sort of a timetable... DarwinTodo on the Wiki . See [www.reprap.org] . I think?

Actually that page seems to suggest that some pages, including RepRapLinuxSoftware, are already considered "frozen"... and I just edited that one! Hope it's OK!

Jonathan

i think its fine... basically the idea is that we dont make any drastic changes after its frozen. fixing bugs and such is completely fine (and encouraged)

Progress report...

I have made a Reprap.jar file, and it apparently works (it runs, at least). Both the Java3D and the serial comms libraries are external to it, so they can be packaged separately, and so the same .jar could (possibly? not tested!) be usable on multiple platforms.

I also used the [www.rxtx.org] (gnu.io) serial libs instead of the Sun ones, and they "work" -- well, the resulting code compiles to bytecode OK, and the resulting .jar file runs. I have no Reprap electronics yet to test real serial i/o with.

Next steps? Probably .deb packages for Java3D, rxtx, and the RepRap host software. At that point, RepRap software installation becomes a matter of installing software as "normal" for Linuxians, rather than the decidedly lengthy set of instructions we currently have.

Jonathan