All,
I resolved the rest of the native code CT test failures in
https://issues.apache.org/jira/browse/FELIX-4729. So looks like we're
getting close to being ready for R6. Please let me know if there is any
feedback on the implementation. A couple of thoughts on the native code
I'd like to float prior to the release.
1) R4LibraryClause and R4Library are no longer really R4 at all.
Can we consider renaming these classes to NativeLibraryClause and
NativeLibrary. I realize this is a bit of a breaking change if
developers are using the R4Library and R4LibraryClause classes but I
couldn't find any examples of this outside the framework project. The R6
changes might be worth a major revision bump.
2) Processor and OS Name aliasing: in memory lookup vs coding.
R6 has it where the processor and os name gets aliased to potentially
many names. Equinox currently does the aliasing by pulling a file into
memory. I found it to be more direct and likely more backwards
compatable in felix to hook into the normalization process and then do
the aliasing. However we could refactor to put all the aliases in a
table like Equinox at the expense of some memory. A file might be
easier to maintain going forward as new os and processors come out.
Might be good to provide some sort of hooks so developers can do this
without us if needed.
3) Moving from the Felix version of VersionRange to the
org.osgi.framework.VersionRange.
Currently we have our on VersionRange class with similar but not exactly
the same functionality as the org.osgi.framework.VersionRange. It
would be helpful if the osgi VersionRange implemented Comparable as we
could then remove the special code I had to add to the CapabilitySet
class to deal with VersionRange based on the provided OS Version. Not
sure if this is something we might consider suggesting in a future spec.
Happy Holidays,
- Bob
