JDK8 Preliminary Repository Layout

[Phil Race]

Andrew,

Whilst almost everything you wrote is something I agree with (like getting
jcheck out there, not adding additional build tools/complexity), the one
thing I quite like right now comes up here I'd like to keep is the 
separate repos.
Its not just hotspot,  but I've been working on JDK for a long time now,
since before there was a hotspot and last year I built hotspot for the 
first time,
and even then only because I was working on the VS2010 compiler upgrade.

So I like that hotspot and jaxp/jaxws can be pre-built and pulled from an
import JDK in a way that doesn't slow down my builds, bloat the source
I need to pull via hg etc etc.

Maybe this doesn't matter to people who want to pull a full forest but
its great for those working on specific components. Which I believe is
most developers.

-phil.


On 3/9/2011 4:48 PM, Dr Andrew John Hughes wrote:
> 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
>>
>>