You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2012/04/16 21:42:48 UTC
Upgrading framework to R5 API
If I find the time, I'd like to update the framework to the R5 API...I
don't plan on implementing any of the features, just upgrading to the
latest API. (Of course, there aren't too many new features, just the
bundle collision hook, I think.) The main reason to do so, is so the
framework can start using/providing the new Resource API, which it
already mostly supports.
This would be beneficial, since it would allow us to run the OBR
resolver bundle I've checked into trunk, which requires the Resource
API. Also, it would make it easier for anyone wanting to submit patches
to implement any missing R5 functionality.
Before doing this, though, we'll probably cut a 4.2.0 release of the
framework first, so this wouldn't happen until 4.4.0 or something, but I
just wanted to run it by everyone to see if there were any objections.
The main issue being, the framework won't implement all R5 functionality
once released...we've done this in the past, so I don't suspect it is an
issue now, but you never know...
-> richard
Re: Upgrading framework to R5 API
Posted by Lucas Galfaso <lg...@gmail.com>.
On Monday, April 16, 2012, Richard S. Hall wrote:
> On 4/16/12 15:49 , Lucas Galfaso wrote:
>
>> Hi,
>> The latest draft of the spec (well, the one posted at osgi.org) does
>> not ask for the framework to be compiled for jsr14. Does this change
>> implies that Felix will change the target to 1.5+? (BTW, I think Felix
>> should change this, but I do know this can be one of those
>> controversial issues).
>>
>
> I think we'll go ahead and do that for the framework 4.2.0 release, which
> will be the next one. Compiling to jsr14 by default is proving too
> problematic, I think. Better to require the people needing target jsr14 to
> recompile than the opposite.
>
>
That would be great, thx
-lucas
> -> richard
>
>
>> Regards,
>> Lucas
>>
>>
>>
>>
>> On Mon, Apr 16, 2012 at 4:42 PM, Richard S. Hall<he...@ungoverned.org>
>> wrote:
>>
>>> If I find the time, I'd like to update the framework to the R5 API...I
>>> don't
>>> plan on implementing any of the features, just upgrading to the latest
>>> API.
>>> (Of course, there aren't too many new features, just the bundle collision
>>> hook, I think.) The main reason to do so, is so the framework can start
>>> using/providing the new Resource API, which it already mostly supports.
>>>
>>> This would be beneficial, since it would allow us to run the OBR resolver
>>> bundle I've checked into trunk, which requires the Resource API. Also, it
>>> would make it easier for anyone wanting to submit patches to implement
>>> any
>>> missing R5 functionality.
>>>
>>> Before doing this, though, we'll probably cut a 4.2.0 release of the
>>> framework first, so this wouldn't happen until 4.4.0 or something, but I
>>> just wanted to run it by everyone to see if there were any objections.
>>> The
>>> main issue being, the framework won't implement all R5 functionality once
>>> released...we've done this in the past, so I don't suspect it is an issue
>>> now, but you never know...
>>>
>>> -> richard
>>>
>>
Re: Upgrading framework to R5 API
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 4/16/12 15:49 , Lucas Galfaso wrote:
> Hi,
> The latest draft of the spec (well, the one posted at osgi.org) does
> not ask for the framework to be compiled for jsr14. Does this change
> implies that Felix will change the target to 1.5+? (BTW, I think Felix
> should change this, but I do know this can be one of those
> controversial issues).
I think we'll go ahead and do that for the framework 4.2.0 release,
which will be the next one. Compiling to jsr14 by default is proving too
problematic, I think. Better to require the people needing target jsr14
to recompile than the opposite.
-> richard
>
> Regards,
> Lucas
>
>
>
>
> On Mon, Apr 16, 2012 at 4:42 PM, Richard S. Hall<he...@ungoverned.org> wrote:
>> If I find the time, I'd like to update the framework to the R5 API...I don't
>> plan on implementing any of the features, just upgrading to the latest API.
>> (Of course, there aren't too many new features, just the bundle collision
>> hook, I think.) The main reason to do so, is so the framework can start
>> using/providing the new Resource API, which it already mostly supports.
>>
>> This would be beneficial, since it would allow us to run the OBR resolver
>> bundle I've checked into trunk, which requires the Resource API. Also, it
>> would make it easier for anyone wanting to submit patches to implement any
>> missing R5 functionality.
>>
>> Before doing this, though, we'll probably cut a 4.2.0 release of the
>> framework first, so this wouldn't happen until 4.4.0 or something, but I
>> just wanted to run it by everyone to see if there were any objections. The
>> main issue being, the framework won't implement all R5 functionality once
>> released...we've done this in the past, so I don't suspect it is an issue
>> now, but you never know...
>>
>> -> richard
Re: Upgrading framework to R5 API
Posted by Lucas Galfaso <lg...@gmail.com>.
Hi,
The latest draft of the spec (well, the one posted at osgi.org) does
not ask for the framework to be compiled for jsr14. Does this change
implies that Felix will change the target to 1.5+? (BTW, I think Felix
should change this, but I do know this can be one of those
controversial issues).
Regards,
Lucas
On Mon, Apr 16, 2012 at 4:42 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> If I find the time, I'd like to update the framework to the R5 API...I don't
> plan on implementing any of the features, just upgrading to the latest API.
> (Of course, there aren't too many new features, just the bundle collision
> hook, I think.) The main reason to do so, is so the framework can start
> using/providing the new Resource API, which it already mostly supports.
>
> This would be beneficial, since it would allow us to run the OBR resolver
> bundle I've checked into trunk, which requires the Resource API. Also, it
> would make it easier for anyone wanting to submit patches to implement any
> missing R5 functionality.
>
> Before doing this, though, we'll probably cut a 4.2.0 release of the
> framework first, so this wouldn't happen until 4.4.0 or something, but I
> just wanted to run it by everyone to see if there were any objections. The
> main issue being, the framework won't implement all R5 functionality once
> released...we've done this in the past, so I don't suspect it is an issue
> now, but you never know...
>
> -> richard