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

add a way to use system jars for building packages #49

Open
pravi opened this issue Jul 27, 2015 · 12 comments
Open

add a way to use system jars for building packages #49

pravi opened this issue Jul 27, 2015 · 12 comments

Comments

@pravi
Copy link

pravi commented Jul 27, 2015

As discussed in #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
Copy link
Member

abika commented Jul 27, 2015

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
Copy link
Author

pravi commented Jul 27, 2015

@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
Copy link
Author

pravi commented Jul 27, 2015

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
Copy link
Member

abika commented Jul 27, 2015

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
Copy link

seamlik commented Jul 28, 2015

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
Copy link
Author

pravi commented Jul 28, 2015

@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
Copy link
Author

pravi commented Jul 28, 2015

@abika see this sample patch

@seamlik
Copy link

seamlik commented Jul 28, 2015

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
Copy link
Author

pravi commented Jul 28, 2015

@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
Copy link
Member

abika commented Jul 28, 2015

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
Copy link
Author

pravi commented Jul 28, 2015

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

@abika
Copy link
Member

abika commented Jul 30, 2015

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

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

No branches or pull requests

3 participants