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 52039 - Entries removed from compilation classpath get re-added when NetBeans is restarted
Summary: Entries removed from compilation classpath get re-added when NetBeans is rest...
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: Radko Najman
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-03 00:36 UTC by vbeffa
Modified: 2007-01-09 14:56 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vbeffa 2004-12-03 00:36:20 UTC
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.
Comment 1 Vince Kraemer 2004-12-05 19:00:46 UTC
Which J2EE project type are you using?
Comment 2 vbeffa 2004-12-06 19:14:48 UTC
I think it's a Web Project with Existing Sources.
Comment 3 vbeffa 2004-12-17 22:47:28 UTC
Is there a workaround for this issue, or an estimate on when it can be
fixed?
Comment 4 Vince Kraemer 2004-12-17 23:46:09 UTC
This looks like it is in the web teams domain
Comment 5 Pavel Buzek 2005-01-29 13:58:20 UTC
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.
Comment 6 vbeffa 2005-01-31 20:35:34 UTC
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.
Comment 7 vbeffa 2005-01-31 20:37:06 UTC
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.
Comment 8 vbeffa 2005-03-23 00:15:31 UTC
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.
Comment 9 vbeffa 2005-06-01 23:40:05 UTC
Raising priority as it looks like this issue is still present in 4.1. Please
advise on estimated fix or workaround.
Comment 10 zikmund 2005-06-02 12:09:00 UTC
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?
Comment 11 vbeffa 2005-06-06 19:59:35 UTC
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.
Comment 12 Pavel Buzek 2005-07-15 14:58:26 UTC
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? 

Comment 13 vbeffa 2005-07-19 20:04:49 UTC
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.
Comment 14 Pavel Buzek 2005-07-20 16:47:11 UTC
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.
Comment 15 vbeffa 2005-07-20 23:55:05 UTC
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>
Comment 16 Pavel Buzek 2005-07-21 01:28:02 UTC
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.
Comment 17 zikmund 2005-07-21 08:27:56 UTC
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.
Comment 18 vbeffa 2005-08-10 00:29:05 UTC
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).
Comment 19 Pavel Buzek 2005-08-10 01:32:14 UTC
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.
Comment 20 vbeffa 2005-08-16 20:01:19 UTC
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.
Comment 21 Pavel Buzek 2005-08-16 20:36:51 UTC
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.
Comment 22 vbeffa 2005-08-16 22:26:41 UTC
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.
Comment 23 Pavel Buzek 2005-08-17 04:05:04 UTC
I will the dialog with confirmation.
Comment 24 vbeffa 2005-08-17 04:53:55 UTC
Thanks.
Comment 25 Pavel Buzek 2005-09-07 18:38:44 UTC
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.
Comment 26 Jaroslav Pospisil 2006-03-13 13:43:01 UTC
TM 5.0->TBD
Comment 27 Pavel Buzek 2006-07-21 22:04:20 UTC
this has been already evaluated, it's just a matter of finding the time to do it
Comment 28 Radko Najman 2007-01-09 14:56:03 UTC
I would say this was solved by issue #63598.