JDK8 Preliminary Repository Layout

[Paul Hohensee]

We could rename 'closed' to be 'oracle'.  You could then have the oracle 
build
be the common code plus the 'oracle' repo.  Add an 'icedtea' repo and you
could have the icedtea build be the common code plus the 'icedtea' 
repo.  Etc.,
for other versions/vendors.

Paul

On 3/9/11 7: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
>>
>>