felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Felix 1.5.0 snapshot
Date Tue, 03 Mar 2009 17:46:33 GMT
Sorry I didn't mention it...

-> richard

Henri Gomez wrote:
> Great.
>
> I got this snapshot repository referenced in our Nexus, so I should be
> easy to grab new stuff.
>
> thanks
>
> 2009/3/3 Stuart McCulloch <mcculls@gmail.com>:
>   
>> 2009/3/4 Henri Gomez <henri.gomez@gmail.com>
>>
>>     
>>> Where could we found it ?
>>>
>>>       
>> either build from trunk or download the main Felix jar (ie. framework +
>> launcher) from:
>>
>>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/felix/org.apache.felix.main/1.5.0-SNAPSHOT
>>
>> this is the Apache snapshot repository, so you can find the other artifacts
>> in nearby directories
>>
>>
>>     
>>> Cheers
>>>
>>> 2009/3/3 Richard S. Hall <heavy@ungoverned.org>:
>>>       
>>>> Hey guys,
>>>>
>>>> I think we will start to gear up for a 1.6.0 release of framework and
>>>>         
>>> main.
>>>       
>>>> I just deployed a 1.5.0 snapshot for your pleasure or feel free to build
>>>> from trunk. I hope people will spend some time playing with this snapshot
>>>> since it has seen some major refactoring under the covers. There are two
>>>> main areas where there was a lot of refactoring:
>>>>
>>>>  1. The structure of the code was simplified to remove a lot of the
>>>>     generic module layer and make it more specific to OSGi, since in
>>>>     all likelihood we will never implement a different module system
>>>>     on top of the module layer. These changes are not complete, but
>>>>     since they are implementation details we can finish this
>>>>     refactoring in later releases. Hopefully, these changes will not
>>>>     impact anyone.
>>>>  2. The locking/concurrency approach was refactored quite a bit.
>>>>     Mainly, we try to be a little more precise and strict in our
>>>>     locking. However, since strictness and precision can lead to
>>>>     deadlocks, we have tried to make the locking interruptible in the
>>>>     case a potential deadlock is detected. I just committed the final
>>>>     changes (I hope) in this area for this snapshot. It is possible
>>>>     that these changes will impact users, so testing by people using
>>>>     multiple threads is greatly appreciated.
>>>>
>>>> Please report any issues back to the mailing list or with JIRA, thanks.
>>>>
>>>> -> richard
>>>>
>>>>         
>>
>> --
>> Cheers, Stuart
>>
>>     

Mime
View raw message