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 <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>
>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, [EMAIL PROTECTED] 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/
>>>>>>
>>>>>
>>
>
>
