add a way to use system jars for building packages

[pravi]

As discussed in https://github.com/kontalk/desktopclient-java/pull/48 we need a way to use system jars when building a package. I found a way to mention this in build.gradle. Can we make another target linke SystemJar or something that will use system jars instead of downloading from maven?

Such jars need not be copied to dist/lib and their path should be set to system path in final jar classpath

--- ../build.gradle 2015-07-27 17:39:21.705491576 +0530
+++ build.gradle    2015-07-27 21:43:20.584702159 +0530
@@ -28,7 +28,7 @@

     compile group: 'org.bouncycastle', name: 'bcpg-jdk15on', version: "$bcVersion"
     compile group: 'org.bouncycastle', name: 'bcprov-jdk15on', version: "$bcVersion"
-    compile group: 'commons-configuration', name: 'commons-configuration', version: "1.10"
+    compile fileTree(dir: '/usr/share/java', includes: ['commons-configuration-1.10.jar','commons-lang.jar','commons-logging.jar'])
     //compile group: 'commons-lang', name: 'commons-lang', version: "2.6"
     compile group: 'commons-io', name: 'commons-io', version: "2.4"
     compile group: 'org.apache.httpcomponents', name: 'httpclient', version: "4.3.5"

[abika]

Wait, how is this done with other Java packages in Debian? AFAIK building is/should be done separate from any arbitrary Linux package management software. This is also described here and possible, for example, by overwriting the classpath in a startup script:

java -cp "KontalkDesktopApp.jar:/usr/share/commons-configuration-1.10.jar:lib/*" org.kontalk.Kontalk

So, I don't see no need for modifying the Gradle build file.

[pravi]

@abika we should be using the packaged jar files during build as well, so we need a way to do this using gradle. All java packages in debian use packaged jar files during build. All binary files in debian should have their corresponding source and built on debian.

[pravi]

see an example http://pkg-java.alioth.debian.org/examples/program/

debian/rules sets CLASSPATH to a system jar during build. For Kontalk, since we are using gradle, setting a CLASSPATH is not enough. So we need to edit gradle.build

[abika]

ok, and how is this usually done in Gradle / can you find some reference Gradle project?

Cause I really have no idea and see a bunch of problems:

• is there a way to avoid declaring each dependency twice (maybe with flavors)?
• using compile fileTree(...) seems not good, as some jars could be present in /usr/share/java twice with different versions, or in different subdirectories (unless you guarantee that this is impossible in Debian). So better use absolute paths
• following that, the build task becomes specific to Debian systems only. And we need need to maintain the same for Fedora, Arch, ...

[seamlik]

I am a member of pkg-java team, and I have some experience on packaging projects that use Gradle.

Typically I will replace the default repository to flarDir { dirs "/usr/share/java" } and maven { url "file:///usr/share/maven-repo" }, thus Gradle will search system jars automatically.

You can read some examples from our bintray-client-java and gradle. Currently only a few number of packages use Gradle, so there's no documentation on this kind of issues yet.

[pravi]

@abika , with @seamlik 's solution, we can avoid adding dependencies twice. For now, we can just patch gradle.build in debian, but if that can be added a separate task upstream that would be good. If we can detect a debian, fedora or arch system and use system jar directories accordingly that will be good.

[pravi]

@abika see this sample patch

[seamlik]

Note that with flatDir as a repository, even Gradle can't find a system jar that matches the exact version of the dependencies, Gradle will use the versionless system jars placed at /usr/share/java. You can also change the versions to dynamic ones, for example org.foo:foo:1.2 => org.foo:foo:[1.2, ) or even org.foo:foo.

[pravi]

@abika, jdeb was suggested as tool for building deb packages by upstream in debian-java discussion list

While we work on a proper deb package in debian, you could try jdeb to create a deb and host it yourself.

[abika]

ok, thanks for your help!

But as jdeb does only support Mave/Ant and cant be used with Gradle it would mean to setup another build manager, correct? Not a solution...

[pravi]

@abika you could request jdeb folks to support gradle by opening an issue.

[abika]

there is already an issue: tcurdt/jdeb#132

And another project is mentioned: https://github.com/nebula-plugins/gradle-ospackage-plugin But don't know if that solves the jar deps problem