Bug 73197 - ProjectClassPathExtender should allow adding 2 kinds of libraries, Design and Compile
ProjectClassPathExtender should allow adding 2 kinds of libraries, Design and...
Product: java
Classification: Unclassified
Component: Project
All All
: P2 (vote)
: 6.x
Assigned To: Tomas Zezula
Depends on: 75471
Blocks: 93470
  Show dependency treegraph
Reported: 2006-03-02 23:13 UTC by _ potingwu
Modified: 2007-01-30 17:49 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description _ potingwu 2006-03-02 23:13:09 UTC
For the project module development, the developers need 3 kinds of classpath
1. ClassPath.DESIGN: Used for the IDE itself. To avoid showing the contents in
the code-completion and does not allow users' codes to use it.
2. ClassPath.COMPILE: Used for the editor's code-completion, compiler's
classpath, ...
3. ClassPath.EXECUTE: Used for applications' runtime libraries. I.e.,
'Packaging' for the Web project that this kind of libraries will go into the WAR

Currently in interface
org.netbeans.spi.java.project.classpath.ProjectClassPathExtender, there is only
a simple method addLibrary(Library library) that prevents developers using
addLibraries(String classPathId, Library[] libraries, String
webModuleElementName) in
org.netbeans.modules.web.project.classpath.WebProjectClassPathExtender even this
method is public.

Same mechanism may also be needed for addArchiveFile and addAntArtifact methods.
Comment 1 Tomas Zezula 2006-03-03 08:11:14 UTC
The ClassPathExtender is not a general contract, some project types may not
provide it at all. General API for manipulation of project's classpath may be
very dangerous, it may cause other modules to make project unrunnable. This is
why the ClassPathExtender allows only addition (no remove) to ClassPath.COMPILE.
If you need a special contract among your project type and your module you can
define your own API, probably friend API to avoid other modules to manipulate
the class path. The only thing I can help you with is to create such a interface
in the java/api module if you decide that you want to have it in public API
rather than in friend API. But j2seroject and probably other project types will
not provide an implementation of this contract.
Comment 2 _ potingwu 2006-03-03 17:13:10 UTC
I don't fully understand the ClassPathExtender usage policy. Do you mean the web
module can make its WebProjectClassPathExtender as an API for its framework
development but not directly extended from ClassPathExtender?

Petr, is that possible to make this a more extendable API just between the web
module and the framework development so that we don't need to touch the whole IDE?
Comment 3 Petr Pisl 2006-03-06 09:41:01 UTC
I think, we can extend contract between Web Module and Framework. It should be
doable if we don't need changes in UI which comes from project infrastructure.
Comment 4 Mark Dey 2006-05-06 01:20:38 UTC
There are two issues being discussed here. One is the addition of a new
Classpath qualifier: ClassPath.DESIGN to differentiate between design time
versus compile time. The second issue has to do with extending ClassPathExtender
which appears now to be a web/project issue, handled by 73198. Po-Ting, if
that's the case, please retitle the Summary description and let's focus the
discussion on ClassPath.DESIGN.
Comment 5 _ potingwu 2006-05-09 21:59:35 UTC
Copy sandipchitale's comment from 73198:
Actually the motivation behind the ClassPath.DESIGN is as follows:

Some times there are additional jars associated with the jars that are added 
to the project's classpath. These additonal jars are meant to be consumed by 
the IDE itself and should not pollute the classes visible to the user's 
project. For example, the user may add a jar containing JavaBeans to a J2SE 
project. There may be an additional jar containing the BeanInfos of the 
JavaBeans. That BeanInfo jar is meant to be consumed by the GUI editor such as 
Matisse. However the classes from the BeansInfo jar should not appear in the 
code completion popup in user project's java files nor should the BeanInfo 
file be packaged with the user's application. Similar scenario applies to the 
Creator JSF component jar files which may have associated designtime jar file 
meant to be consumed by the Creator framework (Designer/Insync).

So the idea is that by having a standard ClassPath.DESIGN mechanism could 
allow the IDE to discover disgntime only jars associated with the projects. 
IMHO this is applicable not only to the Web projects but also to J2SE library 
projects (JavaBeans jar + associated BeanInfo jar case).
Comment 6 Tomas Zezula 2006-05-10 09:04:15 UTC
See http://www.netbeans.org/issues/show_bug.cgi?id=75471 which may solve your
problem. The project implementing the ClassPathModifierImplementation will allow
other modules to add or remove classpath entry from the project classpaths. It's
up to the project to decide which classpath it allows to modify, in other words
the project may return an Extendable for DESIGN classpath which is specific for it.

Possible Usage:

Extendable[] extendables = ProjectClassPathModifier.findExtendables (yourProject);
Extendable toExtend = null;
for (Extendable e : extendables) {
  if (e.getClassPathType().equals (YourProjectConstants.DESIGN)) {
     toExtend = e;
if (toExtend != null) {
    ProjectClassPathModifier.addLibraries (libs, toExtend);
Comment 7 Jesse Glick 2006-05-14 16:58:47 UTC
BTW there is a similar new issue somewhere (j2seproject?) about ability to
specify a design CP in a library.
Comment 8 Tomas Zezula 2006-05-22 16:10:28 UTC
Checking in j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java;
 <--  J2SEProject.java
new revision: 1.61; previous revision: 1.60
Checking in
 <--  ClassPathProviderImpl.java
new revision: 1.18; previous revision: 1.17
Checking in
 <--  J2SEProjectClassPathExtender.java
new revision: 1.13; previous revision: 1.12
RCS file:
Checking in
 <--  J2SEProjectClassPathModifier.java
initial revision: 1.1
RCS file:
Checking in
 <--  J2SEProjectClassPathModifierTest.java
initial revision: 1.1
Checking in project/apichanges.xml;
/cvs/java/project/apichanges.xml,v  <--  apichanges.xml
new revision: 1.14; previous revision: 1.13
Checking in project/manifest.mf;
/cvs/java/project/manifest.mf,v  <--  manifest.mf
new revision: 1.19; previous revision: 1.18
Checking in project/nbproject/project.properties;
/cvs/java/project/nbproject/project.properties,v  <--  project.properties
new revision: 1.21; previous revision: 1.20
RCS file:
Checking in
 <--  ProjectClassPathModifier.java
initial revision: 1.1
RCS file:
Checking in
 <--  ProjectClassPathModifierAccessor.java
initial revision: 1.1
Checking in
 <--  ProjectClassPathExtender.java
new revision: 1.4; previous revision: 1.3
RCS file:
Checking in
 <--  ProjectClassPathModifierImplementation.java
initial revision: 1.1

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo