I'm building my application to run in an OSGi container. I use Maven and the Maven Bundle Plugin from Apache Felix to set up the OSGi manifests for my own modules and that works great.
Now, I'm deploying my bundles into an OSGi container together with several 3rd party libraries. Some of these are already OSGi-fied when I get them from the Maven repos, others, I want to convert into OSGi-compatible jars. I want to set up a Maven project that collects all dependencies, and puts each in its own OSGi jar. The ultimate goal is to collect these jars and my own into an assembly that I can use as a standalone deployment package.
I know how to convert standard jars to OSGi jars, and I have a (somewhat hackish) approach to merge multiple OSGi bundles, even if I probably shouldn't. But if I have a dependency that's already fine as it is, and I just want to copy it from the repo into my assembly, what part of Maven do I use? The bundle plugin is wrong, it messes up the manifests if a dependency is already OSGi-compatible. Do I use the dependency-plugin, the assembly plugin or something else?
I have the feeling I'm overlooking something very simple here.
Did you have a look at the PAX tools? In particular Pax-Runner and
pax-construct... They do not only give you a nice template to start with, but also solve most the problems you mentioned for free.
We use many libraries which are not OSGified by the vendor and which are not available on the Spring bundle repository. We also have many of these and want to deploy them all together hassle free. For this we have created a 2-layer maven setup:
Individual maven projects that either download or contain (as 'system' scope depends) the 3rd party lib in question, and OSGify these using the Apache Felix bundle plugin
One container project that has a dependency on all of these small projects and makes an assembly of them using the core assembly maven plugin. This POM also uses the copy-dependencies goal of maven to make sure everything is in place.
Once it is turned into an assembly (ours is a tar file) we deploy this to our servers. We have gone one step further and used this assembly of 3rd party libraries as the Target Platform for our Eclipse build environment. But this may be irrelevant for you.
You can get OSGi friendly versions of many common artifacts from the Spring bundle repository. So you may not have to do it yourself.
See details of how to configure the bundle repository for Maven.
(will update with some ideas for those that aren't available as bundles already)
Related
I am new to Maven and using it to build a project on my local. This is working nicely on my local. Now, I want to run the same project on my server and the server does not have Maven installed. So I wanted to ask if there is any way by which, when I build a Maven project on my local, I could include all the required jars in it and then simply transfer it to my server? I know Maven creates the repository in C:\Documents and Settings\username\.m2 on Windows.
But how can I include all the jars in project the way we do traditionally? I saw this question. But it talks about creating a custom repository and I don't have Maven installed at all. so I guess it is not a suitable solution to me.
Thanks.
You can use the Maven Assembly Plugin. From the documentation:
The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive.
I have a project that's using the Play framework, and the corporate standard is that all projects should be built by Hudson. However, I cannot find out how to do this, as Hudson does not follow any Java standards, and requires the framework installed at the computer it runs on. I have tried to build the project with Maven (if I had managed this, adding it to Hudson should be quite simple), but I have failed to make it work. I tried the Play Maven module, but Maven claims it does not find the external repo that is listed (http://nexus.infin-it.fr/content/groups/public). This might be because I am behind a firewall. I also tried the recipe listed here, but the local maven build fails because it is unable to find org.playframework:play:1.1:jar.
Has anyone done this and can provide a howto?
It can be done without installing the Play framework on the Hudson server, but it is quite complicated:
Put the play libraries (play.jar and its dependencies) in a Maven repository
Create a pom.xml for your project, configured with:
theses libraries as dependencies
your project specific dependencies (project lib directory)
the java sources folder of your project (in the maven-compiler-plugin): "app"
If your project is simple (no module dependencies), this pom allows you to build the play project java sources using Maven.
If your project has module dependencies, you will have to add the dependencies jar in your pom dependencies.
To do that, you will have to create jar files from the modules if they don't have packaged jars (to get the "CRUD" class of the CRUD module for example).
You can find some help on this page I wrote :
http://blog.infin-it.fr/2010/12/15/play-framework-integration-continue-retour-dexperience/
Even if it's in French, I put my Ant stuff and the Play's pom I wrote.
At work we managed to integrate our Play applications with Bamboo.
It should not be difficult with my files.
Just looked at the repository, that you linked (http://nexus.infin-it.fr/content/groups/public). And guess what, I found the play-1.1.jar. However, the artifact ID is: org.play:play:1.1:jar and not org.playframework
In theory, you could put the full Play zip on your build or in in your repository, and then use Hudson to kick off an Ant script to download Play to the Hudson agent, unzip it, and then run commands on it. It's a little clunky, but it should work.
We are building an Eclipse RCP plugin that is based on an Eclipse target platform (also developed internally in our company, by a different department). We would like to compile the plugin using MAVEN2 (we also use NEXUS for repository management).
The target platform consists of about 130 JARs (most of them org.eclipse.*). One way to perform the build would be to add 130 references into the tag of the POM file. Not only is this a lot of effort, but the target platform occasionally changes, so a new target platform would mean a lot of modifications.
Is there a better way to deal with a lot of dependencies in MAVEN?
Take a look at All Client jBoss artifact. They have solved the same problem using POM artifact.
I am working on converting websphere portal project to maven framework for CI build. I am wondering if there is a way to reference websphere jars other than via dependencies in pom.xml and loading them all to maven repository? I cannot imagine loading them ALL to the repository...
Please advice! Thanks!
When using Maven, it is advisable that all dependent jars are installed in the repository. Even Websphere ones.
Ideally a corporate repository will come in handy here, so that you keep a separate repository for all the Websphere jars accessible to all the users in your project. See http://maven.apache.org/repository-management.html for more.
If this is not an option, then use the local file repository explained on a previous questions - here.
You'll still need to add each dependency in POM.
Also read http://sdudzin.blogspot.com/2007/09/maven-2-and-websphere-automated-build.html
if you have a lot of projects that require this, you can also create a parent pom that would have all the dependencies so your project/module/portlet poms are cleaner.
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.