In various cases a tool working with project sources wishes to add a dependency on a well-known API without needing to specify a particular JAR or Library defining this API. Currently ProjectClassPathModifier does not make this possible - you need to point to a concrete location, which ties the caller too deeply to a particular build/repository system, and leads to hacks such as Maven's CPExtender.checkLibraryForPoms.

Better would be a more abstract variant such as

public static boolean add/removeAPI(String apiClass, FileObject
projectArtifact, String classPathType) throws IOException,
UnsupportedOperationException;

which would leave it up to the PCPMI to decide where such a dependency should come from. (apiClass should I guess be a "binary name", and I guess UOE should be thrown in case this class cannot be found anywhere.) Example impls:

1. java.j2seproject - search global & project libraries for such a class.

2. maven - search repo indices for an artifact defining a class of that name; pick a version matching dependencyManagement, else the newest version. (Currently NBM projects need to use ${netbeans.version}, but if [1] is implemented then dependencyManagement would work transparently here too.)

3. apisupport.ant - search for a ModuleEntry whose getPublicClassNames mentions apiClass.

API clients could include:

1. Form editor (see blocked issues).

2. JUnit/TestNG support, which currently use addLibraries for Ant projects and proprietary calls for Maven projects. (junit.framework.Test, org.junit.Test, org.testng.annotations.Test)

...and probably a lot more (review current PCPM usages).


[1] http://wiki.netbeans.org/MavenNBM4#Fix_repository_generation_and_usage