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.

Bug 129628 - [TCR - sharable libraries] use URI for relative values instead of URL
Summary: [TCR - sharable libraries] use URI for relative values instead of URL
Alias: None
Product: projects
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: David Konecny
Depends on:
Reported: 2008-03-10 01:46 UTC by David Konecny
Modified: 2008-03-27 02:56 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

project.libraries.diff (59.20 KB, text/plain)
2008-03-20 03:53 UTC, David Konecny
java.project.diff (8.98 KB, text/plain)
2008-03-20 03:53 UTC, David Konecny
implementation changes in project.ant (33.80 KB, text/plain)
2008-03-20 03:54 UTC, David Konecny

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2008-03-10 01:46:39 UTC
see SUBJ
Comment 1 David Konecny 2008-03-20 03:53:11 UTC
Created attachment 58715 [details]
Comment 2 David Konecny 2008-03-20 03:53:39 UTC
Created attachment 58716 [details]
Comment 3 David Konecny 2008-03-20 03:54:10 UTC
Created attachment 58717 [details]
implementation changes in project.ant
Comment 4 David Konecny 2008-03-20 04:09:38 UTC
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
Comment 5 Milos Kleint 2008-03-20 09:37:57 UTC
looks cool to me.
Comment 6 Jesse Glick 2008-03-20 15:30:32 UTC
Does LibraryCustomizerContext have to have a public constructor? Can it be final?

Otherwise looks reasonable to me.
Comment 7 David Konecny 2008-03-25 01:05:56 UTC
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/ 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.
Comment 8 Jaroslav Tulach 2008-03-25 11:27:41 UTC
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(); }
Comment 9 David Konecny 2008-03-27 02:55:58 UTC
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:;node=e2ebb3b53130
Comment 10 David Konecny 2008-03-27 02:56:39 UTC