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.
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.
I have a general question about the usage of the BOM from JBoss and WildFly.
Is the a way to build a project for both JBoss 7 and WildFly 10 using a different profile?
I tried to copy the BOM definition from WildFly into a profile like this:
<profile>
<id>WildFly10</id>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-javaee7-with-tools</artifactId>
<version>${version.jboss.bom}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- JSON -->
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>${version.json}</version>
</dependency>
</dependencies>
</dependencyManagement>
</profile>
Of course accourdingly with a JBoss7 profile.
But this way it won't add important libraries to the lib folder, i.e. this definition is in an ear pom and a subproject (war) adds the json dependency. Without a profile maven adds the json jar inside the lib folder, but not if I put it inside a profile.
After I read that changing dependencies in a profile is an anti-pattern [1] I would like to know how I can build my project for both JBoss7 and WildFly 10.
Update
Ok sorry for this quick shot of a question. Here are more details.
project structure:
|-parent (pom)
|- myapp (war)
|- core (jar)
|- deployment (ear)
So deployment is the project building the whole ear containing myapp as a web apllication and core as a library. myapp has a dependency to core and core to json.
In order to have all needed depenedencies with the correct version I included wildfly-javaee7-with-tools in the dependencyManagment. Also is the version of json defined in there. The core project has the json library as a normal dependency.
At this point this should be quite standard. But the thing is I want to be able to build for JBoss 7 and WildFly 10, for what I have to change
<dependency>
<groupId>org.wildfly.bom</groupId>
<artifactId>wildfly-javaee7-with-tools</artifactId>
<version>${version.jboss.bom}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
to
<dependency>
<groupId>org.jboss.bom</groupId>
<artifactId>jboss-javaee-6.0-with-tools</artifactId>
<version>${version.jboss.bom}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Of course ${version.jboss.bom} will be changed from 10.1.0.Final for WildFly to 1.0.7.Final for JBoss.
In order to do so I tried to move wildfly-javaee7-with-tools into a profile. My first guess was to only move this dependency to a profile. But then the json jar doesn't get included. After that I also tried to move jsonlike above.
Without seeing the original not-profiled nor profiled pom in whole cannot say anything accurate but educated guess.
You have json in profiles dependency management.
Is it also in poms main dependencies without version? If not it will not be copied to lib nor packed. It is only managed by profiles <dependencyManagement>.
Does json need managing per profile? It seems to have ${version.json} which then anyway would be same for each profile if copied as it is in the example.
For me it seems that fix might be that you remove the json from profiles dependencyManagement and add it to main dependencies as normal dependency - this just to make profiling more simple - it can be managed but if not needed set the version of json directly to dependency.
From the Spring Boot documentation:
To build a war file that is both executable and deployable into an external container you need to mark the embedded container dependencies as “provided”.
Which looks like this:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
However various tomcat packages still remain as dependencies (and thus show up in my /lib folder), namely:
tomcat-embed-el (a dependency of spring-boot-starter-validation)
tomcat-jdbc (a dependency of spring-boot-starter-jdbc)
Since I will only ever need to deploy my application inside a container and never to run it standalone, how should I proceed with disposing of these dependencies?
P.S. It seems that the first dependency issue is fixed in 1.4.0.M2, see
https://github.com/spring-projects/spring-boot/issues/5454
How can we find which release of OSGi is supported by CQ5.5 version, Is there any log file where i can find out the OSGi release in the CQ5 product?
CQ5.5 uses Apache Felix which is
... a community effort to implement the OSGi R4 Service Platform and other interesting OSGi-related technologies under the Apache license
The references to OSGI in the javadocs at dev.day.com point to R4 v4.2 specifically. This matches the compliance tests for the felix project
If you're building against the OSGI APIs in your application, then you'll need to add the following to your project pom.xml (assuming you're using maven):
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>4.2.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.osgi</groupId>
<artifactId>org.osgi.compendium</artifactId>
<version>4.2.0</version>
<scope>provided</scope>
</dependency>
in CQ 5.6 we don't use the org.ogsi dependencies anymore. instead we have (amongst others)
<dependency>
<groupId>org.apache.sling</groupId>
<artifactId>org.apache.sling.commons.osgi</artifactId>
<version>2.2.0</version>
<scope>provided</scope>
</dependency
also you have (again in 5.6, not sure about 5.5) a depfinder
http://localhost:4502/system/console/depfinder
here you can see which package/version a certain class you need belongs to.
The implementation of OSGi used by CQ is Apache Felix, which implements OSGi Service Platform Release 4.
You can find out more detail about CQ's Technical Foundation at http://dev.day.com/docs/en/cq/5-5/exploring/concepts.html
I am trying to port a project from Jboss 5 to Jboss 7. I have these dependencies in Maven under dependency management in pom.xml:
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-system-jmx</artifactId>
<version>5.1.0.GA</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-system</artifactId>
<version>5.1.0.GA</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-j2se</artifactId>
<version>5.1.0.GA</version>
<scope>provided</scope>
</dependency>
What would be the corresponding Jboss 7 dependencies?
It seems that the name of the groupid has changed to org.jboss.as but the included artifacts don't have the same names. Are they included in other artifacts?
The core of JBoss 7 was completely rewritten since JBoss 5.
If you had dependencies on jboss system, you'll probably need to re-evaluate them to see why you needed them in the first place and what it could correspondend to in JBoss 7.
Start with the nexus search at:
https://repository.jboss.org/nexus/index.html#nexus-search;gav~org.jboss.as~~~~
You can do a classname search there as well.