search

google-code-export / ehcache-spring-annotations

Automatically exported from code.google.com/p/ehcache-spring-annotations
0 stars 0 forks source link

Enhancement: OSGi headers in the MANIFEST #31

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is an enhancement request. 

Can you please add the OSGi headers in the packaged MANIFEST, so that the 
ehcache-spring-annotations package can be used in an OSGi environment without 
needing to repackage it.

Doing this is fairly straight-forward with a tool such as Bundlor 
(http://www.springsource.org/bundlor) or the Felix Maven Bundle Plugin 
(http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html)

Thanks.

Original issue reported on code.google.com by GeorgeC...@gmail.com on 16 Jun 2010 at 2:44

GoogleCodeExporter commented 9 years ago 
Thanks for the request. I've never used OSGi, would you be willing to put 
together a patch for us? If so we'd apply it immediately. We're a few days away 
from our 1.1 release and it would be great to get it in there.

Original comment by eric.dalquist on 16 Jun 2010 at 2:51

GoogleCodeExporter commented 9 years ago 
The patch is attached. 

I've decided on Spring's Bundlor maven plugin, as it has a bit more flexibility 
with the version range, and since Spring uses it for its own bundles. Bundlor 
reads the template.mf file (which contains the packages and their versions 
[from the pom]) and generates an OSGi bundle MANIFEST.MF, that is later used by 
the maven-jar-plugin. 

A few things to note: 

(1) you may want to add the springsource plugin repository for Bundlor as 
described here: 
(http://static.springsource.org/s2-bundlor/1.0.x/user-guide/html/ch02s03.html); 

(2) the bundled version must not have a -SNAPSHOT, otherwise Bundlor (and more 
importantly your OSGi container) will complain; that is why I've created a 
"bundle.version" property. If you find a cleaner way of parsing out the 
MAJOR.MINOR.MICRO from the version (essentially omitting the -SNAPSHOT) in 
maven, definitely use it, and please let me know how you did it;

(3) you may want to relax or tighten the version range of your dependencies a 
bit for OSGi. With maven, the user can choose to use a higher or lower version 
of a dependency than the one specified in the dependency's pom. In OSGi, that 
isn't possible. The users of your bundle will be forced to use a dependency in 
the range specified in the template.mf. So, if slf4j 1.6 is specified as the 
lower range, folks will be forced to either upgrade or use a previous version; 

(4) I've made all packages except .impl accessible by other bundles in the same 
container (they're public). But there may be others that needn't be exported 
for everyone to use. It's, of course, the best practice to only export the API, 
so you may want to add .util in the "Excluded-Imports" list if it's not being 
used.

Original comment by GeorgeC...@gmail.com on 17 Jun 2010 at 5:50

Attachments:

GoogleCodeExporter commented 9 years ago 
Wonderful, thank you so much for the patch. I'll take a look at getting it 
applied in the next day or two and it will make it into the 1.1 release.

Original comment by eric.dalquist on 17 Jun 2010 at 12:39

GoogleCodeExporter commented 9 years ago 
I just applied the patch. I widened the version ranges for several libraries 
and setup properties specifying minimum versions for them. I also added the 
.util package to the excluded imports list but am a little curious as to how 
that works since I've never used OSGi.

Really all a user of this library should need to reference directly are the 
annotations in the base .annotations pacakge and the cache key generators in 
the .key package. The classes in .confi, .impl, .interceptor and .util should 
never need to be referenced by an implementers project under normal usage. 
Should all of those be excluded as well? I'm assuming code within the 
ehcache-spring-annotations library can reference any of its own packages 
without issue.

If you could take a look at the change in trunk that would be great. I'll plan 
on cutting a 1.1-RC2 release after I hear back and once that is verified we can 
make 1.1 GA

Original comment by eric.dalquist on 17 Jun 2010 at 9:30

GoogleCodeExporter commented 9 years ago 
Great! The template.mf is almost perfect, with the exception of two issues: (1) 
Excluded-Imports needed to be changed to Excluded-Exports (my mistake), and (2) 
the packages are comma separated.

I've attached a new template.mf that has the fixes for the two above. It also 
has the rest of the excluded packages. 

To answer your question -- yes, internally the code within 
ehcache-spring-annotations will be able to reference any of its own code, and 
any package that is imported in the MANIFEST. The Export-Package specifies what 
the other bundles can use from this library; and the Import-Package -- what 
ehcache-spring-annotations can access from other bundles. 

Btw, I've tested it in the Eclipse Virgo OSGi server (with the attached 
template.mf), and it works, so the build is good in terms of OSGi.

Original comment by GeorgeC...@gmail.com on 18 Jun 2010 at 7:05

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the testing and updated manifest. I've applied the changes and will 
try to get RC2 cut today.

Original comment by eric.dalquist on 18 Jun 2010 at 5:21

GoogleCodeExporter commented 9 years ago 
Eric, you probably know this: "org.springframework.context.support" 
3.0.3.RELEASE is locked into ehcache [1.3.0,2.0.0) (since context.support's pom 
has a ehcache 1.6.2 dependency). So unfortunately, OSGi user's of 
ehcache-spring-annotations will have to  repackage context.support to increase 
the 2.0.0 restriction to 3.0.0. This is obviously a bit of a hassle, but OSGi 
devs are used to it at this point.

FYI: I've filed a bug for the Spring devs to increase the upper range here: 
http://jira.springframework.org/browse/SPR-7302

Original comment by GeorgeC...@gmail.com on 18 Jun 2010 at 8:13

GoogleCodeExporter commented 9 years ago 
Thanks for the info, having not used OSGi before I didn't know that.

Is there anything we can do in our code to ease the pain? I stuck ehcache 2.0 
as a minimum dependency due to the change in maven package names between 1.x 
and 2.x but I believe this library will work with Ehcache back to 1.6. If I can 
find time to test that we could expand the Ehcache version range.

Original comment by eric.dalquist on 18 Jun 2010 at 9:06

GoogleCodeExporter commented 9 years ago 
Eric, thank you for asking. 

Right now "ehcache-spring-annotations" is only partially OSGi-ready 
(http://www.springsource.com/repository/app/faq#q5). It has a valid MANIFEST, 
but its dependencies do not all have OSGi-ready MANIFESTs. This means that when 
depending on "ehcache-spring-annotations" through maven, the OSGi developers 
have to exclude all of the dependencies with invalid manifests, and include 
valid ones. The other option is to rebuild the package with OSGi-ready 
dependencies.

In OSGi projects (and now, with all projects) what I generally do when adding a 
dependency, is check whether that dependency has a OSGi-ready  MANIFEST (that's 
one that has the proper: Bundle-*, Import-Package, Export-Package, etc. 
headers). If that dependency has a valid MANIFEST -- great -- I use it. If the 
original package creator doesn't -- I go to the SpringSource Enterprise Bundle 
Repository (http://www.springsource.com/repository/), and find the package I 
want there. All packages in the bundle repository are OSGi-ready.

Original comment by GeorgeC...@gmail.com on 19 Jun 2010 at 6:30