On 12/18/14 18:05 , Bob Paulin wrote:
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.
Yeah, I think renaming them is fine...that is purely legacy.
Technically, this isn't public API, so we might not have to worry about
it, but I don't really have a strong opinion.
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.
I assume you mean something like this:
https://issues.apache.org/jira/browse/FELIX-3883
I think we should move this into configuration. We could define the
default values in default.properties and then allow these defaults to be
extended in config.properties, for example.
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.
If it works for us, then it makes sense to reuse it. Our VersionRange
doesn't implement comparable...I don't actually see how a version range
could be comparable, since the notion of greater than/less than doesn't
really make sense.
-> richard
Happy Holidays,
- Bob
