Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of GHARLEY@uk.ibm.com designates
 195.212.29.137 as permitted sender)
In-Reply-To: 
 <15243499.1136332928075.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
To: harmony-dev <harmony-dev@incubator.apache.org>
Subject: Re: repo layout again
MIME-Version: 1.0
Message-ID: 
 <OFCDFF8532.D60C89A8-ON802570EC.003C55A6-802570EC.00408F8E@uk.ibm.com>
From: George Harley1 <GHARLEY@uk.ibm.com>
Date: Wed, 4 Jan 2006 11:45:02 +0000
Content-Type: text/plain; charset="US-ASCII"

Hi Dan, 

By "the java.lang.*/java.io.*/etc. classes that have key native methods 
tied to the VM" you mean the set of classes labelled as "kernel classes" 
in HARMONY-14. The existing documentation for these classes (see 
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/kernel_doc/html/index.html#KernelJavaClasses) 
states that "the VM writer is expected to entirely implement" these 
classes which suggests that your proposal to break these out independent 
of the class libraries is the way to go. 

With the implementation of the kernel classes completely under the control 
of the VM writer it is then an internal design decision whether or not to 
realise a given method as a native or as pure Java. So long as these 
kernel classes adhere to the expected interface from the perspective of 
the classlib then there is no real issue. Meanwhile a dummy/stub 
implementation of the kernel classes would still be required in the 
classlib source tree simply to enable compilation to complete. 

Does that sound reasonable ?

Best regards,
George
________________________________________
George C. Harley


"bootjvm@earthlink.net" <bootjvm@earthlink.net> 
04/01/2006 00:02
Please respond to
harmony-dev@incubator.apache.org


To
harmony-dev <harmony-dev@incubator.apache.org>
cc

Subject
Re: repo layout again


Some more platform tree names:

    solaris32.sparc solaris64.sparc
    linux32.sparc linux64.sparc
    darwin32.ppc (Is this correct for the new MAC boxes?)


One of the things that has never come up in this discussion
has been the possible breakout of the java.lang.*/java.io.*/etc.
classes that have key native methods tied to the VM.  These
are currently set to 'method(int p1, char p2) { return(dummy_value); }'
in the initial contribution, but will need to be converted to
become 'native method (int p1, char p2);' in any real
implementation.  I would propose to break these out in some
meaningful way to be independent of the rest of the class
library, or possibly independent but absorbed into the class
library, where the actual native code implementation is _not_
provided there, but is found in the VM code where it naturally
belongs.  What to you think?  What other suggestions do you
have?


Dan Lydick

-----Original Message-----
>From: George Harley1 <GHARLEY@uk.ibm.com>
>Sent: Jan 3, 2006 4:57 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: repo layout again
>
>Hi, 
>
>How does this sound for the layout of a given module/component/thing (in 
>this case "luni") ...
>
>classlib/trunk
>           |
>           +--java-src
>                |
>                +--luni
>                   |
>                   |
>                   +---src
>                   |    |
>                   |    +--main
>                   |    |   |
>                   |    |   +--<platform>
>                   |    |          |
>                   |    |          +--native
>                   |    |          |
>                   |    |          +--java
>                   |    |          |
>                   |    |          +--resources
>                   |    |
>                   |    +--test
>                   |        |
>                   |        +--java
>                   |        |
>                   |        +--resources
>                   | 
>                   | 
>                   +--doc
>
>
>
>where the value of <platform> comes from the set of agreed identifiers 
for 
>all operating systems we build/run on that have platform-specific code 
>together with the "common" identifier for all platform-neutral code. 
There 
>would be multiple <platform> subdirectories under the "main" folder like 
>this  ...
>
>
>                   +---src
>                   |    |
>                   |    +--main
>                   |    |   |
>                   |    |   +--common
>                   |    |   |    |
>                   |    |   |    +--native
>                   |    |   |    |
>                   |    |   |    +--java
>                   |    |   |    |
>                   |    |   |    +--resources
>                            |
>                            |
>                            +--win32.x86
>                            |    |
>                            |    +--native
>                            |    |
>                            |    +--java
>                            |    |
>                            |    +--resources
>                            |
>                            |
>                            +--linux32.x86
>                            |    |
>                            |    +--native
>                            |    |
>                            |    +--java
>                            |    |
>                            |    +--resources
>                            |
>                            ...etc...
> 
>
>
>I'm keeping my fingers crossed that my mail client doesn't completely 
mess 
>up the above formatting. 
>
>Best regards, 
>George
>________________________________________
>George C. Harley
>
>
>
>
>
>Geir Magnusson Jr <geir@pobox.com> 
>30/12/2005 16:34
>Please respond to
>harmony-dev@incubator.apache.org
>
>
>To
>harmony-dev@incubator.apache.org
>cc
>
>Subject
>Re: repo layout again
>
>
>
>
>
>
>
>
>Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>> 
>>>does this follow from the convo re layout we had last week?
>> 
>> 
>> yes, plus me trying to follow along with an Eclipse set-up to do
>> development.
>
>Ah - that's key for you.  Please help us Eclipse journeymen when you get 
>it figured out...
>
>> 
>> 
>>>We'd
>>>prollie want to rename java-src to something else being it's more like 
a
>>>module than just java...
>> 
>> 
>> Well today it _is_ just java (and a bit of metadata) in there, but I
>> agree that thoughts of making them a bit more than that is goodness.
>> 
>
>I thought we'd given some serious thought and had some kind of agreement 
>that it's worth putting the natives for a given module in that module (I 
>won't use the term 'component' there)
>
>That would mean :
>
>modules/
>    luni/
>       java-src/
>           ... your tree for luni java
>       native-src/
>           ... your tree for luni natives
>
>
>geir
>
>> Regards,
>> Tim
>> 
>> 
>>>Tim Ellison wrote:
>>>
>>>
>>>>beats me :-)
>>>>
>>>>I was following along with the Maven standard directory structure [1] 
>as
>>>>much as possible, since we might as well do that rather than invent
>>>>something gratuitously different.  (I know nothing about maven, and 
I'm
>>>>open to changing the structure to suit the majority.)
>>>>
>>>>This is where I was heading:
>>>>
>>>>.../classlib/trunk/
>>>>  java-src/                 <- poor name, easily changed later
>>>>    <component_name>/
>>>>      make/               <- component-level build script
>>>>      src/
>>>>        main/
>>>>          java/
>>>>            org/apache/harmony/...  <- impl types
>>>>            java/<whatever>/...     <- Java API types
>>>>          resources/
>>>>        test/
>>>>          java/
>>>>            org/apache/harmony/...  <- unit tests
>>>>          resources/
>>>>      META-INF/MANIFEST.MF         <- OSGi manifest
>>>>    <component_name_2>/
>>>>      ...
>>>>  make/                 <- 'bootstrap'/global build script
>>>>  target/               <- results of builds
>>>>
>>>>  native-src/   <- I'm going to leave the natives structure
>>>>                   alone for the moment
>>>>
>>>>I guess the main omission at the moment is a location for
>>>>platform-specific code, I didn't see anything on the maven site about
>>>>that.
>>>>
>>>>[1]
>>>>http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
>>>>
>>>>
>>>>Regards,
>>>>Tim
>>>>
>>>>Geir Magnusson Jr. wrote:
>>>>
>>>>
>>>>>what does "main" mean?
>>>>>
>>>>>
>>>>>On Dec 29, 2005, at 8:31 AM, tellison@apache.org wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Author: tellison
>>>>>>Date: Thu Dec 29 05:31:44 2005
>>>>>>New Revision: 359782
>>>>>>
>>>>>>URL: http://svn.apache.org/viewcvs?rev=359782&view=rev
>>>>>>Log:
>>>>>>Restructuring NIO component layout to allow main and test 
co-location
>>>>>>
>>>>>>Added:
>>>>>>   incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/main/
>>>>>>   incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/test/
>>>>>>   incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/test/
>>>>>>java/
>>>>>>   incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/test/
>>>>>>resources/
>>>>>>Removed:
>>>>>>   incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/com/
>>>>>>   incubator/harmony/enhanced/classlib/trunk/java-src/nio/src/java/
>>>>>>
>>>>>
>> 
>
>