Native CT Tests passing

[Bob Paulin <bo...@apache.org>]

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

Re: Native CT Tests passing

["Richard S. Hall" <he...@ungoverned.org>]

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
>