Created attachment 58715 [details]
project.libraries.diff

Created attachment 58716 [details]
java.project.diff

Created attachment 58717 [details]
implementation changes in project.ant

As agreed on API review I'm changing/enhancing APIs to use URI instead or in addition to URL to support handling of
relative paths within project, mainly in libraries area. Diff of API changes is attached. Changes in clients of this API
 are not fully finished yet in all areas and I can attach them later if needed. But because it is mainly changing URL to
URI I would like to start API review discussion ASAP as code freeze is close.

* project.libraries.diff - library content (both API and SPI) can be get/set as list of URLs or URIs

* java.project.api - in order to add relative folders/jars to classpath I had to add
ProjectClassPathModifier.[add|remove]Roots(URI,...). There are two TODO items to be implemented.

* project.ant.diff - no API changes, just implementation, just FYI

Thanks for the review and your comments in advance. -David

looks cool to me.

Does LibraryCustomizerContext have to have a public constructor? Can it be final?

Otherwise looks reasonable to me.

Thanks for the review guys.

Adding forgotten API_REVIEW_FAST keyword.

Re. "Does LibraryCustomizerContext have to have a public constructor? Can it be final?" - it is constructed in different
package (in project/libraries/ui/LibrariesCustomizer.java) and in the same place it is also extended purely for backward
compatibility - see Javadoc for LibraryCustomizerContextWrapper. I could use accessory pattern to make constructor
private. But considering that extending that class or using it directly is of no use for SPI clients I thought that
Javadoc saying "do not instantiate, do not extend" would be sufficient. Should I implement accessory pattern?

If you do not object I would like to deliver this change on Wednesday (+/-) noon Prague time.

Without looking at your code: Of course use of accessor pattern is my preferred solution. But if you decide to not use 
it, I'd like to advocate a guard in constructor: if (!getClass().getName().equals("org.nb.your.impl.Clazz")) { throw 
new ISE(); }

Re. "accessory pattern or guarded constructor" - I used guarded constructor in this case. Thanks for suggestion.

While implementing clients I decided to added three new API helper methods which were needed repeatedly:
* ProjectClassPathModifierImplementation.convertURLsToURIs
* LibrariesSupport.getArchiveFile
* LibrariesSupport.getArchiveRoot
Let me know if you have any objections. Thanks.

Delivered to trunk:
http://hg.netbeans.org/main?cmd=changeset;node=e2ebb3b53130

Done.