Please review the fix for the CR mentioned in the subject. The webrev:
http://cr.openjdk.java.net/~anthony/webrev-6833444.0/
I verified the fix on MS Windows platform, and it works pretty well.
--
best regards,
Anthony
Hi Xiomara,
Thank you for the comments!
On 4/23/2009 6:27 PM Xiomara Jayasena wrote:
Release Engineering uses c:\jdk ... when building on windows. We will
still need that.
Ups. I'm sorry about that, I really didn't know you use this path. This
was the reason I initiated the discussion on the
Sorry I'm so slow in responding to this...
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have
Hi Anthony,
We do set ALT_BOOTDIR all the time.
From Kelly:
Having said all that, I ALWAYS set ALT_BOOTDIR to my local copy
(and ALT_JDK_IMPORT_PATH too). So I probably would not be impacted
by this change, but I bet quite a few people rely on this c:/jdk1.6.0
default. With enough warning you
As I emailed earlier, I'd be ok with this change but only if RE (Xiomara)
was ok with it, and we made sure everyone was warned well in advance.
Also, the change is incomplete because the README-builds.html file probably
would need to change too.
-kto
Anthony Petrov wrote:
Please review the
Adding a sanity check warning about J:/ usage would be a nice addition
to this change.
-kto
Jonathan Gibbons wrote:
Kelly,
Perhaps make sanity on Windows could give a warning about the use
of network paths, if such is detected.
-- Jon
Kelly O'Hair wrote:
Sorry I'm so slow in responding to
On 4/23/2009 10:31 PM xiomara.jayas...@sun.com wrote:
We do set ALT_BOOTDIR all the time.
From Kelly:
Having said all that, I ALWAYS set ALT_BOOTDIR to my local copy
(and ALT_JDK_IMPORT_PATH too). So I probably would not be impacted
by this change, but I bet quite a few people rely on this
On 4/23/2009 10:15 PM Kelly O'Hair wrote:
The primary reason for the special case on Windows is the unreliability
and slowness of the network connections.
Builds using a local jdk vs. a J:/ mapped can be 5 hours long when
they might normally be 1hr or less. These just come from reports I
have
Jon, Kelly,
Then what about the default builds on Linux/Solaris that do use the
/java share and do not issue any warning message? I agree that these
builds are generally much faster than on Windows, but still. Besides, as
I mentioned before, on my local systems the /java directory and the J:
Anthony,
On pretty much any system you can tell if a drive is local or not,
albeit in a system specific way.
-- Jon
Anthony Petrov wrote:
Jon, Kelly,
Then what about the default builds on Linux/Solaris that do use the
/java share and do not issue any warning message? I agree that these
This sanity check would be a nice to have thing, but it it can't
be done in a simple way I'm not sure I want to see a bunch of convoluted
logic added, we have too much of that already :^(
And it does go beyond your intended change. Maybe a separate bug for
another time, like a sanity warnings on
11 matches
Mail list logo
