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.
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!
smime.p7s
Description: S/MIME cryptographic signature
