Gradle can't seem to get ejb-client dependencies


(chris.vogel) #1

We are in the process of migrating an application from Maven to Gradle. Our project depends on other libraries from within our company, which specify their dependency as type “ejb-client” from Maven. When attempting to resolve the dependency, it seems to resolves it as “<groupId>.<artifactId>-<version>.ejb-client”, instead of “<groupId>.<artifactId>-<version>-client.jar”. Am I missing something? Is it a decision to not support EJB clients? Is it something that was just missed? Is there a suggested way to get around it?

I notice that there is not really any documentation on EJBs with Gradle. Is there something on the roadmap to do something more with them, like being able to create client jars and publish them to a Maven repository?


(Benjamin Muschko) #2

I assume you are trying to resolve a dependency with a classifier? For more information see the section “50.4.1.3. Classifiers” in the Gradle user guide.


(chris.vogel) #3

Benjamin,

Thanks for the reply, but no. I think I need to clarify. I have a dependency that has a transitive dependency that is of type [“ejb-client”] (http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html).

This is our first Gradle project at our company, so everything we are referencing outside of our project is Maven and uses things like ejb-clients.

Chris


(davidmichaelkarr) #4

I don’t know about Benjamin, but I’m wondering what exactly you mean by “type”. I made the same assumption Benjamin made, that you were talking about classifiers.

How about you show us some script and structure? We can’t see enough to help you.


(chris.vogel) #5

So, within Maven, a dependency can have a type, which corresponds to the artifact’s packaging type ([Maven doc] (http://maven.apache.org/pom.html#Dependencies)). The default for that type is a jar, but you can have things like ejb, war, or ear. With EJBs, there is a special dependency type, ejb-client ([Maven doc] (http://maven.apache.org/plugins/maven-ejb-plugin/examples/ejb-client-dependency.html)). An ejb-client artifact should really have the EJB interface and other classes needed by that interface. And, you’re right, based on the way I described it, in the Maven repository it looks just like a classifier. However, in the Maven POM, an ejb-client dependency would look like:

<dependency>

<groupId>com.example</groupId>

<artifactId>ejb-project</artifactId>

<version>1.0</version>

<type>ejb-client</type>

</dependency>

So, like I said, I’m referencing an existing Maven project from our repository (meaning I can’t really change the project POM) that has a transitive dependency on an ejb-client, like above, and Gradle is not liking it. Using the above example, I’m getting an error like:

  • What went wrong:

Could not resolve all dependencies for configuration ‘:common:compile’.

Artifact ‘com.example:ejb-project:1.0:ejb-project.ejb-client’ not found.

It seems that Gradle is taking the Maven dependency type and trying to use it as the suffix for the artifact.


(Benjamin Muschko) #6

Thanks for clarifying. I had a quick look at the parsing code and it looks like the type ‘ejb-client’ is not handled correctly. I opened an issue.


(chris.vogel) #7

Great. Thank you.

So, I assume for now we are stuck, but it should be fixed later.


(Benjamin Muschko) #8

I fixed the issue. You’ll be able to try out the fix with 2.1-rc1.


(chris.vogel) #9

Thank you. I’ll let you know.


(chris.vogel) #10

Benjamin,

So, I downloaded the nightly build yesterday and tried out your code fix. I’m still having the same problem. I did some more research into this and here is what I found:

2.0 is downloading most EJB clients. I looked at some of my other dependencies and they are using other EJB clients that are being downloaded. The problem that I am seeing is where only the EJB client is deployed to the Maven repository. Other projects have both the EJB and the EJB client in the repository. With the artifacts that I’m having problems with, only the EJB client is deployed (the project teams thought that was all they really needed to put in the repository, which is technically true). What do you think about fixing that type of behavior, as unique of a case as it might be?

Thanks,

Chris


(Benjamin Muschko) #11

Would you mind providing us with example code that demonstrates the issue you are seeing?


(chris.vogel) #12

I’d be happy to, but I’m not quite sure what you’re looking for. I’ve got a build.gradle that has a dependency and then I have a pom.xml that has another dependency that is of type ejb-client. When you look at the Maven repository for the transitive dependency, there is only the ejb-client and the pom, not the ejb jar. It causes the same error message that I mentioned above. I get this debug message:

  08:57:22.698 [DEBUG] [org.gradle.api.internal.artifacts.ivyservice.ivyresolve.CachingModuleComponentRepository] Detected non-existence of artifact 'com.edj.eReports.services:eReports:1.2.1:eReports.ejb-client' in resolver cache  

Here is the directory listing:

  -bash-3.2$ ls -la  total 68  drwxr-xr-x 2 generic generic  4096 Jul  1  2013 .  drwxr-xr-x 5 generic generic  4096 Apr 10  2012 ..  -rw-r--r-- 1 generic generic 33273 Jul  1  2013 eReports-1.2.1-client.jar  -rw-r--r-- 1 generic generic

 59 Jul  1  2013 eReports-1.2.1-client.jar.md5  -rw-r--r-- 1 generic generic

 67 Jul  1  2013 eReports-1.2.1-client.jar.sha1  -rw-r--r-- 1 generic generic  8908 Jul  1  2013 eReports-1.2.1.pom  -rw-r--r-- 1 generic generic

 52 Jul  1  2013 eReports-1.2.1.pom.md5  -rw-r--r-- 1 generic generic

 60 Jul  1  2013 eReports-1.2.1.pom.sha1  -rw-r--r-- 1 generic generic

181 Jul  1  2013 maven-metadata.xml  -rw-r--r-- 1 generic generic

 52 Jul  1  2013 maven-metadata.xml.md5  -rw-r--r-- 1 generic generic

 60 Jul  1  2013 maven-metadata.xml.sha1  

(Benjamin Muschko) #13

Can you do me a favor and delete your local cache (’~/.gradle/caches’) and try again?


(chris.vogel) #14

That did it. Thanks. Sorry for bothering you.


(Benjamin Muschko) #15

No worries. Thanks for checking!