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.

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.

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).

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.

COvered by: http://www.netbeans.org/issues/show_bug.cgi?id=75471

Checking in j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java,v
 <--  J2SEProject.java
new revision: 1.61; previous revision: 1.60
done
Checking in
j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/ClassPathProviderImpl.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/ClassPathProviderImpl.java,v
 <--  ClassPathProviderImpl.java
new revision: 1.18; previous revision: 1.17
done
Checking in
j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathExtender.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathExtender.java,v
 <--  J2SEProjectClassPathExtender.java
new revision: 1.13; previous revision: 1.12
done
RCS file:
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifier.java,v
done
Checking in
j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifier.java;
/cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifier.java,v
 <--  J2SEProjectClassPathModifier.java
initial revision: 1.1
done
RCS file:
/cvs/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifierTest.java,v
done
Checking in
j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifierTest.java;
/cvs/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/classpath/J2SEProjectClassPathModifierTest.java,v
 <--  J2SEProjectClassPathModifierTest.java
initial revision: 1.1
done
Checking in project/apichanges.xml;
/cvs/java/project/apichanges.xml,v  <--  apichanges.xml
new revision: 1.14; previous revision: 1.13
done
Checking in project/manifest.mf;
/cvs/java/project/manifest.mf,v  <--  manifest.mf
new revision: 1.19; previous revision: 1.18
done
Checking in project/nbproject/project.properties;
/cvs/java/project/nbproject/project.properties,v  <--  project.properties
new revision: 1.21; previous revision: 1.20
done
RCS file:
/cvs/java/project/src/org/netbeans/api/java/project/classpath/ProjectClassPathModifier.java,v
done
Checking in
project/src/org/netbeans/api/java/project/classpath/ProjectClassPathModifier.java;
/cvs/java/project/src/org/netbeans/api/java/project/classpath/ProjectClassPathModifier.java,v
 <--  ProjectClassPathModifier.java
initial revision: 1.1
done
RCS file:
/cvs/java/project/src/org/netbeans/modules/java/project/classpath/ProjectClassPathModifierAccessor.java,v
done
Checking in
project/src/org/netbeans/modules/java/project/classpath/ProjectClassPathModifierAccessor.java;
/cvs/java/project/src/org/netbeans/modules/java/project/classpath/ProjectClassPathModifierAccessor.java,v
 <--  ProjectClassPathModifierAccessor.java
initial revision: 1.1
done
Checking in
project/src/org/netbeans/spi/java/project/classpath/ProjectClassPathExtender.java;
/cvs/java/project/src/org/netbeans/spi/java/project/classpath/ProjectClassPathExtender.java,v
 <--  ProjectClassPathExtender.java
new revision: 1.4; previous revision: 1.3
done
RCS file:
/cvs/java/project/src/org/netbeans/spi/java/project/classpath/ProjectClassPathModifierImplementation.java,v
done
Checking in
project/src/org/netbeans/spi/java/project/classpath/ProjectClassPathModifierImplementation.java;
/cvs/java/project/src/org/netbeans/spi/java/project/classpath/ProjectClassPathModifierImplementation.java,v
 <--  ProjectClassPathModifierImplementation.java
initial revision: 1.1
done

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;
in
    org.netbeans.modules.web.project.classpath.WebProjectClassPathExtender.

Thanks,
Po-Ting

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
J2SEProjectClassPathModifier.

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.

Petr

In the NetBeans 6.0 Javadoc,
org.netbeans.spi.java.project.classpath.ProjectClassPathExtender 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.

You are right. We need to implement ProjectClassPathModifier SPI. This
implementation should support the DESIGN classpath as well, which covers your
requests.

WebProjectClassPathModifier implemented in web project.

Checking in classpath/WebProjectClassPathExtender.java;
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/WebProjectClassPathExtender.java,v
 <--  WebProjectClassPathExtender.java
new revision: 1.17; previous revision: 1.16
done
Checking in classpath/ClassPathProviderImpl.java;
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/ClassPathProviderImpl.java,v
 <--  ClassPathProviderImpl.java
new revision: 1.29; previous revision: 1.28
done
RCS file:
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/WebProjectClassPathModifier.java,v
done
Checking in classpath/WebProjectClassPathModifier.java;
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/WebProjectClassPathModifier.java,v
 <--  WebProjectClassPathModifier.java
initial revision: 1.1
done
Checking in classpath/ClassPathSupport.java;
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/ClassPathSupport.java,v
 <--  ClassPathSupport.java
new revision: 1.16; previous revision: 1.15
done
Checking in WebProject.java;
/cvs/web/project/src/org/netbeans/modules/web/project/WebProject.java,v  <-- 
WebProject.java
new revision: 1.106; previous revision: 1.105
done
Checking in WebProjectOperations.java;
/cvs/web/project/src/org/netbeans/modules/web/project/WebProjectOperations.java,v
 <--  WebProjectOperations.java
new revision: 1.11; previous revision: 1.10
done

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 = 
       (ProjectClassPathModifierImplementation)
       project.getLookup().lookup(ProjectClassPathModifierImplementation.class);

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?

*** Issue 98882 has been marked as a duplicate of this issue. ***

I'm adding some discussion between Radko and me about this new API:
- you can simply call
      ProjectClassPathModifier.addLibraries(...);
  and the right implementation will be called.
  (P.S., because this method is static)

- 'projectArtifact' you can use e.g. your source root
      WebModule.getJavaSources(project)[0];)
  'classPathType'
      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.

E.g.,
    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 project.properties 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.

Currently,
- 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

> 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.

WebProjectClassPathModifier was implemented. It cannot address the 2nd and 3rd
requirement from the last example so I filed a new issue #100114 for it.

Why does WebProjectClassPathExtender still exist? Now that
WebProjectClassPathModifier has been created and is in the project lookup, WPCPE
can simply be deleted, I think.

You are right, there is no reason to keep WPCPE in the code. Or Radko, do you
know any?

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 netbeans.org but if it is used in
frameworks hosted on dev.java.net, 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
deprecated.