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.
I have a J2EE project I am using to edit my JSP/HTML files. It points directly to my server's deployment directory. When I redeploy my application, NetBeans reparses all the jars in WEB-INF/lib because they are in the compilation classpath (Project Properties --> Build - Compiling Sources screen). If I remove them from the list and redeploy, they are not reparsed. However, if I restart NetBeans, they reappear in the list and subsequently get reparsed when I redeploy.
Which J2EE project type are you using?
I think it's a Web Project with Existing Sources.
Is there a workaround for this issue, or an estimate on when it can be fixed?
This looks like it is in the web teams domain
Can you take a look at the project.properties file, property javac.classpath before you remove the jar files from Compiling Sources screen and after? The jar files should be removed from this property right after you close the project properties dialog. Also, the same information is stored in project.xml inside tag <web-module-libraries> and should also be removed. Thanks.
Both files get updated correctly. The only remaining entries are javac.classpath=${libs.servlet24.classpath};${libs.jsp20.classpath} which are grayed out in the properties dialog, so they can't be removed.
Also, when I quit NetBeans, the files stay without the entries I removed. It's only when I restart NetBeans that the entries get re-added.
Is there any workaround for this? Every time I restart NetBeans or redeploy my web app it reparses the jars, and that takes 10-20 seconds each time.
Raising priority as it looks like this issue is still present in 4.1. Please advise on estimated fix or workaround.
Could you please provide step-by-step scenario how it can be reproduced starting with new created WebApp? Where is your directory placed and how do you modify project.properties?
I am not modifying project.properties directly. They are removed when I remove the entries from the project classpath in the project properties dialog. I have an existing web application already deployed inside my container. I create a new web application with existing sources (File - New Project - Web - Web Application with Existing Sources), and I set the project location outside the web application's directory. The project folder points to the directory in which the web application is deployed. Once I have created the project, I open its properties dialog and click on (in 4.1 now) the Libraries node. I see listed all the jar files inside WEB-INF/lib. I select all of them (about 40 total in my web app) and click Remove, then OK. This causes them to be removed from project.properties. However, if I restart NetBeans the "Scanning Project Classpaths" dialog comes up and this (I think) re-adds them to project.properties. Then, every time I redeploy my web app, they are re-scanned.
I finally see what you mean now. The IDE cannot know what changes you made to your project outside of IDE. For example if you are working with someone else and he he is not using netbeans, or you sometimes modify your project libraries outside of netbeans. The IDE wants to have the classpath setup as it will be on the server (because we thought that would make sense...). So it is scanning the WEB-INF\lib when you open the project and adds jar files in project.properties if they are not there. That triggers scanning. I do not see the reason why you would not want to have the jar files from the classpath in code completion, etc. when you have them in WEB-INF\lib. Why are the jar files are parsed when you deploy, though? It looks like the jar files are changed every time you build/deploy, otherwise they would not be parsed. You say "The project folder points to the directory in which the web application is deployed." What exactly is the structure of project folder and the build folder?
I think the jar files are reparsed even when they do not change. I'm not sure I understand your question about the folder structure. The project's folder is in C:\projects, while the web pages folder is in C:\<app-server-path>. The issue I raised is that if you explicitly remove the jars from the Libraries panel, they get re-added. I still think the parsing should not happen automatically, or there should be a preferences setting for whether to do it manually or automatically. If there are hundreds of jars, like in the project I'm working on, parsing just slows development to a crawl.
The fact that the IDE parses jar files that are on classpath when they change is not controlled by web module, this is an issue of java language infrastrucure, the people working on it are aware of it and it cannot be simply switched off. I understand that having to wait for parsing if you did not change anything is anoying and I am trying to find the cause of it. Removing the jar files form classpath is only a workaround. In fact removing the jar files from classpath and adding them again (the web project adds them, because they are in WEB-INF/lib and they are needed for compilation - I assume) will cause the jar files to be reparsed so this can make things worse. You say: >I think the jar files are reparsed even when they do not change. Are you sure? Did you check the timestamps? If the jar files do not change and they are reparsed. Also, can you copy he first 3 lines of your project.xml file in here to double check the type/version of project? Thanks.
You may be right about the timestamps. When redeploying a web app, my container first deletes the ear file and the extracted directory, and then extracts a new copy of the ear file. So the timestamps will probably be newer on all the files. This doesn't change the fact that none of the jars in WEB-INF/lib may actually have had their contents changed, and yet the IDE is reparsing all of them. project.xml starts like this: <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://www.netbeans.org/ns/project/1"> <type>org.netbeans.modules.web.project</type>
The IDE cannot know that they are the same. If it detects a timestamp change it has to check the whole thing for any changes. Maybe you can try to setup the project differently to solve the problem. You can create a copy of your web module outside of your application server. You can keep the libraries there (WEB-INF/lib) as well as sources. The IDE will build the project into a build directory. You can set the build directory location to your app server - go to nbproject/project.properties and change the build.dir property. When you build the project the app server should get the updated version of module, but the sources will never change. Let me know if this help.
Timestamp change means that IDE *has to* reparse JARs otherwise there's no chance how to check their differences (I haven't heard yet about binary comparison of JAR files after timestamp change to check if they are accidentally identical). From this point of view, I'm marking this issie as Won'tFix.
Sorry, but the discussion got sidetracked from the original bug. What was marked as wont fix was not reparsing jars when the web app is redeployed. However, the original bug stated that entries that were explicitly removed from a project's classpath get re-added when NetBeans is restarted. This is still a bug. NB should respect what I have chosen to explicitly remove (or add) to a project's classpath (the Compile-time Libraries list on the Libraries section of the properties dialog).
No, I marked it as wontfix because what you are trying to do is a workaround and what the IDE does now is intended behavior. The IDE should use the same classpath that the module has and the project support is helping the user to make it that way.
Workaround? The properties dialog clearly and easily permits you to remove jars from the compilation classpath; it is not a workaround. If it is a workaround, then why is there the option to remove those jars from the classpath at all? I do not use a web project to compile classes; I use it only to edit jsp and xml files so that I can edit them directly in place. I do _not_ want to go through an extra build step every time I make a change to copy a file or files from a different project's output directory to my web app's deployment directory. When I am doing development, I may modify a file or files multiple times per minute, and the overhead of building to copy them is too high. Sure, I can probably work around this by mounting my jsp dir in another project, but I will probably lose features like parsing of tag libraries for code-completion. I just don't see how the direction you are taking NB is making development easier.
I think that you have a very rare situation. There is nothing wrong with tweaking jsps and html in server deployment area but I think this would still work just fine if the jar files on classpath would not change timestamps all the time. Refreshing of classpath is fairly fast if you do not change the jar files. Besides, you are saying that you want code completion and scanning of tag libraries. I think that this means that you have to have these classpath entries in project classpath. Anyway, I think that automatically adding entries that are in WEB-INF\lib into classpath may be a useful feature and I do not want to just turn in off. I can add a dialog that will ask for confirmation to do this and will show a checkbox "Do not ask again". Let me know if this would work.
I think tag library code-completion comes from parsing .tld files in WEB-INF as well as xmlns attributes in the jsp:root tag, as far as I can tell. I don't think it uses the jar files, but I could be wrong. Sure, if there were an option to turn off the parsing that would be on by default, that would work fine.
I will the dialog with confirmation.
Thanks.
VBEFFA: I found an extremely simple workaround - I do not know how I could have overlooked it before. Simply removing the property lib.dir from nbproject/project.properties solves the problem -- if you remove this property the IDE will never automatically add the jar files to classpath again. This should work even in netbeans 4.1. Downgrading to P3, still target for 5.0 if time permits.
TM 5.0->TBD
this has been already evaluated, it's just a matter of finding the time to do it
I would say this was solved by issue #63598.