river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [PROPOSAL] Source drop and bug database
Date Thu, 04 Jan 2007 19:00:01 GMT

On Jan 4, 2007, at 1:45 PM, Craig L Russell wrote:

>
> On Jan 4, 2007, at 9:06 AM, Jeff Ramsdale wrote:
>
>> I see on the site that there's a menu section entitled
>> "Subcomponents." Is that intended to be a mechanisms for organizing
>> sub-projects? Specifically, should the code repository and site
>> reflect a separation between the core code and the TCK and (possibly)
>> other subcomponents?
>
> Excellent question. If there are clearly separate components that  
> can be shipped or used separately, it makes sense to have separate  
> sub-projects to reflect the components, with dependencies documented.
>
> For example, if there exist a common core with bootstrap code, and  
> an implementation that depends on the core, the structure of the  
> code could look like:
>
> river/
>   site/
>   trunk/
>     core/
>       src/
>         java/
>           org/
>             apache/
>               river/
>     service-file/
>       src/
>         java/
>           org/
>             apache/
>               river/
>     service-print/
>       src/
>         java/
>           org/
>             apache/
>               river/
>
> Each sub-project under trunk builds its own jar file for distribution.

We have something similar in harmony - we have the main components  
distinct because they can be versioned separately

    harmony/classlib/trunk
    harmony/drlvm/trunk
    etc

and then a "federated build point" :

    harmony/trunk

which uses the magic of svn to create


    harmony/trunk
                /working_classlib
                /working_vm
                /working_jdktools
                /commonresources

so from the POV of trunk, you have one big tree, yet each of those  
subdirs had a svn switch done to them so working in

     harmony/trunk/working_classlib

is the same as working in

     harmony/classlib/trunk

It works very nicely - its very convenient to work in, and means that  
in the future, other VMs or such can be swapped in w/o disruption of  
the current subprojects.

geir

>
> Craig
>
>> For instance, is there any benefit in organizing
>> the Sun service implementations accordingly as well?
>>
>> Jeff
>>
>> On 1/4/07, Jim Hurley <Jim.Hurley@sun.com> wrote:
>>> Another piece we should probably consider as part of
>>> the initial codebase (or maybe to include down the line)
>>> is the "Jini Technology Lookup, Discovery, and Join
>>> Compatibility Kit" (LDJ).  You can find it under "Associated
>>> Downloads" at:
>>> <https://starterkit.dev.java.net/downloads/index.html>
>>>
>>> Way back when :-)   under the SCSL, something similar
>>> was named the "Technology Compatibility Kit" (TCK) and
>>> was a legal measure for helping to ensure compliance for
>>> commercial implementations.
>>>
>>> I think some people have found it generally handy over
>>> time to use to test their Jini service, etc -- so it might be
>>> good to include.
>>>
>>> Thoughts?
>>>
>>> -Jim
>>>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>


Mime
View raw message