Re: osgi.jar and R4 sources was: Mavenization

[Brett Porter <br...@gmail.com>]

On 8/27/05, Richard S. Hall <he...@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

Re: osgi.jar and R4 sources was: Mavenization

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

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 <he...@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
>>>
>>>
>>>
>>>  
>>>
>>
>
>
>
>

Re: osgi.jar and R4 sources was: Mavenization

[Martijn Dashorst <ma...@dashorst.dds.nl>]

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 <he...@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
>>
>>
>>
>>  
>>
>

Re: osgi.jar and R4 sources was: Mavenization

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

BJ Hargrave wrote:

>I would suggest a single jar. Then someone can go java -jar felix.jar to 
>invoke the framework. This is basically what eclipse does now.
>

This is how I invoke Oscar, but Oscar has always been multiple JARs. I 
just use the Class-Path manifest header.

Certainly, if you combine everything into one, then you don't need the 
manifest header, but then we would also have to combine moduleloader.jar.

-> richard

Re: osgi.jar and R4 sources was: Mavenization

[BJ Hargrave <ha...@us.ibm.com>]

"Richard S. Hall" <he...@ungoverned.org> wrote on 2005-08-26 06:40:19 PM:

> 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.

I would suggest a single jar. Then someone can go java -jar felix.jar to 
invoke the framework. This is basically what eclipse does now.

> 
> -> richard
> 


BJ Hargrave
Senior Software Engineer, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@us.ibm.com
Office: +1 407 849 9117 Mobile: +1 386 848 3788

Re: osgi.jar and R4 sources was: Mavenization

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

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 <he...@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
>
>
>
>  
>