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: osgi.jar and R4 sources was: Mavenization
Date Fri, 26 Aug 2005 23:27:35 GMT
Sounds just like what we need.

-> richard

Martijn Dashorst wrote:

> Best way of handling the source import is to do it as a 'vendor' 
> branch. This way you can more easily manage your own changes to the 
> source. This is a feature of both SVN and CVS. It has helped me a few 
> times, and I wish I knew it a few years ago :-)
>
> Martijn
>
> Richard S. Hall wrote:
>
>> I expect that once the OSGi Alliance releases a final osgi.jar file 
>> with source, then we will check that into our repo and make mods to 
>> tie it to our framework where necessary and possibly make any other 
>> improvement/changes we deem necessary.
>>
>> The OSGi Alliance won't (at least they didn't in the past) release 
>> updates to this JAR file, so we won't have to worry about re-patching 
>> until R5, would be my guess.
>>
>> This seems manageable.
>>
>> re: one jar versus two, I prefer two, since it makes it easier for me 
>> to "see" the size of our implementation, but I might be able to be 
>> convinced otherwise.
>>
>> -> richard
>>
>> Brett Porter wrote:
>>
>>> On 8/27/05, Richard S. Hall <heavy@ungoverned.org> wrote:
>>>  
>>>
>>>> For me, this was more an issue of letting things settle down a little
>>>> bit. Everything is so fluid right now that it seems like we'd be 
>>>> chasing
>>>> our tails.
>>>>   
>>>
>>>
>>>
>>> Definitely a good idea, but I'd also avoid letting anything settle
>>> down which is known to be somiething you want to change as things can
>>> pick up fast and they get harder and harder to change.
>>>
>>>  
>>>
>>>> You have to expect dependencies from felix.jar to osgi.jar. The 
>>>> reverse
>>>> dependencies are a little more tricky and ugly. The ugly part is 
>>>> that I
>>>> just grabbed the R4 sources from Eclipse since they are under EPL so
>>>> that we would have them to compile against until the official R4 
>>>> release
>>>> comes out which will also be under EPL; Eclipse has dependencies back
>>>> into their framework, so I just hacked them to get them to compile 
>>>> with
>>>> Felix. The tricky part is that we will probably want these circular
>>>> dependencies too, because this is done for optimization purposes.
>>>>   
>>>
>>>
>>>
>>> I don't think this is an issue of Mavenization, as I think it needs to
>>> be addressed in the Ant build anyway (and you can get Maven to do what
>>> you are doing now with a little encouragement, but it isn't
>>> recommended).
>>>
>>> So, if osgi.jar and felix.jar are going to forever be linked in this
>>> way, they have to reside together and you can't substitute another
>>> container for felix or another osgi spec jar without changing the
>>> other. In which case, they should just be one JAR. Problem solved :)
>>>
>>> This cuts back to how the R4 sources will be managed going forward,
>>> which I've discussed with you before. Will we be maintaining our own
>>> version of the R4 sources, constantly copying changes from the EPL
>>> sources, will they be frozen, or will we eventually use a
>>> redistributable JAR?
>>>
>>> I think from earlier discussions we've established that all of those
>>> are acceptable from a licensing standpoint, but from a technical
>>> standpoint the first one sounds downright scary, the second reasonable
>>> (but still scary as I'm sure there will be revisions and then it
>>> reverts to the first) and third preferable as it means that osgi.jar
>>> and felix.jar can be independant.
>>>
>>> Regardless, IMO if we maintain the sources and there is a circular
>>> dep, I think producing one JAR is the best way to go.
>>>
>>> WDYT?
>>>
>>> - Brett
>>>
>>>
>>>
>>>  
>>>
>>
>
>
>
>


Mime
View raw message