Add OSGi metadata to Querydsl modules

Bug #779743 reported by Oliver Gierke on 2011-05-09
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

The Querydsl JARs contain manifest files but they in turn contain any import or export declarations. Would be cool if they could contain valid OSGi metadata which can be generated with little effort.

I've attached a patch that uses SpringSource Bundlor plugin to generate the metadata for Core, APT, Maven Plugin, SQL and JPA (the JPA profile pretty much). Bundlor can use Maven properties to generate the version ranges in the MANIFEST.MF, which - if used more intensively - could reduce the amount of version information duplication in pom.xml and

Beyond that you have a split package com.mysema.util in Core module as well as SQL module which will cause trouble in an OSGi context as packages must not be split between JARs. I also had to change the version scheme to 2.2.0.beta-4-SNAPSHOT as OSGi requires a 3rd version digit to be numeric only as well.

I had to configure the JAR plugin in querydsl-root as well, as it does not include generated MANIFEST.MF files by default.

I hope the patch helps you getting started with Bundlor a bit. Feel free to contact me for further assistance.

Oliver Gierke (ogierke) wrote :
description: updated
description: updated

I just added minimal into the modules and fixed the split package issue. Could you given me some hints on how I should configure the core, apt, sql, jpa and mongodb modules so that they work for you?

How much metadata do I need to put into to get proper manifests?

Changed in querydsl:
status: New → In Progress
Oliver Gierke (ogierke) wrote :

You can add a configuration attribute <failOnWarnings>true</failOnWarnings> to Bundlor. If configured this way Bundlor will break the build if you e.g. introduce a new dependency that you don't have added a version range in for. I didn't include it the first place as the split package generated such a warning and I didn't wanna leave you with a broken build.

What do you mean with:

"Could you given me some hints on how I should configure the core, apt, sql, jpa and mongodb modules so that they work for you?"

Can't the version ranges be detected from the Maven metadata or does Bundlor operate only on the target jar?

Oliver Gierke (ogierke) wrote :

It partially can. Assuming you have defined a Maven property like this:


then you can do something like this in the


This pretty much says: take the maven property spring.version, take it's 4 digits as lower inclusive bound and stretch the upper bound until the next major release. The result will be "[3.0.5.RELEASE,4.0.0)" in that case. So you don't need to touch the in case you update dependency versions.

I just commited improved template.mfs.

Jean-Pierre Bergamin (ractive) wrote :

I could not find any bugtracker for the codegen and the commons-lang project that is also used by querydsl. So I just mention it here...

It would be very convenient if mysema codegen and the commons-lang projects would also be available with proper OSGi manifests.

Jean-Pierre Bergamin (ractive) wrote :

BTW: I just saw that querydsl-core/ has a type. The version of the net.jcip.annotations package is wrong:


Either you should define a new property or just use 1.0.0

Jean-Pierre Bergamin (ractive) wrote :

I also would exclude the findbug imports, since they are not needed at runtime:

Fixed the templates

Changed in querydsl:
status: In Progress → Fix Committed

Released in 2.2.0

Changed in querydsl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers