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.
| Summary: | [TCR - sharable libraries] use URI for relative values instead of URL | ||
|---|---|---|---|
| Product: | projects | Reporter: | David Konecny <dkonecny> |
| Component: | Libraries | Assignee: | David Konecny <dkonecny> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | apireviews, jglick, mkleint, pjiricka, tzezula |
| Priority: | P3 | Keywords: | API_REVIEW_FAST |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: |
project.libraries.diff
java.project.diff implementation changes in project.ant |
||
|
Description
David Konecny
2008-03-10 01:46:39 UTC
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. |