Iris,

As I said earlier, it is common to work on langtools in isolation. The primary tests for the compiler
are the regression tests in the same workspace, and JCK, which is separate.  The build system is primarily
Ant, and NetBeans friendly, with Makefile wrappers, as compared to the Makefiles and ant/NetBeans
wrappers in, say, the jdk repository. My understanding is that the new EE repositories
(jaxp, corba, etc) are more similar to langtools than jdk, in that respect.

I agree that doing a full build is often useful, but to me, it makes more sense to have a single
forest in which I can "install" my repository and do a build there, when needed, rather
than to have every work area be a complete forest.

-- Jon


Iris Garcia wrote: 
Hi, David.

  
                           Is there any reason to check out just 
one of the repositories?  (just one tree rather than the whole forest) 
    

I debatted about that one for a while.  Given the way that various portions of
the build system currently works (for instance, it is difficult to get a
javadoc build if you only have a single repository in the forest), in my mind
developers should operate on forests by default... hence this comment in
"Respositories: Cloning":
 
  http://openjdk.java.net/guide/repositories.html#clone
  
  It is strongly recommended for developers to clone the entire
  project's forest, rather than a single repository. This is the only
  means to ensure consistency in builds. The follow example illustrates
  how to clone the entire tl forest into the directory mytl.

Here's what the Guide says about retrieving only a single repository in the
forest:

  If reading a limited portion of the source is the only goal, it is
  possible to clone a single repository from a project forest. For
  instance, this example shows how to clone the langtools repository
  from the tl project into the default destination directory.

Since I've always had partial repositories in the old "CodeManager" system
(sometimes consisting of only a single file or small directory), I can see many
other uses of a single repository.  In fact, I'm going to guess that large
portions of developers are going to care about only a single part of the
repository.  For instance, jaxws developers will probably largely operate on
the jaxws tree, so the other trees may not be interesting.  Similar comments
can probably be made for hotspot and language developers.  My guess is for this
approach to be successful, the developer needs to be very comfortable with the
build structure and any potential side-effects their modifications may cause.
For instance, as a developer in Core Libraries, it would seem that I only need
to retrieve the "jdk" portion of the repository since that's where the
implementation of those classes resides.  However, I would need to be pretty
confident to not do a full build of the entire forest before I did my commit.
Even if I was only modifying javadoc, I'd still need the forest for a full
javadoc build.

  
However there is the issue of the individual team repositories.  Is 
there a way to discover the full set of repositories we're hosting on 
openjdk.java.net??  
    

Yes, from the Guide, "Terminology and Naming Scheme":

  The OpenJDK repository forests are located at http://hg.openjdk.java.net/.

  
                     And also the parent/child relationships between 
those repositories?
    

I haven't verified the diagram for this, but I believe that the relationship is
similar to what we've had historically and it's something like this:

- MASTER
  - 2d
  - awt
  - build
  - corba
  - hotspot
    - hotspot-comp
    - hotspot-gc
    - hotspot-rt
    - hotspot-svc
  - i18n
  - jaxp
  - jaxws
  - l10n
  - tl
    - jsn
  - modules
  - swing

I'm not sure where "nio2" goes since it's not in use.  Logical candiates are
directly to the MASTER and to tl.  I'm also not certain how the serviceability
and JMX teams will be handling their putbacks.  I think they're going back
directly into TL, but I'd need to check the commit logs to verify.

Thanks,
iris


_______________________________________________
guide-discuss mailing list
guide-discuss@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/guide-discuss