harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: Supporting working on a single module?
Date Thu, 18 May 2006 09:17:01 GMT
Rana Dasgupta wrote:
> Hi,
> Is there an expectation of a standardised deployment model for the 
> Harmony
> compliant VM's like DRLVM and others? Eg., should they all produce 
> binaries
> that can be unpacked to overlay the Harmony Classlib deployment structure
> as can the IBM VME? At some point, we will be posting distributions 
> for both
> class libraries and VM on the Harmony site; they should be deployable 
> on a
> user machine in some standard way.
>

I think it makes sense to have a standard "shape" for deployed binaries, 
so that
for users to get a completely working jdk it is as simple as grabbing 
VME and
Classlib distributions and unpacking them in the same place. There is a 
subtle
difference here between Harmony VMs and the IBM VME however, in that
the IBM VME was intended for development use, and so matches the
expected layout of a developers deploy directory. An actual customer of the
Harmony runtime would expect something closer to what they are used to
with other Java implementations.

It was suggested by Mark [1] that we create snapshots for the proposed hdk,
the jdk and the jre. The hdk is intended for use by Harmony developers;
the jdk and jre are more familiar packages and would be the ones
used by customers. I suggest that any Harmony VM release should match
the structure of one of the latter two. IMHO if a VM matches the jre 
structure
this provides a "lowest common denominator" solution that can be overlaid
onto jre, jdk and hdk.

Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605091407.k49E749L028574@d06av02.portsmouth.uk.ibm.com%3e


> Thanks,
> Rana
>
>
> On 5/17/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
>>
>> > deploy/
>> >   \----jdk
>> >           |----include
>> >           \----jre
>> ...
>> > 2) I was wondering how this change will affect the DRLVM? I notice 
>> from
>> > building
>> > the VM locally that it produces a deploy\jre\bin structure, so I 
>> imagine
>> > that some
>> > small path changes to build scripts would be necessary (similar to the
>>
>> I think this specific change shouldn't directly affect the DRLVM
>> building script since it takes the Harmony class libraries in a source
>> form.
>>
>> If we, however, want to adjust the JRE image produced by the DRLVM
>> building script, then I guess the only line that will have to be
>> changed (in build/make/build.xml) is:
>>
>>        <!-- product binary deploy location -->
>>        <property name="build.deploy.dir"
>> location="../${build.os.short}_${build.arch}_${build.cxx}_${build.cfg
>> }/deploy/jre"
>> />
>>
>> I can include it as a next "cumulative patch".
>>
>> Surely, some more updates will have to be done for xml files at
>> build/make/components in case the classlibs will be split by modules
>> in future.
>>
>> Thanks,
>> Andrey.
>>
>>
>> On 5/17/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>> > Ive just opened HARMONY-469 which contains a patch to rearrange the
>> > current layout
>> > of the deploy directory into:
>> >
>> > deploy/
>> >   \----jdk
>> >           |----include
>> >           \----jre
>> >
>> > This is a preliminary step to reorganising the native code and 
>> using the
>> > deploy directory
>> > as an HDK (as discussed else where in this topic [1] & [2]).
>> >
>> > If/when this patch is accepted and applied, there are a couple of 
>> issues
>> > that may affect
>> > us that I thought would be worth bringing to general attention:
>> >
>> > 1) The IBM VME is laid out to unpack with the same directory structure
>> as
>> > the current deploy directory i.e. it overlays into
>> > deploy/jre/bin/default. If there is a new
>> > jdk directory added into the structure, then the VME will no longer
>> > unpack into the
>> > right place, which might confuse new developers hoping to try out our
>> > code. I am
>> > currently working on making a VME which reflects the new layout
>> > available, and I will
>> > send a note to the list once it is ready (this would be after
>> > HARMONY-469 was
>> > applied).
>> > Developers that are already using a VME in their workspace will simply
>> > need to move
>> > the deploy/jre/bin/default directory to deploy/jdk/jre/bin/default.
>> >
>> > 2) I was wondering how this change will affect the DRLVM? I notice 
>> from
>> > building
>> > the VM locally that it produces a deploy\jre\bin structure, so I 
>> imagine
>> > that some
>> > small path changes to build scripts would be necessary (similar to the
>> > changes I
>> > had to make in HARMONY-469).
>> >
>> > Regards,
>> > Oliver
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c200605091407.k49E749L028574@d06av02.portsmouth.uk.ibm.com%3e

>>
>> >
>> > [2]
>> >
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/%3c4463654A.3080105@googlemail.com%3e

>>
>> >
>> >
>> > --
>> > Oliver Deakin
>> > IBM United Kingdom Limited
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
>

-- 
Oliver Deakin
IBM United Kingdom Limited


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