The change adds annotations for all methods inside the class. The initial idea - enforce checks of symlink methods to prevent NPEs on Windows platforms.
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
Retrying 3 times while waiting for 100 millis between retries (at
recreating symlink after "deleting" it). Ends up throwing FAE exception
if thrown for a 4th time in a row - as not much can be done at that
point. A warning is logged in that case, prior to throwing the last FAE.
Given these <variable,value> mappings: <A,a> and <A.B,a-b>, $A.B would
evaluate to $a.B, as it currently does, and ${A.B} to a-b instead of the
current ${A.B}.
Existing ${A.B}-like references will break (not evaluate to ${A.B}) if
there actually is an A.B variable defined, which I think is very
unlikely.
Apparently the Maven 2 process factory fails to adequately insulate the Maven process from Jenkins library dependencies;
if you specify a build extension that can override dependencies used by Jenkins core classes!
A real fix would involve changing class loader delegation, since presumably similar bugs could still occur.
On Chrome (and possibly others), an inline element like span doesn't enlarge
its size to cover its content, so the 1px place holder wasn't taking effect.
To ensure the minimum height of 16px, make it an inline-block element. I'm
not entirely sure how an inline-block element with no fixed width would behave,
but with a bit of casual testing, the text inside seems to wrap OK.
- ID_FORMATTER is time zone sensitive, so comparing against # of
milliseconds since the epoch won't be portable.
- resolveSymlink can return a relative path.
Remember the permalink target as symlink (or simple text file) so that
looking that up doesn't cause the walk of the build history.
I think this is more in line with our general preference of making
$JENKINS_HOME useful (than trying to persist cache into a blackbox.)
Having a general purpose in-memory cache could be useful, so I'll see if
I can add that, too, in a way that allows someone to plug different
backend.
b5ed319 already caught linkage errors but then unconditionally returned false from Util.isSymlink, which is wrong;
we want to fall back to the generic File.canonicalPath comparisons in this case.
(Not doing so for resolveSymlink since it would require an awkward four-way return value:
String, null (not a symlink), IOException, <something else> for Java 5/6.)
Stephen Connolly