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 51523 - API review of UnitTestForSourceQuery changes
Summary: API review of UnitTestForSourceQuery changes
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 4.x
Hardware: All All
: P3 blocker (vote)
Assignee: apireviews
URL:
Keywords: API_REVIEW_FAST
Depends on:
Blocks: 46354
  Show dependency tree
 
Reported: 2004-11-15 15:35 UTC by Tomas Zezula
Modified: 2004-11-23 16:24 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2004-11-15 15:35:58 UTC
The change to the UnitTestForSourceQuery and the
corresponding SPI is required to support projects
which have more than one source or test root.

See apichanges.xml:
http://www.netbeans.org/source/browse/java/api/doc/changes/apichanges.xml.diff?r1=1.10&r2=1.11
Comment 1 Jaroslav Tulach 2004-11-23 15:59:09 UTC
Althrough there is probably a small chance that the change is not
fully backward compatible, the case that exhibits it is pretty obscure
(register your UnitTestForSourceQueryImplementation into
Lookup.getDefault() and remove the default one that delegates to
active project won't work anymore as there will be new
MultipleRootsUnitTestForSourceQueryImplementation and it will delegate
to project before your own UTFSQI gets called). As this is not
important at all, I agree with the change.
Comment 2 Tomas Zezula 2004-11-23 16:02:05 UTC
Thanks.
Comment 3 Jesse Glick 2004-11-23 16:24:25 UTC
Note that the presence of the default (project-delegating)
UTFSQI/MRUTFSQI is mentioned in Javadoc only in a nonnormative
section, and the class name (needed for masking) is not mentioned at
all, so anyone trying to do such masking would be stepping outside the
bounds of the guaranteed API anyway. So I don't consider breaking that
scenario to be a problem; such a user would simply need to switch the
mask to the new project-delegating MRUTFSQI.