Hi Kelly, thank you, and I also found the same thing described on the internal page you set up. I'm thinking right now my original question probably doesn't have a strong use-case-justification. Is there any reason to check out just one of the repositories? (just one tree rather than the whole forest) 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?? And also the parent/child relationships between those repositories? (This might be OT for discussion in the guide) - David Kelly O'Hair wrote:

These are forests, use fclone rather than clone, and the first time you need to make sure the destination does not exist, e.g.

rm -f -r my2d hg fclone http://hg.openjdk.java.net/jdk7/2d my2d

-kto

David Herron wrote:

...

The discussion about per-component repositories [1] doesn't seem to match reality.

If one wanted to check out just one component-area workspace it's not clear how to proceed from the guidebook description. It says the URL pattern is: <release>/<project>{-gate}?/<component>

<release> obviously is 'jdk7' ... but then precisely what value is used for '<project>' and '<component>'

The page lists project names such as '2d' so perhaps one of these would work

hg clone http://hg.openjdk.java.net/jdk7/2d hg clone http://hg.openjdk.java.net/jdk7/jdk7/2d

But those result in a directory containing just the license & README & make files, and no source.

On the other hand this following results in just the CORBA repository being checked out

hg clone http://hg.openjdk.java.net/jdk7/jdk7/corba

- David Herron

[1] http://openjdk.java.net/guide/repositories.html#term _______________________________________________ guide-discuss mailing list guide-discuss@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/guide-discuss

David Herron wrote:

Hi Kelly, thank you, and I also found the same thing described on the internal page you set up.

I'm thinking right now my original question probably doesn't have a strong use-case-justification. Is there any reason to check out just one of the repositories? (just one tree rather than the whole forest)

Yes, in some cases, there may be a valid reason to just get one repository or a partial forest. A developer may wish to focus on certain repositories and ignore the rest until it's time to push the changes. It depends on what the team considered acceptable practice. For example, the hotspot team does almost all there work without ever building a jdk themselves. They have the ability to isolate their work and test it using a promoted jdk image. All repositories (except for the enclosing repository) is independently buildable and can be worked on by developers independently.

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?? And also the parent/child relationships between those repositories?

There are multiple dimensions here. The basic OpenJDK forest contains 7 unique repositories, an enclosing repository plus corba, hotspot, jaxp, jaxws, jdk, and langtools. Every repository is represented as a pair, the pull (http) repository and the push (ssh) "-gate" repository. So each forest is actually implemented with 14 (7*2) repositories. The master area is jdk7/jdk7 and it's child team areas are: jdk7/2d jdk7/awt jdk7/build jdk7/corba jdk7/hotspot (has children: jdk7/hotspot-comp, jdk7/hotspot-gc, jdk7/hotspot-rt, jdk7/hotspot-svc) jdk7/i18n jdk7/jaxp jdk7/jaxws jdk7/jsn (may be a child of jdk7/tl?) jdk7/l10n jdk7/modules (may be a child of jdk7/tl? Or special project?) jdk7/nio2 (may be a child of jdk7/tl? Or special project?) jdk7/swing jdk7/tl The jdk7/modules and jdk7/nio2 may be considered "projects" and may or may not push directly to the master area. I'm not sure about those, the team gets to decide. A project may create many changesets that could at project completion get folded together into fewer official changesets that get pushed into the master area eventually. It depends on the team and the project. We are trying to be flexible but at the same time make sure the changesets that get integrated follow the rules we have setup. -kto

(This might be OT for discussion in the guide)

- David

Kelly O'Hair wrote:

...

These are forests, use fclone rather than clone, and the first time you need to make sure the destination does not exist, e.g.

rm -f -r my2d hg fclone http://hg.openjdk.java.net/jdk7/2d my2d

-kto

David Herron wrote:

...

The discussion about per-component repositories [1] doesn't seem to match reality.

If one wanted to check out just one component-area workspace it's not clear how to proceed from the guidebook description. It says the URL pattern is: <release>/<project>{-gate}?/<component>

<release> obviously is 'jdk7' ... but then precisely what value is used for '<project>' and '<component>'

The page lists project names such as '2d' so perhaps one of these would work

hg clone http://hg.openjdk.java.net/jdk7/2d hg clone http://hg.openjdk.java.net/jdk7/jdk7/2d

But those result in a directory containing just the license & README & make files, and no source.

On the other hand this following results in just the CORBA repository being checked out

hg clone http://hg.openjdk.java.net/jdk7/jdk7/corba

- David Herron

[1] http://openjdk.java.net/guide/repositories.html#term _______________________________________________ guide-discuss mailing list guide-discuss@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/guide-discuss

---

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

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

Hi.

...

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.

I would like to offer the following guidance.

If you're changing the layout of any part of the JDK, you really should do a full build on the whole repository, at least including images (generally as the last step before integrating). Yes, the file may have compiled correctly, but then something such as the images target broke, or the file wasn't included in the final rt.jar. There's a lot more than javac to be concerned with when you're moving target files around. Gatekeepers don't particularly enjoy last minute images target breakage. ;)

I think that thare are many types of changes for which I'd advise full builds prior to commit. Off the top of my head, here are a few more cases that I've run into: - A new class is added as part of the change. The unqualified class name is identical to that of another class in a different package. If any existing class in the JDK happens to do a star import of both packages and uses the unqualified class name, the compiler will report an ambiguity. Here's a short example: import java.awt.*; import java.util.*; class A extends List {} Believe it or not, this sort of thing happended during my very first integration! - If you work with incremental builds and are modifing any files which are built during bootstrap, it's possible that those files may compile just fine after bootstrap, but they won't compile during bootstrap. - Just because an API isn't public, doesn't mean that other parts of the JDK don't depend on its presence or precise semantics. At best, this is found during a full build. At worst the problem isn't found until an application/test is run. (Yes, that means they were probably using reflection.) There are multiple horror stories. I'd say that these cases are rare, but I'm sure any gatekeeper ("integrator" if you're using the old terminology) will appreciate if a full build was done at some point prior to commit. I stand by my statement that any developer working with only part of the forest needs to be extremely comfortable with the build structure and any potential side-effects their modifications may cause. iris