Gradle unable to find downloaded dependency packaged as OSGi bundle (non-OSGi app)

Old Forum Archive
1

(Cross posted from StackOverflow at http://stackoverflow.com/q/10589900/433348)

My (non-OSGi) application build is using Gradle 0.9, and I am trying to upgrade from an old version of Jersey (1.1.4.1) to something much newer (1.12?). I do not pretend to know much about using OSGi. But when I point my Gradle dependencies (with $JERSEY_VERSION set to “1.12”) to:

dependencies {
     compile (
             [group: 'com.sun.jersey', name: 'jersey-server', version: "$JERSEY_VERSION"],
              ... etc.

it downloads the jersey-server-1.12.jar into my Gradle dependencies cache under a “bundles” directory instead of the normal “jars” directory, and then Gradle seems to not include this jar in its classpath like it would if it were under a “jars” subdirectory instead.

I discovered it went under “bundles” because the POM has it labeled as an OSGi enabled jar (“bundle”). I do not think we are going to want to OSGi-ify our project. What can I do to get Gradle to add the newer Jersey jar to my classpath? I would prefer to not manually copy the file to a local repo if possible, but rather somehow rely on the dependency management capabilities of Gradle if possible.

I also use the “eclipse” task to generate the eclipse classpath, so I want that to be able to work as well.

2

That’s a very old version of Gradle. Dependency management has changed drastically since then. Are you able to upgrade?

3

Perhaps. My script was based off of a previous script, and I would have to figure out how to convert some usages that break in 1.x+. Will upgrading solve my problem automagically, or what would I have to do? I am fairly new at Gradle, BTW.

4

Upgrading will allow us to help you resolve the issue if it isn’t fixed automatically. It’s very unlikely we could make this work with the version you are using.

5

I updated to 1.0, and it still wasn’t solved, but found the problem – oops on my part. Upgrading to Jersey 1.12, they had rearranged/split some of their jars. I needed a couple new jersey-* jars, as the ClassNotFoundException was because the class was really not there in the bundle (I should have checked), since it got moved into one of the new jars.

Sorry to bother you.