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?
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.
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.
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.
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?
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