Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PonomarSetup: Move language-specific subdirectories into .jar files? #11

Open
GoogleCodeExporter opened this issue Apr 26, 2015 · 1 comment

Comments

@GoogleCodeExporter
Copy link

PonomarSetup.exe currently has to install some 37,000 files, most of which are 
XML files. Most of these are language-specific files under the languages 
subdirectory.

Having such a large number of individual files bloats the installer's XML code. 
It probably also is responsible for the relatively long time to install and 
uninstall (a couple minutes). MSI installers/uninstallers read and write 
database entries for each file that is installed/uninstalled.

For modularity and ease of deployment, it may make sense to bundle the relevant 
language-specific subdirectories (languages/cu, languages/en, etc.) into 
separate .jar files. The installer would then only have a small number of files 
to deploy.

We could then also turn the installer into a web installer that prompts the 
user to select which language-specific .jar file(s) to download and install.

Reading an XML file that's contained in a .jar file is straightforward. See for 
example: 
http://stackoverflow.com/questions/3369794/how-to-a-read-file-from-jar-in-java

This is not a must-have feature. It could be deferred until after we've 
provided a basic installer or application bundle for each major platform 
(Windows, OS X, and Linux).

The code changes involved may be extensive (for example in the functions that 
search up and down the tree for the existence of a specific file).

Original issue reported on code.google.com by ps008v...@gmail.com on 11 Feb 2015 at 2:32

@GoogleCodeExporter
Copy link
Author

I am not sure if Jar is the best way to go for this. Perhaps the language files 
can be just made available in archives that the user loads and unzips, perhaps 
with the aid of some interface. This would also make the modularity available 
for the Perl API.

Original comment by aleksandr.andreev@gmail.com on 15 Feb 2015 at 1:41

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant