Per-component repositories

[Jonathan Gibbons]

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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/guide-discuss
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/guide-discuss/attachments/20080305/9e4fb4f9/attachment.html