harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Where to place the core classlib code?
Date Thu, 01 Dec 2005 11:59:09 GMT
Geir Magnusson Jr. wrote:
> 
> On Dec 1, 2005, at 6:04 AM, Tim Ellison wrote:
> 
>> I thought the idea was that each contribution started working directly
>> in the sandbox?  Isn't that what Dan and Archie are doing?
> 
> 
> We threw it in the sandbox because we had no better ideas and was a 
> good starting point.  Since I'm really hoping that we don't have 
> multiple classlibrary efforts here at Harmony (although that's  welcome
> too, I suppose, if someone really wants to do it...), I  figure we can
> start by moving this code out now, and then if one or  more of our VMs
> (Archie or Dan's) start to support it, we pull it out  too and put in
> the appropriate place - whatever that is - so we can  start having a
> comprehensive build.

Ok, sounds good.

>>
>> Once things are pulled out from the sandbox I propose that the
>> repository is laid out to represent a few (non-trivial) sub-projects
>> that have well-defined interaction, to allow some development  autonomy,
>> but build together into a single system, something like:
>> enhanced
>>   /classlib
>>     /trunk
>>     /branches
>>     /tags
>>   /vm
>>     /trunk
>>     /branches
>>     /tags
>>   /jit
>>     /trunk
>>     /branches
>>     /tags
>>   /build
>>     /trunk
>>     /branches
>>     /tags
>>
>> and so on, with further subdivision within the sub-projects are  required
>> (e.g. ACL areas within the classlib as defined by the ACQ).
>>
>> Is this the sort of thing you mean?
> 
> 
> Yes - we've talked about this before, and I just wanted to focus on 
> classlib...
> 
> The problem I have with this is that we won't be able to branch the 
> whole thing easily like we would if we had :
> 
> enhanced/
>      trunk/
>          classlib/
>          vm/
>          tools/
>      branches/
>          harmony-v0.5-branch/
>                  ...
>      tags/
>          harmony-v0.5-rc1/
>                  ...
>          harmony-v0.5-rc2/
>                  ...
> 
> Thinking out load -  it's not obvious to me that we'd want to do that 
> anyway, given the eventual mass of this thing.  The deliverable goal  is
> a full stack and tools, would we really want to be assembling from 
> truly independent sub-parts?   Yah, I guess we do...  that allows the 
> sub-components to be independently developed and tested.

Right, in a system this size we have to break it down into subprojects
(what you called 'subdivisions' below).  The *repository* branches will
be most useful within a subproject, and if we want different
combinations of subprojects then they are likely build-time targets.

> It might be that the structure of each subdivision (not using the  word
> "component" 

are you comfortable with "subproject"?

> needs to vary independently also because of  requirement
> specific to each (for example, a modular class library  would have ore
> than one build artifact...

exactly.  We have said that the classlibs are going to be modular too,
so we will have flexibility within the classlib subproject/subdivision too.


Regards,
Tim

> 
> geir
> 
> 
>>
>> Regards,
>> Tim
>>
>>
>> Geir Magnusson Jr. wrote:
>>
>>> Now that the code from IBMs contrib (HARMONY-14) is in the sandbox
>>> (well - it's uploading now...), we'll need to shift things around  a
>>> bit.
>>>
>>> do we do something as obvious as
>>>
>>> enhanced/trunk/classlib/
>>>
>>> ?
>>>
>>> Or do we get ahead of things and do :
>>>
>>> enhanced/trunk  /* for general stuff, including project build scripts
>>> and such */
>>>
>>> enhanced/classlib/trunk  /* for HARMONY-14 and then the security code
>>> layered on *?
>>>
>>> ?
>>>
>>> geir
>>>
>>
>> -- 
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
> 
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message