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.
I would like to ask for an API review for issue #49026. http://wiki.netbeans.org/wiki/view/Excludes49026 has all the relevant information. http://wiki.netbeans.org/wiki/view/Excludes49026#section-Excludes49026-APIChangesSoFar lists the proposed API changes.
No comments? I would like to merge this.
looks generally ok. mk1: exclude of project's binary dependencies is probably also for consideration for maven based projects, be it netbeans dependencies, OSGI or anything else that restricts access to packages. mk2: are excludes meant for sources only or for test sources as well? would they be different then? the current costumizer dialog seems to cater to that scenario mk3: will there be any error reporting on wrongly setup pattern (illegal character used etc.) probably not necessary, user wil be notified by the missing includes that something is wrong.
"... seems to cater ..." -> "... seems not to cater ..."
[MK1] Excludes in binary classpath entries is permitted by the API but ignored by Retouche, and also not an option in any of the existing project types. If you would like to use it for Maven projects (and I might like to use it for NBM projects), that would be a separate development effort, mostly in Retouche code. [MK2] For the sake of simplicity, excludes in a j2seproject apply to all source roots including test sources. In a freeform project, the GUI makes the same assumption but project.xml could specify more specific excludes. The API permits any policy. [MK3] No plans for such an error message, since you get instant feedback on matches anyway. Please note that the current design of IncludeExcludeVisualizer is provisional - as mentioned in the wiki, a possible alternate view (or perhaps replacement) would show either a tree with checkboxes, or a pair of list panes with Add>> and <<Remove buttons, or some similar GUI which is less powerful (no patterns) but simpler to use when only a limited number of included or excluded elements are needed.
By the way, one recent minor refinement to the API requested by Tomas: a FilteringPathResourceImplementation firing PROP_INCLUDES may choose to set a propagationId on the PropertyChangeEvent. Consecutive events with matching IDs are coalesced by ClassPath when refiring its PROP_INCLUDES. This is important for performance when a project contains n > 1 source roots in one compilation unit and includes/excludes are changed; otherwise Retouche would need to rescan n^2 roots (n roots for each of n events received).
Done. See issue #49026 for commit information.