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 73198 - WebProjectClassPathExtender should handle different kinds of libraries, Compile and Execute
Summary: WebProjectClassPathExtender should handle different kinds of libraries, Compi...
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Radko Najman
: 98882 (view as bug list)
Depends on: 75471
Blocks: 72091 89772 93470
  Show dependency tree
Reported: 2006-03-02 23:42 UTC by _ potingwu
Modified: 2007-05-21 15:52 UTC (History)
9 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description _ potingwu 2006-03-02 23:42:46 UTC
For the Web project framework development, the developers need 3 kinds of
classpath qualifiers (see also
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

In addLibraries(String classPathId, Library[] libraries, String
webModuleElementName) of
org.netbeans.modules.web.project.classpath.WebProjectClassPathExtender, it
should have the ability to 'OR' this qualifiers.

- ClassPath.COMPILE only: show it under Libraries->Compile without Package selected
- ClassPath.COMPILE | ClassPath.EXECUTE: show it under Libraries->Compile with
Package selected
- ClassPath.EXECUTE only: show it under Packaging
- ClassPath.DESIGN: should introduce another category in the project properties
customizer with appropriate warnings that changing or removing these libraries
might cause anomalous behavior in the IDE.

* May need extra mechanism for ClassPath.EXECUTE to select 'Path in WAR'
otherwise go into the default WEB-INF/lib or WEB-INF/classes
* Should we define a better UI between Libraries->Compile->Package and Packaging
(not very needed though, just somehow confused by the difference in 2 various
Comment 1 _ potingwu 2006-03-03 17:24:41 UTC
There is one more request I forgot to add in the issue.

There is the case that some ClassPath.COMPILE libraries that should not be added
into the WAR file (Package). We should also define a tag like
ClassPath.COMPILE_ONLY that will be shown in Libraries->Compile but make the
Package unselected and disabled so that user cannot reselect it by the GUI.

Or we can introduce a new flag 'READONLY'. If the library has READONLY=true,
then user cannot change/remove it. This will make the above statement true and
also prevent user remove the ClassPath.DESIGN libraries.
Comment 2 _ potingwu 2006-03-03 17:29:38 UTC
Petr Pisl wrote:
> Now I start to understand. So user can add it's own library with runtime jars
and with designtime jars to the project. I'm right?

Yes, framework developer can add them by web module API, and user can add them
by project properties window GUI.
Comment 3 _ sandipchitale 2006-05-08 19:09:52 UTC
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 4 _ potingwu 2006-05-09 22:03:13 UTC
Copy ppisl's comment from 73197:

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 5 Tomas Zezula 2006-05-11 10:32:10 UTC
COvered by:
Comment 6 Tomas Zezula 2006-05-22 16:10:39 UTC
Checking in j2seproject/src/org/netbeans/modules/java/j2seproject/;
new revision: 1.61; previous revision: 1.60
Checking in
new revision: 1.18; previous revision: 1.17
Checking in
new revision: 1.13; previous revision: 1.12
RCS file:
Checking in
initial revision: 1.1
RCS file:
Checking in
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/;
/cvs/java/project/,v  <--
new revision: 1.19; previous revision: 1.18
Checking in project/nbproject/;
/cvs/java/project/nbproject/,v  <--
new revision: 1.21; previous revision: 1.20
RCS file:
Checking in
initial revision: 1.1
RCS file:
Checking in
initial revision: 1.1
Checking in
new revision: 1.4; previous revision: 1.3
RCS file:
Checking in
initial revision: 1.1
Comment 7 _ potingwu 2006-05-23 19:25:46 UTC
Hi, Petr and Radko,

Could you please verify that this change will be suitable for web project to
make the following method available for framework development:
    public boolean addLibraries(final String classPathId, final Library[]
libraries, final String webModuleElementName) throws IOException;

Comment 8 Petr Pisl 2006-05-24 13:29:52 UTC
Hi Po-Ting,
I think this will work in your case as well. Of course firstly there has to be a
implementation of this in the web project and some changes have to be done as
well in the addLibraries method in WebProjectClassPathExtender. I expect that
the implementation will be very similar to J2SEProjectClassPathModifier and

The API is in the trunk now and I don't know, whether will be in 5.5 branch as
well. Our team doesn't work on trunk, but just only on 5.5 branch and we will be
able to make the implementation if the api will be in 5.5 (unfortunately the 5.5
branch is feature frozen) or after finishing 5.5 and moving all things from 5.5
branch to the trunk.

Comment 9 _ potingwu 2007-02-20 20:11:18 UTC
In the NetBeans 6.0 Javadoc, is now
deprecated. It suggests to use ProjectClassPathModifier instead (75471). We
should change the web project to use the new APIs.

I think the framework developing really needs the ClassPathType (either COMPILE
or EXECUTE) when adding libraries. Otherwise, the war files will include all the
compile-time libraries and becomes huge and even have some run-time issues. Or,
the Java editor will show the run-time libraries methods that should not be
available for the users' codes.
Comment 10 Petr Pisl 2007-02-21 08:56:32 UTC
You are right. We need to implement ProjectClassPathModifier SPI. This
implementation should support the DESIGN classpath as well, which covers your
Comment 11 Radko Najman 2007-03-14 13:52:28 UTC
WebProjectClassPathModifier implemented in web project.

Checking in classpath/;
new revision: 1.17; previous revision: 1.16
Checking in classpath/;
new revision: 1.29; previous revision: 1.28
RCS file:
Checking in classpath/;
initial revision: 1.1
Checking in classpath/;
new revision: 1.16; previous revision: 1.15
Checking in;
/cvs/web/project/src/org/netbeans/modules/web/project/,v  <--
new revision: 1.106; previous revision: 1.105
Checking in;
new revision: 1.11; previous revision: 1.10
Comment 12 _ potingwu 2007-03-22 22:20:04 UTC
I'm trying to migrate the classpath in visualweb. I'm confused here about the
usage of api and spi!

As I known, I should use project.getLookup().lookup() to get the implementation.
Since I look into the web/project codes, I should lookup
ProjectClassPathModifierImplementation, right?
    ProjectClassPathModifierImplementation mod = 

but all methods in ProjectClassPathModifierImplementation are protected, how
should I access them?

If I change the lookup to ProjectClassPathModifier, then the lookup can't find
the class. Could you please give me some hint? (the old ProjectClassPathExtender
does not have 2 kinds of interface)

And what parameters should I use in the api,
    ProjectClassPathModifier.addLibraries(Library[] libraries,
                              FileObject projectArtifact, String classPathType)

    'projectArtifact' is not needed for the old ProjectClassPathExtender,
        what should I use?
    What 'classPathType' are for ClassPath.COMPILE and ClassPath.EXECUTE?
Comment 13 Petr Pisl 2007-03-26 09:29:35 UTC
*** Issue 98882 has been marked as a duplicate of this issue. ***
Comment 14 _ potingwu 2007-03-27 20:03:01 UTC
I'm adding some discussion between Radko and me about this new API:
- you can simply call
  and the right implementation will be called.
  (P.S., because this method is static)

- 'projectArtifact' you can use e.g. your source root
      ClassPath.COMPILE or ClassPath.EXECUTE

- it works for ClassPath.COMPILE type. But I got the following error in the New
  Project Wizard for ClassPath.EXECUTE:
      Modification of [$MyProjDir/src/java, classpath/execute] is not supported 

  This is fixed by Radko by, add a library to ClassPath.EXECUTE, it will be
  added to "debug.classpath" property. This is not the original request! Looks
  like we have different point of view of the EXECUTE!

Here is a usecase of visualweb:
I will use the visualweb libraries for the usecase. In visualweb, there are 2
kinds of libraries, one for the IDE to compile the Java source, and the other
for the WAR file to pack.

    1st set of libraries: (e.g., libs.jsf-support.classpath) these libraries
       will be used for both Compile and WAR file.
       I think in the project customizer, it is shown in category 'Libraries',
       with 'Package' checked.

    2nd set of libraries: (e.g., libs.jdbcsupport-designtime.classpath) these
       libraries will only be used for Compile but not in the WAR file.
       I think in the project customizer, it is shown in category 'Libraries',
       with 'Package' un-checked.

    3rd set of libraries:(e.g., libs.jdbcsupport-runtime.classpath) these
       libraries will only be used for WAR file but not for Compile.
       I think in the project customizer, it is shown in category 
       'Build->Packaging', Path in WAR

The related variables that are used in the are:
    for Compile: javac.classpath=${libs.jdbcsupport-designtime.classpath}
    for WAR: war.content.additional=${libs.jdbcsupport-runtime.classpath}

Visualweb needs API to add a COMPILE classpath with or without the 'Package'
been checked.

- If I add libraries only by type=ClassPath.COMPILE,
     All libraries in Compile Libraries with the 'Package' checked

- If I add { LibA, LibB } by type=ClassPath.COMPILE and also add { LibA } by
  type=ClassPath.EXECUTE, then I see in the project customizer:
     LibA in Compile Libraries with the 'Package' checked
     LibB in Compile Libraries without the 'Package' checked
Comment 15 Radko Najman 2007-03-28 15:48:51 UTC
> Looks like we have different point of view of the EXECUTE!

My point of view is based on the current web project implementation. In j2se
project ClassPath.EXECUTE refers to the "run.classpath" property but in web
project this property is not used and ClassPath.EXECUTE equals to debug
classpath in web project.

From the usecase the request is clear now. ProjectClassPathModifier cannot help
in this case. It modifies project classpath but it cannot help you in case that
you want to add libraries, which should be in WAR but not on classpath. To allow
this we have to introduce a new API class probably. I'll try to implement it ASAP.
Comment 16 Radko Najman 2007-04-05 15:22:05 UTC
WebProjectClassPathModifier was implemented. It cannot address the 2nd and 3rd
requirement from the last example so I filed a new issue #100114 for it.
Comment 17 Jesse Glick 2007-05-19 00:05:28 UTC
Why does WebProjectClassPathExtender still exist? Now that
WebProjectClassPathModifier has been created and is in the project lookup, WPCPE
can simply be deleted, I think.
Comment 18 Petr Pisl 2007-05-21 09:27:38 UTC
You are right, there is no reason to keep WPCPE in the code. Or Radko, do you
know any?
Comment 19 Radko Najman 2007-05-21 15:52:59 UTC
WebProjectClassPathExtender class was annotated as deprecated. The reason why it
is still in the repository is that it is still used e.g. in web frameworks. It
can be fixed in frameworks hosted on but if it is used in
frameworks hosted on, we would broke them.

I don't have currently access to the up-to-date repository but I guess that
ClassPathExtender still exists also in J2SE project and it is also annotated as