In the Readme-File of the jboss-client, it says:
Maven users should not use this jar, but should use the following BOM dependencies instead [...]
<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-ejb-client-bom</artifactId>
<type>pom</type>
</dependency>
In the Maven Repository, there are several different versions of jboss-as-ejb-client-bom. Unfortunately, there is no indication in the readme, which version of this artifact to use.
When using JBoss libraries, I usually declare this dependency in the pom.xml's dependencyManagement section in the version corresponding to JBoss server version:
<dependency>
<groupId>org.jboss.bom</groupId>
<artifactId>eap-runtime-artifacts</artifactId>
<version>7.0.0.GA</version>
<type>pom</type>
</dependency>
In the eap-runtime-artifacts BOM, the jboss-as-ejb-client-bom is not managed, thus I need to specify a version. As there is also no version 7.0.0.GA of the client, I am not sure which version to use. So, my questions basically is:
Do I have to use a specific version of jboss-client (artifact jboss-as-ejb-client-bom), depending on which version of JBoss server (artifact eap-runtime-artifacts) I use? If so, where do I find the corresponding versions of client and server?
Related
How to use the Liberty's distributedmap feature in a Java application?
Where I can find the required Maven dependencies (com.ibm.websphere.cache..)?
The Maven dependencies for WebSphere features like the DistributedMap are defined in the https://github.com/WASdev/ci.maven.tools repository and they are published on Maven central.
The following dependency loads all APIs:
<dependency>
<groupId>net.wasdev.maven.tools.targets</groupId>
<artifactId>liberty-apis</artifactId>
<version>${liberty.dependency.version}</version>
<scope>provided</scope>
<type>pom</type>
</dependency>
The Maven coordinates for the distributedMap API would be:
<dependency>
<groupId>com.ibm.websphere.appserver.api</groupId>
<artifactId>com.ibm.websphere.appserver.api.distributedMap</artifactId>
<version>2.0.68</version>
</dependency>
Each release of Liberty will have a different version, but that is from 22.0.0.9 the latest version as of this response. I found this by using search.maven.org and searching for distributedMap. This should work for other features APIs as well.
We are upgrading openam to version 13. I've set artifacts version to 13.0.0 but when I start building the service with Maven I get a error message saying:
failure to find org.forgerock.openam:openam-oauth2-common:jar:13.0.0.
We are using forgerock repository: http://maven.forgerock.org/repo/repo/
Question: why the dependency is suddendly not available any longer and how to properly upgrade it?
It appears that the artifact you were using has been refactored, moving from a single project (i.e. a library) to a multi-module project (several modules, several libraries). Hence, although its Maven coordinates have not changed (GAV, GroupId, ArtifactId, Version), the usage (the consumption) of this library has been directly affected because its type has changed (again, from jar to pom).
Version 11.0.0, for example, was a jar, hence you could import it as most of the Maven dependency, via a dependency section.
However, since version 12.0.0, the artifact is a pom defining the following modules:
<module>oauth2-core</module>
<module>oauth2-restlet</module>
<module>openid-connect-core</module>
<module>openid-connect-restlet</module>
<module>oauth2-oidc-test-server</module>
Hence, what previously would have been:
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openam-oauth2-common</artifactId>
<scope>provided</scope>
<version>11.0.0</version>
</dependency>
It cannot be simply upgraded via its version number but must be replaced via several dependencies (you can now narrow down what you actually need):
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-core</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-restlet</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openid-connect-core</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>openid-connect-restlet</artifactId>
<version>13.0.0</version>
</dependency>
<dependency>
<groupId>org.forgerock.openam</groupId>
<artifactId>oauth2-oidc-test-server</artifactId>
<version>13.0.0</version>
</dependency>
Most probably version 11.0.0 is provided as a subset of the dependencies above, including them should fix the issue (but you could also investigate later on which one is effectively required by your project, e.g. the last one, oauth2-oidc-test-server, is most probably not required simply looking at its artifactId name, as an immediate guess).
I was using net.sf.jasperreports as the group for the version 3.6.0.
<dependency>
<groupId>net.sf.jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>3.6.0</version>
</dependency>
For some reasons, I was asked to downgrade to the version 3.5.2.
<dependency>
<groupId>jasperreports</groupId>
<artifactId>jasperreports</artifactId>
<version>3.5.2</version>
</dependency>
When I have taken a build it is observed that some of the jar files are missing like,
jcommon-1.0.15.jar
jdtcore-3.1.0.jar
Can anyone please explain me why this is happening. Are these jars are coming from net.sf.jasperreports? Please explain the difference between using groupids jasperreports and net.sf.jasperreports.
I'm pretty sure this is an inheritance from older maven conventions. The name of the groupId is merely an identifier and as such it only really has to be unique in the context it is being used. Se also http://www.mail-archive.com/users#maven.apache.org/msg34557.html
That means that as long as you don't use any dependencies outside of your own local repository (and stay offline), you could duplicate names of dependencies in maven central, for instance junit, primefaces or whatever.
So version 3.5.2 of jasperreports simply used artifactId as groupId (or vice versa), but later versions changed groupId to net.sf.jasperreports.
Dependencies between versions change, so it's pretty natural some artifacts "disappear" if you downgrade. If your project depends on these artifacts, you should explicitly define these as dependencies in your POM.
I have the following dependency (only so far) pom.xml
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.6.2.RELEASE</version>
</dependency>
This dependency obviously depends on other "dependencies" via it's pom.xml... when maven finished downloading these dependencies I noticed that it didn't grab the latest version of the Spring stuff (4.0.6.RELEASE)... it grabbed a 3.2.x version.
How can I force maven to grab the latest version of the Spring stuff? Do I need to explicitly modify my pom.xml to include all the dependencies or is there some "magic" I can use for this?
Thanks.
Spring "Bill Of Materials"
Salvation may come from special "bill of materials" POMs supported by Maven and published by Spring. Quoting from Maven "Bill Of Materials" Dependency in their manual:
It is possible to accidentally mix different versions of Spring JARs when using Maven. For example, you may find that a third-party library, or another Spring project, pulls in a transitive dependency to an older release. If you forget to explicitly declare a direct dependency yourself, all sorts of unexpected issues can arise.
To overcome such problems Maven supports the concept of a "bill of materials" (BOM) dependency. You can import the spring-framework-bom in your dependencyManagement section to ensure that all spring dependencies (both direct and transitive) are at the same version.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.0.6.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Would this work for you?
Looking at the spring-data-jpa artifact pom file, we can see that it has a parent called spring-data-parent with current version 1.4.2.RELEASE. It's pom describes dependencies and their versions. Currently spring version is at 3.2.10.RELEASE
One way you can possibly accomplish what you want is to add explicit dependency on spring artifacts. But you would still have to define their versions.
I have a maven application that will be deployed to JBOSS 5.1 as a war. I want to know how to get it so that Maven can use the JBOSS 5.1 jars (i.e. all the jars in the common/lib folder and any other resources available to JBOSS at runtime) at compile time but not bundle them into the war file.
I thought I could just include some kind of JBOSS dependency with provided scope to do this however I can't find such a dependency. I have done a good bit of searching and can't really find such a dependency. There are a lot of references to pointing to a central JBOSS repository and pulling dependencies from there. I thought there would be just one global dependency that would include all JBOSS runtime jars. Os there such a thing?
If you need more than the standard Java EE API like JBoss packages or resolve some compatibility problems, you can use this dependency :
For JBoss / Java EE 7 Specification APIs
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-7.0</artifactId>
<version>1.0.1.Final</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
For JBoss / Java EE 6 Specification APIs
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>3.0.2.Final</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
For JBoss WildFly 8.2.0.Final complete runtime dependencies
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-parent</artifactId>
<version>8.2.0.Final</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
Now, you can also use those POM files to extract the specific dependencies you need.
This could be useful in remote debug time to let your IDE resolve automatically the server dependencies jars and sources currently loaded, or appearing in stacktraces ... in development mode.
In a production MAVEN build, you probably just need this kind of configuration (depending on your JBoss version) :
http://www.mastertheboss.com/jboss-server/wildfly-8/maven-configuration-for-java-ee-7-projects-on-wildfly
Considering JBoss is an EE container, adding the JavaEE dependency should be enough.
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
Scope provided ensures that JBoss's own libraries are used once the application is deployed to the server.