This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. Should ask for results from one repo at a time, since it is likely that there will be a hit from the first one (local repo), in which case there is no need to download indices for remote repos. 2. Current code picks the first existing local artifact, but also picks the last-encountered local artifact even if it does not exist. This does not make sense. Anyway it is OK to return a nonexistent local artifact for use in the endorsed CP - if it appears later, the parser will rerun. (If the target/endorsed/*.jar was in fact downloaded by the Maven build, it will very likely still be available locally, so this is unlikely to matter. The most plausible exception would be if you built the project from a shell, cleaned your local repo, then opened the project in the IDE.) 3. In case there is in fact no repo match for some reason (broken index?), still should not include target/endorsed/*.jar in boot CP. Probably better to copy it to a temp dir. 4. Want some logging to diagnose problems in the field.
core-main #87a57d4562df
Integrated into 'main-golden', will be available in build *201105280401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/87a57d4562df User: Jesse Glick <jglick@netbeans.org> Log: #198936: Better repo lookup of target/endorsed/*.jar
Any news on whether this fix helps? There are a couple of weeks open to backport fixes to 7.0.1 but I am reluctant to backport a fix with no feedback.
At least in my case this appears to have made a difference in that the problem not longer occurs. Strangely after a successful run with the 201105280401 build the 7.0 version would clean and build without error. I confirmed that the fixed the problem on my "clean" alternate windows 7 box. I also tested a clean install of 7.0 of both windows XP SP3 and RHEL 5 and neither displayed the problem described in BUG 195195. So at least in my case the error was exclusive to Windows 7 Pro.
(In reply to comment #4) > Strangely after a successful run with the 201105280401 build the 7.0 version > would clean and build without error. Perhaps due to some repository index being updated by the time you tried it. > I confirmed that the fixed the problem on my "clean" alternate windows 7 box. Good, I will consider that verification. > I also tested a clean install of 7.0 of both windows XP SP3 and RHEL 5 and > neither displayed the problem described in BUG 195195. So at least in my case > the error was exclusive to Windows 7 Pro. Interesting. I would not expect any issue on Linux since this is related to file locking. But I would expect problems to occur interchangeably on XP and 7. (Unfortunately I have no copy of 7 to test on myself.) Bug #197927 is thought to only occur on Vista and 7, so it is possible the recent fix of that issue helped as well, though I think it is unrelated.
Backporting: releases #b3ace58fcf66