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 ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
