I am working on integrating fabric8 for my application and need to add fabric8 kubernetes and openshift client as OSGI bundles. I can get them from following maven repositories as JAR archives.
https://mvnrepository.com/artifact/io.fabric8/openshift-client/2.5.7
https://mvnrepository.com/artifact/io.fabric8/kubernetes-client/2.5.7
And and have to convert them to OSGI bundles to add them to my application since my application is only supporting bundles.
Is there a way to directly get the OSGI bundles of the above jars from maven repository as dependencies without converting them and adding them to a central repository ?
There is no direct way to get OSGI bundles, we have to build it manually.
We can make it available but we have to prepare the bundle and there are plenty of tools available,
For reference:
http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
http://wso2.com/library/tutorials/develop-osgi-bundles-using-maven-bundle-plugin/
The kubernetes-client ships bundles for all its artifacts. The bundles are available on maven central and you can use them just by using the bundle classifier.
For example:
http://repo1.maven.org/maven2/io/fabric8/kubernetes-client/2.6.2/kubernetes-client-2.6.2-bundle.jar
Related
I am building a SpringBoot application in which i want to handle some of the cross cutting concerns like logging, caching, persistence in to a project on its own so in future other rest spring boot components can adopt it and use it as a dependency.
I am using Gradle for dependency management. My question is :-
How can i manage this concerns without publishing it to the public artifactory.
If i have to publish then which is the free artifactory i can use for my development practice
If creating jar is an option as a temp solution then how can it be achieved via gradle. Most of the examples over the internet is for creating the executable jar files.
What are the other options i can try.
How can i manage this concerns without publishing it to the public artifactory.
Publishing has to happen regardless where it will be published to. You can use a private solution such as Nexus Repository.
If i have to publish then which is the free artifactory i can use for my development practice
For development, you can simply publish to your local Maven repository. This is typically ~/.m2. Using the Maven Publish plugin, you can easily publish locally by invoking the publishToMavenLocal task.
If creating jar is an option as a temp solution then how can it be achieved via gradle. Most of the examples over the internet is for creating the executable jar files.
Since you're creating a Spring Boot library, use the Java Library plugin to create the JAR artifact and in combination with the Maven Publish plugin to publish.
In the end, there are 2-3 key components that get published when using Gradle:
JAR artifact
pom.xml: https://maven.apache.org/pom.html
Gradle Module Metadata: https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html
I want to deploy a Java & Maven micro services application on OpenShift however I have one small issue. These micro services are dependent on a commons project
containing some common components.
How can i add the jar of the commons project ( private jar, not on public repo) to the class path of the micro services about to be deployed on Openshift?
When building the application locally we used a maven plugin which would move the jar of the commons project into the local maven repository, from where it was easily referenced via a dependency tag in the pom file.
Here are some approaches that I thought about:
use an internal maven repository
create a folder on the root of the project and use it as a local maven repo, declaring it via repository tags in the pom files
deploy a nexus repository on the Openshift cluster
The first approach is not viable since our company does not have an internal maven repository.
We also tried the third approach , however we did not manage to deploy a running nexus repo on Openshift.
The only viable solution left is the second one, however I am a little bit reluctant to implement it since it does seem to be the standard way of doing things. What approach would you reccommend?
create a folder on the root of the project and use it as a local maven repo, declaring it via repository tags in the pom files
This won't be a good approach TBH.
My recommendation would be using a nexus/jfrog etc. repo OpenShift internal or externally (a more recommended approach for enterprises) and get the commons and other libraries from that repo via defining maven dependencies.
Is Spring tightly coupled with Maven ? Most of the examples in the internet shows Spring and Maven to configure spring dependent jars, this post explains so many cons of Maven. All commercial projects are should to be using only this combination ?
Please explain
Thanks
Both of them serve different purposes, Spring examples use Maven because maven is highly adopted as a build, dependency management framework. That has nothing to do with Spring coupling with Maven. Spring is a framework to build enterprise applications and Maven is a build and deploy tool.
You can use Gradle, ivy or even manually download the libraries instead of relying on Maven as the dependency management framework.
No. You can use whatever you want to build your Spring-based app. BTW, all the Spring tutorials show examples using Gradle (that Spring also uses internally).
What is true, though, is that Spring jars are available from the Maven central repository and the Spring repository, and that their dependencies is thus described in a Maven pom.xml file. But nothing prevents you from downloading the required jars manually and add them in the classpath.
I am moving my spring-java project to osgi.
I have some dependencies which are not available as bundles in the spring ebr repo or in maven repo.
What are the best ways to handle them?
The options I can think of are
create a local maven repo, convert the jars to bundles and use them ( this will become difficult with the transitive dependencies and updates of the jar)
add them in the bundle classpath ( my bundle becomes huge and managing those jars is not easy with upgrades)
keep all such jars in the classpath of another bundle, export the packages and use them ( again managing the jars is difficult)
Any other suggestions or which of the above is advisable?
The most advisable way is your first option, because that is the 'OSGi way'. This way you can better modularise your application and share the same bundle in different client bundles. You can also benefit from the version management inherent in OSGi.
You don't necessarily have to use Maven to create bundles from the JARs, although that may help. You can also use bnd to wrap a JAR as an OSGi bundle.
If you use apache karaf there is an option to bundle any jar from a maven repo on the fly.
You just use the uri install -s wrap:mvn:groupId/artifactId/version. This will use bnd to bundle the jar with default settings and installs it. This works for example with the oracle jdbc driver.
Is it possible to have standard war deployment, which can be deployed on tomcat and also can be build as OSGi bundle and deployed with other bundles in OSGi container tomcat(i think virgo)?
Yes, there's a good deal of interoperability between WARs and WABs. Apache Aries and WebSphere Application Server will convert WARs to WABs on deployment. This is a good way to get up and running, but it's a better practice to use proper WABs in which you build in the OSGi metadata yourself. The extra OSGi headers won't interfere with the deployment in a normal Tomcat container, so the WAB has the greatest flexibility.
For your build, you have a number of options. For example, the maven bundle plugin can be configured to build WABs, or you can use Eclipse PDE's tooling support for OSGi metadata.
Pax-Url-War provides this functionality to containers like Apache Karaf. In brief, this allows you to import an URL like war:file:///path/to/myapp.war and Pax will wrap it as an OSGi bundle, optionally changing the URL root and other parameters on the fly.