We just have to make sure to maintain API compatibility and consistency in the version numbers. Also, from my understanding of fragment hosts, specifying a host indicates that the hosts class loader will contain all its fragments. I'm starting a migration to OSGi at my work, so I'll have a more thorough understanding soon.
Also, that reminds me about the API changes. What I'd like to see is splitting pure API/SPI classes into one package(s), and implementation classes in another. This will make it easier to export only the necessary classes to other bundles, plus I think it's good practice. I'll try to refactor core to reflect my idea. If big API refactoring won't work too well, I might instead work on writing a separate OSGi API for implementing third party plugins and such in a more OSGi way. This could even be an addition to the existing @Plugin API that exists with the Felix SCR annotation processor plugin to automate the declarative services stuff. Overall, I don't think true OSGi support will be ready for 2.0, but we should take care of any necessary API changes before GA. Matt Sicker > On Feb 20, 2014, at 0:41, Remko Popma <[email protected]> wrote: > > Although it looks strange that the async OSGi bundle points to the log4j-api > bundle as its Fragment-Host. It would have expected log4j-core, but perhaps I > don't understand OSGi well enough... > >> On Thursday, February 20, 2014, Remko Popma <[email protected]> wrote: >> It looks like this is already done: the rc1 jars (incl the ones in >> apache-log4j-2.0-rc1-osgi-bin.zip) are all named 2.0-rc1, but the manifest >> has entries like: >> Bundle-Version: 2.0.0.rc1 >> Export-Package: org.apache.logging.log4j.core.async;version="2.0.0.rc1" >> Fragment-Host: org.apache.logging.log4j-api;bundle-version=2.0.0.rc1 >> >> This looks like what you had in mind, right? >> >> >> Sent from my iPhone >> >>> On 2014/02/20, at 7:20, Matt Sicker <[email protected]> wrote: >>> >>> Checks the manifest. In the Export-Package attribute, each package is >>> paired with a version number. Those are the version numbers used by OSGi, >>> so I'd assume they can differ from the jar name. >>> >>> >>>> On 19 February 2014 16:07, Remko Popma <[email protected]> wrote: >>>> Do OSGi containers look at the jar name or at the manifest for version >>>> info? >>>> >>>> Sent from my iPhone >>>> >>>> On 2014/02/20, at 1:31, Matt Sicker <[email protected]> wrote: >>>> >>>>> Just a quick follow-up to making things nice for the bundles. Version >>>>> numbers in OSGi are in the format: "major.minor.micro.thing" where the >>>>> major.minor.micro is the usual semantic versioning separated by dots, and >>>>> the last part can be a string like "rc1" or "beta-2" or "GA" or whatever >>>>> as is commonly done by many projects. By following the proper versioning >>>>> scheme, consumers of these bundles can specify a version range such as >>>>> [2.0, 2.1) so that all 2.0.x versions are considered, but not 2.1.x. >>>>> >>>>> Overall, this isn't too different (if at all) from common practices for >>>>> versioning, but it's nice to keep in mind if you guys don't like >>>>> increasing the minor version very often. >>>>> >>>>> -- >>>>> Matt Sicker <[email protected]> >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]>
