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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
