This lz4-java build now generates a valid OSGi bundle. The same JAR (same name, same everything) will keep the same behavior from non-OSGi Java environments. I tested quickly from an OSGi container on Linux/amd64 with a manual test (instantiated the 3 implementations) and using DataStax's Java driver for Cassandra.
Please note that in OSGi, packages are the "code modules" that are getting imported and exported, and are thus versioned. The best practice is to version them separately, depending on the semantic changes they go through between releases. A package within a given bundle (the deployment unit, i.e the JAR) could keep the same version while the bundle version changes. A common idiom is to have a simple text file named packageinfo in each package we mean to export that contain its version. This file is then picked-up by bnd, the bundle tool making, to export the proper version for each package.
Since I didn't want to change that significantly your development habits by creating those files that you might forget to update when you make incompatible changes, I take the Ivy revision value as the exported package version. This means that all packages have the same version (same as the bundle), and also that in the case of revisions having the -SNAPSHOT suffix I have to strip it out. Unfortunately I found nothing shorter/better than doing this using ant's scripting abilities (with JavaScript).
Here are the main changes:
computing the proper Import/Export package manifest entries using bnd (a new file lz4.bnd, whose name must match with the lz4.jar the jar ant target creates, contains the bnd instructions and in general the manifest entries).
replaced two calls to Class.forName with safer equivalents within OSGi (Class.forName has caching that sometimes create issues. It is advised to replace the calls to safer equivalents).
Thanks for looking into it (and if you accept the pull-req, possibly backporting the changes if the next release won't happen soon), and for making LZ4 available for Java :).
This pull request fixes issue #30.
This lz4-java build now generates a valid OSGi bundle. The same JAR (same name, same everything) will keep the same behavior from non-OSGi Java environments. I tested quickly from an OSGi container on Linux/amd64 with a manual test (instantiated the 3 implementations) and using DataStax's Java driver for Cassandra.
Please note that in OSGi, packages are the "code modules" that are getting imported and exported, and are thus versioned. The best practice is to version them separately, depending on the semantic changes they go through between releases. A package within a given bundle (the deployment unit, i.e the JAR) could keep the same version while the bundle version changes. A common idiom is to have a simple text file named packageinfo in each package we mean to export that contain its version. This file is then picked-up by bnd, the bundle tool making, to export the proper version for each package. Since I didn't want to change that significantly your development habits by creating those files that you might forget to update when you make incompatible changes, I take the Ivy revision value as the exported package version. This means that all packages have the same version (same as the bundle), and also that in the case of revisions having the -SNAPSHOT suffix I have to strip it out. Unfortunately I found nothing shorter/better than doing this using ant's scripting abilities (with JavaScript).
Here are the main changes:
lz4.bnd, whose name must match with thelz4.jarthejarant target creates, contains the bnd instructions and in general the manifest entries).Thanks for looking into it (and if you accept the pull-req, possibly backporting the changes if the next release won't happen soon), and for making LZ4 available for Java :).