Mark Hindess wrote:
On 7 June 2006 at 9:42, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Oliver Deakin wrote:
Just thought Id give a bit of a heads up on HARMONY-561.
The patch attached to that JIRA moves the header files under the
native-src/platform/include directories into
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Just thought Id give a bit of a heads up on HARMONY-561.
The patch attached to that JIRA moves the header files under the
native-src/platform/include directories into
/modules/luni|archive/src/main/native. It also updates the build
scripts and
Just thought Id give a bit of a heads up on HARMONY-561.
The patch attached to that JIRA moves the header files under the
native-src/platform/include directories into
/modules/luni|archive/src/main/native. It also updates the build
scripts and
makefiles to move the headers into a shared
On 5/25/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Vladimir Gorr wrote:
On 5/25/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK
Geir Magnusson Jr wrote:
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK could be anywhere - the was no hard-wired spot. That
allowed having multiple simultaneous HDKs (ex different snapshot
version) at
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
2006/5/25, Oliver Deakin [EMAIL PROTECTED]:
I imagine that an HDK would come in a zip format, much like the current
snapshots [2].
I also suggest to add build date into zip name and internal directory name.
Something like HDK_20060525/deploy and so on...
It will let us keep few copies of HDK
On 5/25/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK could be anywhere - the was no hard-wired spot. That
allowed having multiple
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK could be anywhere - the was no hard-wired spot. That
allowed having multiple simultaneous HDKs (ex different
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
Alexey Petrenko wrote:
2006/5/25, Oliver Deakin [EMAIL PROTECTED]:
I imagine that an HDK would come in a zip format, much like the current
snapshots [2].
I also suggest to add build date into zip name and internal directory name.
Something like HDK_20060525/deploy and so on...
Yes, I
Vladimir Gorr wrote:
whether does it mean the HDK will contain the sources (src.zip?) as well?
Otherwise I don't understand what can be modified. Could you please clarify
this?
I know you addressed to oliver, but let me take a wack at it to see if I
grok everything
One of the many
Geir Magnusson Jr wrote:
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/
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
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/
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
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 :
Vladimir Gorr wrote:
On 5/25/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK could be anywhere - the was no hard-wired spot. That
Geir Magnusson Jr wrote:
Vladimir Gorr wrote:
whether does it mean the HDK will contain the sources (src.zip?) as
well?
Otherwise I don't understand what can be modified. Could you please
clarify
this?
I know you addressed to oliver, but let me take a wack at it to see if
I grok
Post J1 catchup. Just minor comments, am trying to read the thread
through...
Mark Hindess wrote:
On 10 May 2006 at 8:07, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
AS a matter of fact, I think that the hdk is simple a tar of the junk
created by a make the world build...
I wouldn't have
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
Some stuff that got lost (because I got consumed by J1 and I was the
only one pushing on it) was the idea of ensuring that
1) the HDK could be anywhere - the was no hard-wired spot. That allowed
having multiple simultaneous HDKs (ex different snapshot version) at the
same time as a full
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
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
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
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
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
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
Tim Ellison wrote:
That layout works for me too.
Patches welcome ;-)
hehe, had a feeling that might be coming ;)
Im actually working on a couple of preliminary patches at the moment for
this refactoring. One is a minor tidy up, raised in HARMONY-451. I hope
to raise another JIRA soon
Hi Andrey,
Andrey Chernyshev wrote:
On 5/12/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
SNIP
To do this there are at least three steps needed, as far as I can
see:
1) Refactor the native code into the modular structure we currently
have for Java code and
Tim Ellison wrote:
Andrey Chernyshev wrote:
snip
(1) Do we need to keep the 'main' directory in every module? If we
need to have a distinction between tests and sources, may be just pull
tests one level up and have something like:
archive/
src/
native/
java/
On 15 May 2006 at 16:14, Andrey Chernyshev [EMAIL PROTECTED] wrote:
Hi Oliver,
I think using src/main and src/test to group our implementation
and test code was a convention we agreed on a while back. Personally
I dont have any problem with it, but it's something we can look at again
I was thinking that platform specific directories would be laid out
underneath each native
component directory. So, for example, underneath the
modules/luni/src/main/native/port
directory there would be the following structure (avoiding ascii tree
diagrams):
Mark Hindess wrote:
On 15 May 2006 at 16:14, Andrey Chernyshev [EMAIL PROTECTED] wrote:
Hi Oliver,
I think using src/main and src/test to group our implementation
and test code was a convention we agreed on a while back. Personally
I dont have any problem with it, but it's something
Andrey Chernyshev wrote:
I was thinking that platform specific directories would be laid out
underneath each native
component directory. So, for example, underneath the
modules/luni/src/main/native/port
directory there would be the following structure (avoiding ascii tree
diagrams):
That layout works for me too.
Patches welcome ;-)
Regards,
Tim
Oliver Deakin wrote:
Andrey Chernyshev wrote:
I was thinking that platform specific directories would be laid out
underneath each native
component directory. So, for example, underneath the
modules/luni/src/main/native/port
Andrey Chernyshev wrote:
snip
(1) Do we need to keep the 'main' directory in every module? If we
need to have a distinction between tests and sources, may be just pull
tests one level up and have something like:
archive/
src/
native/
java/
tests/
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Mark Hindess wrote:
On 9 May 2006 at 10:32, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the
typical
On 12 May 2006 at 13:59, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Oliver Deakin wrote:
To do this there are at least three steps needed, as far as I can see:
1) Refactor the native code into the modular structure we currently
have for Java code and tests. This has been spoken about
Geir Magnusson Jr wrote:
Nathan Beyer wrote:
Perhaps this is a bit of an aside, but one of the biggest difficulties I
have when trying to develop against a single module is the
availability of
the test support classes. Currently, I run the ant build and run the
'compile-support' to build the
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Mark Hindess wrote:
On 9 May 2006 at 10:32, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the
On 5/12/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Oliver Deakin wrote:
Geir Magnusson Jr wrote:
Mark Hindess wrote:
On 9 May 2006 at 10:32, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to
On 11 May 2006 at 13:23, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I *do* sympathize with [psychos like] Mark who has 4 builds at once
Hey! I resent that . . . I said I had at least half a dozen. ;-)
-Mark.
-
Terms of
' snapshot
would need to contain to fully support modular development.
-Mark.
-Original Message-
From: Mark Hindess [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 09, 2006 9:07 AM
To: Apache Harmony Dev List
Subject: Supporting working on a single module?
As the Harmony Classlib
Nathan Beyer wrote:
Perhaps this is a bit of an aside, but one of the biggest difficulties I
have when trying to develop against a single module is the availability of
the test support classes. Currently, I run the ant build and run the
'compile-support' to build the test support classes. Then
Mark Hindess wrote:
On 9 May 2006 at 10:32, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the
typical way of working for many (perhaps even most)
AM
To: Apache Harmony Dev List
Subject: Supporting working on a single module?
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the typical
way of working for many (perhaps even most) contributors. So I think
we need
If you are working on Windows and don't have a C development environment
setup the build fails right away. It might be useful to provide a
mechanism for obtaining the windows binary components so people who are
only interested in the java parts of harmony can build everything after
a
The existent snapshot is intended for this purpose. However I'm not 100%
sure it will help
for your case when the C development environment is absent. I mean the
default Windows installation
should contain some set of dynamic libaries the snapshot can loaded at
runtime.
Thanks,
Vladimir.
On
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the typical
way of working for many (perhaps even most) contributors. So I think
we need a plan to support this. I also think that forcing ourselves
to support this mode
Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the typical
way of working for many (perhaps even most) contributors.
Sure, that makes sense.
So I think
we need a plan to support this. I also
On 9 May 2006 at 10:32, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mark Hindess wrote:
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the
typical way of working for many (perhaps even most) contributors.
Hi Mark,
Mark Hindess wrote:
Can you not work on a single module now?
Yes. But only by checking out everything.
I am developing a API stubs project, which is a full stubs
implementation of the Java 1.5 API. My objective was actually to allow
for not needing an API implementation to compile
On Tuesday 09 May 2006 22:03, Etienne Gagnon wrote:
Yes. But only by checking out everything.
I am developing a API stubs project, which is a full stubs
implementation of the Java 1.5 API. My objective was actually to allow
for not needing an API implementation to compile code against the
Chris Gray wrote:
On Tuesday 09 May 2006 22:03, Etienne Gagnon wrote:
Yes. But only by checking out everything.
I am developing a API stubs project, which is a full stubs
implementation of the Java 1.5 API. My objective was actually to allow
for not needing an API implementation to compile
Chris Gray wrote:
On Tuesday 09 May 2006 22:03, Etienne Gagnon wrote:
Yes. But only by checking out everything.
I am developing a API stubs project, which is a full stubs
implementation of the Java 1.5 API. My objective was actually to allow
for not needing an API implementation to compile
Geir scripsit:
For what my opinion is worth (on a good day, a cup of coffee, but not at
Caffè Florian), this would be an excellent thing to have. It will never
be easy to work on the core Java APIs in a totally modular way (because
Sun didn't design things that way), but with such a set
Tim Ellison wrote:
Chris Gray wrote:
On Tuesday 09 May 2006 22:03, Etienne Gagnon wrote:
Yes. But only by checking out everything.
I am developing a API stubs project, which is a full stubs
implementation of the Java 1.5 API. My objective was actually to allow
for not needing an API
Geir Magnusson Jr wrote:
Tim Ellison wrote:
I disagree -- we spent a good period of time last summer carving up the
class library into modules defined by Java and internal APIs. I believe
it would be detrimental to disregard these boundaries by compiling
against the entire Java APIs, as that
Chris Gray wrote:
On Tuesday 09 May 2006 23:26, Tim Ellison wrote:
Geir Magnusson Jr wrote:
I guess the question for me, now that I thought about it longer, is
where would we use the separate stub library? I can see us filling in
our blanks w/ stubs for whatever reason (totally fooling
-Original Message-
From: Mark Hindess [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 09, 2006 9:07 AM
To: Apache Harmony Dev List
Subject: Supporting working on a single module?
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules
-
From: Mark Hindess [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 09, 2006 9:07 AM
To: Apache Harmony Dev List
Subject: Supporting working on a single module?
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the typical
way
, May 09, 2006 9:07 AM
To: Apache Harmony Dev List
Subject: Supporting working on a single module?
As the Harmony Classlib grows, I think that being able to work on a
single module (or some subset of the modules) will become the typical
way of working for many (perhaps even most
61 matches
Mail list logo
