GNU/Linux packaging and integration (was "The use of AppleJavaExtensions.jar has to be an option to allow GNU/Linux distributions to build packages")

[DevDef]

I've successfully packaged Keystore Explorer as an RPM for my favorite GNU/Linux distro (i.e. Mageia), but I had to download AppleJavaExtensions.jar from Apple®™ to compile the source code. Unfortunately, Apple’s license is far too restrictive and prevents any redistribution. So, even if the resulting built RPM is free because it doesn’t contain the Apple Jar, a source RPM can’t be submitted to the various distro’s building systems because it must contain the problematic Jar to be compilable, even though this library is useless with anything but Mac OS X systems in the end. This is, IMHO, a major problem, and the use of this Apple Library by the source code of Keystore Explorer should depend on an build option, in order to compile the code without any non free elements.

With such a build option, Keystore Explorer could be imported and built in all GNU/Linux distros and distributed in their repositories for a wider visibility.

[kaikramer]

Actually, I wanted to get rid of this dependency for a while now. It should be possible by using reflection. I will look after it during the next couple of days.

[DevDef]

I’m glad to know that you were already concerned by this licensing problem. :-) You’re doing a really great job. Thanks a lot!

By the way, may I suggest you to provide an SVG version of the application icon (kse.svg)?

[kaikramer]

It's done, AppleJavaExtensions.jar is not required for compiling anymore.

The application icon was made by a professional designer a long time ago. I only have PNGs in sizes from 16x16 to 512x512 pixels.

[DevDef]

Don’t worry about the SVG... I tried to vectorize your icon by myself, but I’m really not good enough at this... :-/ I have a more important problem: the code doesn’t compile anymore. I’m screwed with 7 for-each errors in X509Ext.java looking like this:

Buildfile: /home/davy/rpmbuild/BUILD/keystore-explorer-master/kse/build.xml

init:

compile: [javac] Compiling 302 source files to /home/davy/rpmbuild/BUILD/keystore-explorer-master/kse/build [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] /home/davy/rpmbuild/BUILD/keystore-explorer-master/kse/src/net/sf/keystore_explorer/crypto/x509/X509Ext.java:592: error: for-each not applicable to expression type [javac] for (ASN1Encodable attributeValue : attributeValues) { [javac] ^ [javac] required: array or java.lang.Iterable [javac] found: ASN1Set [...]

Any hint?...

[kaikramer]

Have you replaced the Bouncy Castle v1.53 jars (bcpkix.jar and bcprov.jar) with an older version? Or maybe you have included another BC version in your Java installation? It must be something like that.

[DevDef]

Well done! I use the ones provided by Mageia Cauldron (developpement version) which are 1.52 versions, according to Mageia policy. Even Fedora Rawhide (often the most advanced GNU/Linux distro) versions are 1.52 due to other project dependencies... So, it's a pity that BouncyCastle 1.53 (or the brand new 1.54) is mandatory. What would be nice is to provide a new 5.1.2 stable release of KeyStore Explorer that would compile without AppleJavaExtensions.jar and run with BouncyCastle 1.52 jars (it matches well: 5.1.2 for 1.52, same digits in a different order ;)).

[kaikramer]

Nah, the release of 5.2 is too soon to do another release before... Anyways, KSE did not use any important new features of BC 1.53, so I have simply restored compatibility with 1.52 in the latest commit.

[DevDef]

Thank you very much for reverting to BouncyCastle 1.52 ! I‘ve finally successfully built my RPM, but I had to patch your source code in order to remove all references to Darcula, because even though it looks pretty nice, it’s not packaged in any GNU/Linux distro (and especially Mageia) and I really don’t want to add the burden of creating a specific package for it. I noticed a little strangeness: the user preferences subdirectory name:

/home/username/.java/.userPrefs/net/sf/_!'s!~@"5!(:!d!"v!()!~@"f!'`!e!"w!'w!bw"y!'`!cg==/prefs.xml

Shouln't it be one of:

• /home/username/.java/.userPrefs/net/sf/keystore-explorer;
• /home/username/.java/.userPrefs/net/sf/keystore_explorer;
• /home/username/.java/.userPrefs/net/sf/kse?

Moreover, for a better GNU/Linux integration, I think it would be interesting to default to GTK+ theme, at least for GTK+ based desktops (GNOME, MATE, LXDE, Xfce...) and keep Plastik 3D for Qt based ones (mostly KDE), as it integrates better with it, IMHO. After a rapid googling, I found that reading the XDG_CURRENT_DESKTOP environment variable should easily do the trick: http://stackoverflow.com/questions/10235117/how-to-detect-if-linux-os-uses-kde-or-gnome-environment http://askubuntu.com/questions/72549/how-to-determine-which-window-manager-is-running

Anyway, thanks for you involvement,

Davy

P.-S. : You should activate the display of spaces and tabs in your code editor/IDE to avoid mixed indentations (tabs and spaces) and trailing spaces at the end of lines. Your latest additions are using white spaces whereas the code is mainly using tabs...

[kaikramer]

Darcula is completely optional now (commit af3eee025d8a620f9874fa49da408cd6dd338fa4).

The preferences subdirectory's name should indeed be .../net/sf/keystore_explorer. It's the same weird name in my Mint installation, but fine under Windows and Mac OS. I will take a look at the issue.

As for the default look&feel under Linux: I agree that GTK+ should be the default for GTK based desktop environments, but the value of XDG_CURRENT_DESKTOP seems pretty diverse and unreliable (e.g. for KDE it is sometimes empty, sometimes 'KDE'). Still, I could set GTK+ as LaF for all known values (basically all the values from your second link but KDE) and default to Plastik for the rest.

The mixture of tabs and spaces and the trailing spaces are caused by me experimenting with IntelliJ IDEA over the last few weeks (I usually use Eclipse). Obviously the formatting settings in IntelliJ are different from those in Eclipse... Thanks for pointing that out.

[DevDef]

Once again, thank you for simplifying GNU/Linux packaging. I’m less surprised of your involvement now that I know that your a GNU/Linux user. ;) I had to patch the source to disable the test stuff too. It should be disabled by default.

I have an ultimate request (at least for now ;)): use the desktop environment file chooser, i.e. GTK file chooser for GNOME and others GTK desktop environments, and KDE file chooser for KDE, provided that you finally find a reliable way to detect the use of a KDE desktop. As I saw that you are already using the OS file chooser for Window$ and Mac OS X, I’m pretty sure it’s easily doable for GNOME and KDE...

I should also provide you my XDG keystore-explorer.desktop file to be integrated to the source code. Concerning the start script, it’s more complicated because it’s more distro specific, and it should be generated by ant. But if your are interested, just tell me...

Of course, the work will be really completed after a full localization. And, as I’m French, I will provide a French translation. :)

Davy

[kaikramer]

Compiling/running the tests is now separate from compiling the main code.

The file chooser only looks similar to the native one on Windows, but it behaves differently and if you look closely there are several minor visual differences. On Mac OS and Linux the file chooser does not even look like the native one. I am aware of that and I don't like it either, but right now other issues are more important.

I am not interested in the .desktop file (there are so many easy ways to create a launcher nowadays) or the start script (as you said it's distro specific), but I am actually interested in the rpm file. I would really like to take a look at it.

I am thankful for every contribution and a french translation of KSE would be great!

[DevDef]

I am not interested in the .desktop file (there are so many easy ways to create a launcher nowadays)

Well, this time I must disagree. The XDG file remains the most standard way to do it and, anyway, there’s no constraint to use it. But, from a GNU/Linux packaging POV, it’s clearly a must have. The idea of providing it upstream is to centralize the translations. And it also contains the MIME types to bind the file managers (like Nautilus, Dolphin, etc.) with the different kinds of file handled by a software (i.e JKS, p12, p7, pem...). keystore-explorer.desktop.zip

I will provide you my RPMS (the source RPM for building) and binary too, but I have to rebase them from your latest changes and that means to rediff the patches...

Is your code already ready for localization? I ask because I have no experience in Java l10n, my translations are usually gettext po files. But I know someone that could help me with the Java bundle stuff...

Davy

[DevDef]

One more note about the patch: As I build KSE with my distro’s JARs, some of them have different names:

• JavaHelp is javahelp2.jar, so the trick is to patch the build.xml to rename jhall.jar as javahelp2.jar ;
• MigLayout is a unique JAR miglayout.jar, whereas you have 2 separated JARS: miglayout-core.jar and miglayout-swing.jar, so the patch removes those two JARs and add miglayout.jar

I would prefer doing this differently, with some ant parameters, but I failed for now... :-/ keystore-explorer-5.2.0-rename-needed-jars.patch.zip

[kaikramer]

That was a misunderstanding, I wasn't saying that XDG .desktop files are the wrong way to do it, I was just saying that there are many tools to quickly and easily generate them. For example one can extract the KSE ZIP distribution file somewhere, right click on the desktop, select "Create launcher/shortcut" (or however it is done in the respective DE), select kse.sh as command, select the application icon and that's it. Of course that generates a much simpler .desktop file than the one you wrote, but it might be enough for many users. However, I like the idea of centralizing translations and MIME-bindings.

Yes, KSE is ready for localization. All display texts are in resource bundles (resource.properties in the various sub-folders).

[DevDef]

OK, I’m glad to read that it was just a misunderstanding. :-) So, as I promised, here is ZIP containing a source RPM (all the needed stuff to build a binary RPM) based on your latest code and a resulting built RPM. keystore-explorer-5.2.0-0.git20160107.1.mga5.zip

Now, I have to take a look at the bundles French translations...

[kaikramer]

Thanks for the RPMs. Be warned that there are more than 10.000 text snippets to translate. That might be a bit too much for one person. However, many strings are something like "Authority Key Identifier Extension" which might not be worth translating.

I have found the reason for the strange directory name (.java/.userPrefs/net/sf/_!'s!~@"5!(:!d!"v!()!~@"f!'!e!"w!'w!bw"y!'!cg==): When Java creates the sub-directories, it checks for "inappropriate" characters in the directory name and if it encounters one the name is translated to alternate Base64 and an underscore character is prepended. While it is a good idea to make surethat the directory contains no problematic characters, it makes no sense at all to include the underscore character into the list of "inappropriate" characters and then prepend it after making the string "safe". Also it is rather questionable to use the alternate Base64 encoding. However, I doubt that Oracle would accept a bug report for that and as I cannot simply change the package name, there is not much I can do about it.

[DevDef]

Translation is in progress. It will take a while to fulfill, step by step... You shouldn’t have told me that there were 10,000 strings to translate, it is discouraging. ;-) I found some strings (the 5 first strings) in this file https://github.com/kaikramer/keystore-explorer/blob/master/kse/src/net/sf/keystore_explorer/resources.properties that shouldn't, IMHO, be part of translations and sould rather be defined as static strings in a class:

KSE.Name=KeyStore Explorer KSE.SimpleName=kse KSE.Version=5.2 KSE.SimpleVersion=52 KSE.AppUserModelId=SourceForge.KeyStoreExplorer52

Concerning the strange user preferences directory name, I've found a very old bug report from 2002 considering it’s not an issue and won’t be fixed: https://bugs.openjdk.java.net/browse/JDK-4696941 IMHO, it’s a shame that it hasn’t been considered an issue as it really hurts the eyes!

Of course, renaming the package from keystore_explorer to the more compliant (though not very elegant) name "keystoreexplorer" could be a simple way to fix this (using the powerful refactoring function of Eclipse). I wonder if the package’s prefix should even be renamed according to where the code is now hosted, i.e.: "com.github.kaikramer.keystoreexplorer". WDYT?

[DevDef]

French translation completed (except the help and HTML pages)! \o/ I haven’t tried to recompile and test yet, though. I’ll try tomorrow and let you know...

I think I deserve a credit for such a hard work. ;-)

Davy

[kaikramer]

Wow, that's great news! I didn't expect the translation to be completed so soon. Well done! Of course you will get full credit for it.

I just realized that I didn't answer your last comment, so I'll do that now:

Those 5 strings have have to be in a properties file (and not in the code), because I want all version info in one place and a properties file can be accessed from both Java code and the build file. Until now there were no translations, so it was basically just a properties file. I guess I'll have to move them in a separate file now...

I'll think about changing the package name to "org.keystoreexplorer" (looks bad without a seperator), but not before the next release. I registered that domain so I don't have to change the package names again when github falls from grace.

Ah, and btw, native file dialogs are now implemented. It requires JavaFX (and probably Java 8), which unfortunately might be a problem for Linux distributions. If KSE doesn't find JavaFX, it will fall back to the Swing file dialogs. It works pretty well with Oracle Java 8 on all three platforms. There might be a way to make it work with OpenJDK 7 as well, but I haven't found it.

[DevDef]

First build was the good one! But I had hard time tweaking Git to get your very latest nice changes (GTK default :-)...) because I’m a Git rookie. Now, how can I submit my work? I don’t have permissions to push my changes...

[kaikramer]

The GitHub way to submit your work is to send me a pull request. First you have to fork my repository, then apply your changes there and finally create the pull request.

Some links about this topic: https://help.github.com/articles/creating-a-pull-request/ https://help.github.com/articles/using-pull-requests/ https://yangsu.github.io/pull-request-tutorial/

[DevDef]

Done: https://github.com/kaikramer/keystore-explorer/pull/12

[DevDef]

Hi Kai,

Apparently there’s no private messaging (any more) in GitHub, hence why I write you here because it’s kinda related and it doesn’t deserve a new issue... I’ve completely missed the release of KSE 5.2 because I was daily monitoring your commits waiting for something like “bumping 5.2 release” that has never came... I had a look on the main Web site this week-end and I saw the 5.2 release notes. So, I’ve rebuilt and submitted a source RPM of KSE 5.2 yesterday. It has been accepted and built this morning. So, as I promised, KSE is now officially included in the upcoming Mageia 6. :-) FYI, I also started to write an article about KSE on LinuxFr.org, but it’s not finished yet...

Cheers,

Davy

P.-S. : I’d like to have your e-mail address for these private discussions, if you don’t mind. I think you already have mine...