Add OSGi metadata to Querydsl modules

[Oliver Gierke]

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 template.mf.

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.

[Timo Westkämper (timo-westkamper)]

I just added minimal template.mf 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 template.mf:s to get proper manifests?

[Oliver Gierke (ogierke)]

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 template.mf 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?"

[Timo Westkämper (timo-westkamper)]

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

[Oliver Gierke (ogierke)]

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

<properties>
  <spring.version>3.0.5.RELEASE</spring.version>
</properties>

then you can do something like this in the template.mf:

Import-Template:
  org.springframework.*;version="${spring.version:[=.=.=.=,+1.0.0)}"

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 template.mf in case you update dependency versions.

[Timo Westkämper (timo-westkamper)]

I just commited improved template.mfs.

[Jean-Pierre Bergamin (ractive)]

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)]

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

...
net.jcip.annotations.*;version="${findbugs.version}",
...

Either you should define a new property or just use 1.0.0

[Jean-Pierre Bergamin (ractive)]

I also would exclude the findbug imports, since they are not needed at runtime:
In template.mf:
...
Excluded-Imports:
 edu.umd.cs.findbugs.annotations.*
...

[Timo Westkämper (timo-westkamper)]

Fixed the templates

[Timo Westkämper (timo-westkamper)]

Released in 2.2.0