JDK8 Preliminary Repository Layout

[Dr Andrew John Hughes]

On 18:32 Tue 08 Mar     , Kelly O'Hair wrote:
> 
> First, if we talk about the mercurial forests, it has nothing to do with the Mercurial Forest Extension.
> What we really have is a set of nested repositories, sometimes called our "forest" of repositories.
> 
> This email is just about the actual layout of the repositories for jdk8.
> 
> The initial thinking at this time is that the openjdk8 open forest will look very much like openjdk7:
> 
>    openjdk8/
>     corba/
>     jaxp/
>     jaxws/
>     jdk/
>     hotspot/
>     langtools/
> 
> 7 repositories total. Cloned from the openjdk7 repos so we will have all the openjdk7 history in the openjdk8 repositories.
> 
> Just for discussion sake, not that you can see what is behind the closed curtains, we are considering changing
> the closed overlay a little, from the current jdk7 (bold is a closed repo):
> 
>   jdk7/
>     corba/
>     deploy/
>     jaxp/
>     jaxws/
>     jdk/
>       src/closed/
>       test/closed
>       make/closed/
>     hotspot/
>       src/closed/
>       test/closed
>     install/
>     langtools/
>     pubs/
> 
> To something a little simplier like:
> 
>   jdk8/
>     corba/
>     deploy/
>     jaxp/
>     jaxws/
>     jdk/
>       closed/{src,test,make}
>     hotspot/
>       closed/{src,test,make}
>     install/
>     langtools/
>     pubs/
> 
> The existence of these closed repos should not be a surprise, and it should have no impact on the openjdk itself.
> We are just trying to consolidate and have fewer repositories. Just thought it might be of interest.
> 

Not surprised.  Also don't really care where you put them as I don't seem to have them either way ;-)

What I would ask is do the projects get this as well?  Specifially, I'd like an icedtea/jdk8 at the same time please.

> But back to the openjdk8 forest.
> 
> Other ideas were considered:
>   * Folding jaxp/jaxws into the root or jdk8/jdk repo

Sounds good.  jdk8/jdk would make more sense as jaxws depends on some classes that are in the jdk
tree (com.sun.net.httpserver) and we could then get rid of the Ant junk.  It would be good to have
the code there too so we can once again track changes.  The recent security issue was a nightmare
due to the unavailability of the source code.

>   * Separating out the jdk demos from the jdk repo to a separate "demos" repository

Makes sense.  Having an option to disable them would be a good first step.

>   * Separating out the client (awt/swing/etc) code from the jdk repo into a separate repo

Why would we want to do this?  IME, there are lots of interdependencies with the other code and
this would make the build a nightmare.

>   * Updating the corba sources changing it to an ant build

Please, no!  These Ant builds are already a nightmare and an order of magniture harder to debug than
the Makefiles.  Why you want to require a build system that requires an entire JDK setup (possibly
bringing another into the mix beyond the bootstrap JDK) is beyond me.

What would make much more sense is to just add corba into the jdk tree.  It actually requires sun.tools
classes to compile rmic anyway so it would make much more sense there.

Hey, I'd just make it all one repository as they all interdepend on each other, but the HotSpot folks
probably wouldn't like that... ;-)   Moving the HotSpot servicability agent into the JDK, where the
interfaces it uses lives, might be a good idea though.  I'm currently working on a patch which fixes
up a mismatch between the HotSpot SA implementation and the interfaces in the JDK which has existed
for who knows how long (it's certainly in OpenJDK6)...

> 
> None of this seemed urgent to do out of the gate, or delay getting a preliminary jdk8 layout defined.
> 

No, I agree with that.  Splitting off OpenJDK8 already seems overdue.

> I know there is some interest in pulling the actual jaxp/jaxws sources back into their repos, that will
> be discussed separately, we have multiple issues with that, but I am well aware of the pains that the
> source drop zip files have created.
> 

The problem is less technical and more social; there is no obvious way to interact with the JAXP and JAXWS
side of things.  We just get these zips of code with no idea of what changes are in there or why.

Basically, they shouldn't work either like they do now or did before, but like everything else in OpenJDK
with visible commits.  Hey, maybe we could even have some mailing list discussion if we're very lucky...

> As always, we would like to get comments, or additional ideas.
> 
> Separate topics:
>   * Forest Extension and it's replacement

Do we really need one?  Current status quo (get_source.sh) works fine.

>   * Mercurial server update to 1.8 or newer

I guess this is related to the forest issue.

>   * Build&Test system [1]
>   * Open bug tracking system [2]
> 

You missed off open sourcing that jcheck thing... that's the biggest problem I have with
the Mercurial server.  :-)

> -kto
> 
> [1]   http://mail.openjdk.java.net/pipermail/build-dev/2011-February/004112.html
> [2]   http://mail.openjdk.java.net/pipermail/web-discuss/2011-March/000153.html
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and IcedTea
http://www.gnu.org/software/classpath
http://icedtea.classpath.org
PGP Key: F5862A37 (https://keys.indymedia.org/)
Fingerprint = EA30 D855 D50F 90CD F54D  0698 0713 C3ED F586 2A37