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.
Summary: | WebProjectClassPathExtender should handle different kinds of libraries, Compile and Execute | ||
---|---|---|---|
Product: | javaee | Reporter: | _ potingwu <potingwu> |
Component: | Web Project | Assignee: | Radko Najman <rnajman> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | jchalupa, jglick, marcow, markdey, pjiricka, ppisl, rnajman, sandipchitale, satyaranjan |
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 75471 | ||
Bug Blocks: | 72091, 89772, 93470 |
Description
_ potingwu
2006-03-02 23:42:46 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. 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. 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. |