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
