Installers - Githubissues

alexanderkoller commented 6 years ago

Make sure that the installer infrastructure works correctly, and document it.

alexanderkoller commented 6 years ago

There is a directory "VorläufigeInstaller" in dirty-dialogos, which was not copied to dialogos.

akoehn commented 6 years ago

The VorläufigeInstaller were binaries checked into git; they did not belong there. The current installer is based on a system that was last updated in 2009 and does not reliably work across systems.

If nobody else is working on an installer, I would add an install4j target to gradle; this seems to be the best solution. While not free software, install4j is free for open source software: https://www.ej-technologies.com/buy/install4j/openSource

alexanderkoller commented 6 years ago

Sounds great. Can install4j be configured so it downloads Java if it isn't installed yet?

akoehn commented 6 years ago

Yes, that is supported by install4j. I contacted them and have license keys for developers. If I procrastinate tomorrow, I'll build the installer infrastructure.

akoehn commented 6 years ago

Ok, I built the first version of an installer. install4j can also download additional components such as model files. Might be useful if the download becomes too large.

I'll check something in once the gradle plugin works.

alexanderkoller commented 6 years ago

Hi, could you check in the installer generator soon? It would be cool to close the issue, and I'd like to understand the relationship to #49.

akoehn commented 6 years ago

Yes, once I'm back from vacation.

Re #49: You can define sets of files for optional installation, e.g. German or English language files. The installer then asks whether to install the components via checkboxes.

These components can be defined as bundled (i.e. they are contained in the installer but not always installed) or downloadable. In the downloadable case, an HTTP directory has to be defined in which all components generated by install4j are stored.

akoehn commented 6 years ago

Should we ship the individual classes or combined jars? Any preferences?

timobaumann commented 6 years ago

one fatjar is probably most convenient.

akoehn commented 6 years ago

There is now an install4j branch including the install4j configuration file.

Open that using install4j and build the installers. It currently builds a windows installer and a Linux installer. Currently only installs the fatjar and the startup script as well as the uninstaller.

You can select to install an english language component but that just does nothing atm, it's just there to show how it looks. The components can either be bundled or downloaded on demand. If they are set to be downloaded, install4j will generate the files that need to be uploaded somewhere.

The windows and mac installers can be configured to install a jvm if needed but I didn't do that yet.

Is there a .ico file we could use somewhere?

akoehn commented 6 years ago

There is now an installer downloadable available here: http://tmp.chark.eu/dialogos/DialogOS_unix_2_0.sh

The files to generate the installers are in the install4j branch. A python script downloads the list of models from http://www.coli.uni-saarland.de/~koller/dialogos/models/pocketsphinx.json and then downloads and extracts all models. Currently, that file is not valid and needs to be updated.

The language files are downloaded on demand and installed to {user.dir}/.dialogos in the appropriate directory.

timobaumann commented 6 years ago

I was expecting ./gradlew install4j from what's written above but that doesn't work. Can you add more instructions, possibly in the Wiki?

timobaumann commented 6 years ago

also, if izpack isn't used anymore, can we remove that directory (and dependency in build.gradle)?

akoehn commented 6 years ago

I didn't work on the gradle part after completing the install4j config file. Instead, I just used the GUI to build the installers. I don't want a missing install4j install to interfere with the other gradle tasks and haven't looked into what to do to make it work.

izpack can be removed.

timobaumann commented 6 years ago

I have rebased the install4j branch and pushed that to my fork. I've made a few changes:

got rid of shadowJar in build (causes problems here and for jitpack as well)
turned all plugins into components so that they can be selected at install time.
I find install4j good enough for model installation, don't see the need for ModelLoader functionality from within DialogOS.

Some questions:

is there some form of gradle integration of install4j that would automatically put dependencies into lib/ and on the classpath? Ideally by gradle component?
can components be hierarchically ordered in the installer? (i.e.: Pocketsphinx -> indent corresponding model components)
how does the net installer work?

timobaumann commented 6 years ago

also: I haven't checked thoroughly which components depend on what jars in lib/. Just a few obvious ones (everything usb → NXT, ...). There's probably room for smaller downloads there.

akoehn commented 6 years ago

re your questions:

the gradle integration only calls install4j and sets some variables for it, see install4j-gradle doc. Everything else needs to be done using gradle.
You can create folders in the File -> installation components view to sort them
it creates all relevant data, you have to set the URL under which those will be downloadable. Just rsync the results to the specified location.

timobaumann commented 6 years ago

@akoehn :

what I meant by "hierarchically ordered": can the selection of components while the user is installing be made into a tree rather than a flat list? I did not mean the file hierarchy.
~~where do I set that URL?~~ (it's in "media" for each installer)

Another idea for discussion: I see the point of @alexanderkoller that it's inconvenient to have all model files checked into our repository. How about we set up a separate repository (dialogos-install) that binds together the main repository, various plugins (sqlite, others as we remove them from the main repo) and contains the model files? That way normal people don't have to worry about downloading the files.

akoehn commented 6 years ago

@timobaumann it's right where I said it is. See Screencast

Re the separate repository: We should make sure that it is possible to build dialogos from source and use it. If all models are in the extra repo and that one is needed anyways, why bother doing it that way? Right now we host the models somewhere and have a download script. No need for a binary-only git repo.

timobaumann commented 6 years ago

ah, thank you!

the advantage of an extra repository is that it decouples installation from use in a software project. It also avoids circular dependencies:

the sqlite plugin depends on DialogOS sources (via jitpack)
a DialogOS-install repository could depend on DialogOS AND the SQLite plugin without introducing a circular dependency.

alexanderkoller commented 6 years ago

Todo: Check what happens if the dialog uses a Mary or Sphinx language whose Jar file was not installed by the installer.

alexanderkoller commented 6 years ago

Let's consolidate all documentation on how to build the installers into README.md in the dialogos-distribution repository.

timobaumann commented 6 years ago

I added some notes about our release process in https://github.com/dialogos-project/dialogos-distribution/commit/306327a084076ffc52511805d44b3794e04fed05

dialogos-project / dialogos

Installers #4