harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Supporting working on a single module?
Date Thu, 25 May 2006 12:37:21 GMT


Oliver Deakin wrote:
> Geir Magnusson Jr wrote:
>> On thing to think about (which I didn't realize until now) is that HDK 
>> should sit above /classlib in the tree right?  the VMs will need it as 
>> well.  I imagine :
>>
>> enhanced/
>>     classlib/
>>     drlvm/
>>     jchevm/
>>     bootvm/
>>
>> So maybe add a
>>
>>    enhanced/common
>>
>> directory in which the HDK sits by default?
>>
>> I'd like to avoid the structural balkanization of making classlib an 
>> island.
> 
> I had imagined that HDKs would be packaged up as zips and made available
> in a similar way to snapshots, rather than having a tree of binaries 
> checked into
> SVN. 

I think we all did.  I don't know what about the above leads you to 
assume I would have wanted this in SVN.


> IMHO keeping it as a zip makes unpacking it where you want very 
> simple,
> allows you to easily keep a "known good" HDK configuration locally (in the
> form of the original zip) and makes it very easy to get previous 
> versions of
> the HDK (just download an earlier zip).
> I'd be interested to hear what general consensus on this matter is, and
> how mailing list members would prefer the HDK to be provided.

Keeping zips around and all that is great, but is it that Eclipse would 
break having it up and above the root of the project tree?

geir

> 
> We discussed [1] that having separate HDKs for each VM and for classlib
> makes sense - as long as we keep them in a uniform shape, then they can 
> easily
> overlaid onto each other to allow a developer to work on the classlib 
> and the
> VM of their choice.
> I don't see this separation of classlib and VMs as a bad thing. I think 
> that
> having a VMI enabling us to develop the classlib and VMs as distinct units,
> and developing using potentially disparate methods and build systems that
> most suit that component, is one of the cool things about Harmony!


> 
> Regards,
> Oliver
> 
> [1] 
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c446D8460.9050105@googlemail.com%3e

> 
> 
>>
>> geir
>>
>> Oliver Deakin wrote:
>>> Hi all,
>>>
>>> I have opened HARMONY-485, which proposes an additional doc for the 
>>> website describing the HDK and its contents.
>>> The layout of the HDK described in the doc matches that produced by 
>>> the build script alterations raised in
>>> HARMONY-469.
>>>
>>> I hope that eventually (once the natives are modularised
>>> and build scripts are altered to understand/use the HDK) the doc will 
>>> expand into a more full description of how developers can use the HDK 
>>> to rebuild Java/native code.
>>>
>>> Regards,
>>> Oliver
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message