From kelly.ohair at oracle.com Mon Aug 1 05:41:01 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 1 Aug 2011 07:41:01 +0200 Subject: Forest Extension - Not to be found? In-Reply-To: References: <4e0e453a.dc97d80a.15ce.ffffc76c@mx.google.com> <1310067123.4394.1.camel@galactica> <4E2CA046.2030801@gatworks.com>

<6AB6C50C-810E-41B6-91BF-45368C08F279@oracle.com> <5C722A5A-1CB6-4719-9628-4D1B17EDDA4B@oracle.com> <589D37EA-2192-41F0-BB14-21115772DA00@oracle.com> <4E2F997C.7000509@oracle.com> <1311781667.2830.7.camel@galactica>

Message-ID: <9C90D6AE-4EB6-4C10-AE9B-5A51795FF0D3@oracle.com> I generally get my own ant 1.7.1, install it, and put that one in my PATH and set ANT_HOME to refer to it. It gets me much more predictable build behavior. --- The basic ant launching issue is probably one of the most troublesome part of using ant in our build processes, it is extremely hard to get predictable behavior over all our build platforms with ant. -kto On Jul 31, 2011, at 6:12 PM, Mario Torre wrote: > 2011/7/28 Mario Torre : > >> I'll write down some proposal for the README files and propose them >> here then. I will try to send you hopefully tomorrow a patch for the >> Makefile as well. > > I'm trying to build the JDK8 with a local JDK7 as a dependency, on > Fedora 15, but I'm stuck at the very beginning: > > make[2]: Entering directory > `/home/neugens/work_space/netbeans/jdk8-build/langtools/make' > JAVA_HOME=/home/neugens/work_space/netbeans/jdk7u/build/linux-amd64/j2sdk-image/ > ANT_OPTS=-Djava.io.tmpdir='/home/neugens/work_space/netbeans/jdk8-build/build/linux-amd64/langtools/build/ant-tmp' > ant -diagnostics > > /home/neugens/work_space/netbeans/jdk8-build/build/linux-amd64/langtools/build/ant-diagnostics.log > ; \ > JAVA_HOME=/home/neugens/work_space/netbeans/jdk7u/build/linux-amd64/j2sdk-image/ > ANT_OPTS=-Djava.io.tmpdir='/home/neugens/work_space/netbeans/jdk8-build/build/linux-amd64/langtools/build/ant-tmp' > ant -version >> > /home/neugens/work_space/netbeans/jdk8-build/build/linux-amd64/langtools/build/ant-diagnostics.log > Error: Could not find or load main class org.apache.tools.ant.launch.Launcher > Error: Could not find or load main class org.apache.tools.ant.launch.Launcher > make[2]: *** [/home/neugens/work_space/netbeans/jdk8-build/build/linux-amd64/langtools/build/ant-diagnostics.log] > Error 1 > make[2]: Leaving directory > `/home/neugens/work_space/netbeans/jdk8-build/langtools/make' > make[1]: *** [langtools-build] Error 2 > make[1]: Leaving directory `/home/neugens/work_space/netbeans/jdk8-build' > make: *** [build_product_image] Error 2 > > Doing some debug it seems that the ant script launches at some point a > script called "build-classpath", which tries to build the classpath > and set it as an environment variable, but fails for some reason. > > I can bypass this script but then the ant itself fails because it > doesn't find the correct jars. > > Now, I think this maybe a Fedora 15 bug, although those scripts do not > seem to be completely tied to Fedora (that means this can be a bug > affecting other distribution using the jpackage system that seems to > be behind this build-classpath script). > > It maybe that building the JDK using a boot JDK other than > ALT_BOOTDIR=/usr/lib/jvm/java-openjdk doesn't work, at least of F15 > (which is not exactly the best Linux distribution around to be > honest). > > Does anybody here (Andrew, Mark?) have experienced similar issues? > > I'm sure there is an easy way to set all this configuration stuff, but > probably we need to tweak the makefiles to support that. > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Proud GNU Classpath developer: http://www.classpath.org/ > Read About us at: http://planet.classpath.org > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ From donald.smith at oracle.com Mon Aug 8 20:29:39 2011 From: donald.smith at oracle.com (Donald Smith) Date: Mon, 08 Aug 2011 16:29:39 -0400 Subject: OCA Updated to 1.7 Message-ID: <4E404733.7070903@oracle.com> Hi, This note is to inform everyone that the OCA has been updated to version 1.7 [1]. The goal of this rev was to clean up some of the language that frequently caused confusion, and also the make the signature block less prone to error/misunderstanding. There are otherwise no substantive changes. The OCA FAQ update is a bit behind, and will be posted to reflect the new version within the next couple weeks. Please feel free to contact me directly with any questions, - Don [1] - http://openjdk.java.net/legal/ From mark.reinhold at oracle.com Wed Aug 24 17:19:35 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 24 Aug 2011 10:19:35 -0700 Subject: JDK Enhancement-Proposal & Roadmap Process -- DRAFT In-Reply-To: stuart.marks@oracle.com; Tue, 28 Jun 2011 12:17:07 PDT; <4E0A28B3.1070208@oracle.com> Message-ID: <20110824171935.712794EE@eggemoggin.niobe.net> 2011/6/28 12:17 -0700, stuart.marks at oracle.com: > I have a question about how the process, and specifically the proposal > template, deals with changes of a "horizontal" or "cross-cutting" nature. From > the template, > >> - Proposal template >> http://cr.openjdk.java.net/~mr/jep/jep-template > > there is a fairly specific hierarchy of areas and components: > > // We use two-part identifiers of the form /. > // > // The areas are: vm, core, client, web > // > // The components depend upon the areas, as follows: > // > // vm: comp, gc, rt, svc > // core: lang, libs, i18n, net, sec, svc > // client: gui, sound > // web: jaxp, jaxb, jaxws, corba > > This scheme lends itself well to enhancements in a specific component, as most > enhancements are. But there's a different kind of enhancement that doesn't seem > to fit well into the area/component form. > > Consider the following example proposal: ... > > A proposal like this doesn't seem to fit into a single area/component. It seems > unreasonable to require multiple similar proposals for different > components. I'm not sure of a good alternative though. Maybe we create a new > pseudo-component or even pseudo-area to indicate proposals of a horizontal > nature. Or perhaps we just say core/* or even */* (though the latter does seem > unlikely). That's actually the idea. Further down in the draft template [1] it says: // Use "--" for the component name if more than one component in an area // is significantly affected, or if some component not listed here is // affected. // // Use "--/--" for the value of this header if more than one area is // affected, e.g., for a proposal to restructure the build process. On reflection the traditional glob symbol '*' makes more sense, so I'll change the template to use that. > By the way, I don't think this example is a special case. ... Agreed. > Another minor concern I have is the actual breakdown of components in the core > area. Consider things like io, nio, and rmi. Do they fit into libs and net, or > are they their own components? This isn't really a big deal; we just need to > make sure we've established the right set of items in the area/component > hierarchy. I think the above structure is a reasonable starting point. It isn't cast in stone. I expect the set of areas and (more likely) components to evolve (slowly) over time. If absolutely necessary we can always go back and re-categorize old JEPs if the structure changes significantly. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-template