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 19810 - error reading jar recipe when changing projects
Summary: error reading jar recipe when changing projects
Status: CLOSED DUPLICATE of bug 21326
Alias: None
Product: obsolete
Classification: Unclassified
Component: jarpackager (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: issues@obsolete
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-01-27 06:43 UTC by zohar
Modified: 2003-07-01 10:02 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
popup screenshot (60.98 KB, image/jpeg)
2002-01-27 06:44 UTC, zohar
Details
ide.log (29.48 KB, text/plain)
2002-01-27 06:45 UTC, zohar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description zohar 2002-01-27 06:43:33 UTC
I use build 200201250100.
I have a project that contains a jar. Each time I switch projects I get a popup 
message saying that there is a problem with the jar recipe. The jar compiles 
OK, with no warnings. See the screenshot and the ide.log
Comment 1 zohar 2002-01-27 06:44:53 UTC
Created attachment 4440 [details]
popup screenshot
Comment 2 zohar 2002-01-27 06:45:30 UTC
Created attachment 4441 [details]
ide.log
Comment 3 brinkley 2002-01-29 17:21:50 UTC
This appears to be a bug in Project swtiching and is a timing issue. I
mounted a new file system and copied the colorpicker directory and
contents from the samples. Then create a jarpackager recipie using the
colorpicker directory. 

Create a new "dummy" project. When you press ok generally the error
the user specified will appear. Switching back and forth between the
project will cause the error to occur sometimes (inidcating its a
timing issue) if and only if the jarpackager recipie file is visable
in the Explorer. 

I'm just guessing but I beleive the file explorer isn't properly
cleared before the new project is loaded in the explorer. Consequently
the explorer is trying to mount the jarpackager recipie file even
during this state of transition.

The error appears to be harmless as once acknowledged everything works
as it should.
Comment 4 zohar 2002-02-04 12:41:49 UTC
reproduced in build 200202040100
Comment 5 zohar 2002-02-06 05:24:48 UTC
maybe it's harmless, but it's still annoying. I reproduced it with 
build 200202060100.
Comment 6 brinkley 2002-02-06 05:36:06 UTC
Yes, I agree it's annoying, but the point is there isn't a loss of
data. It's not a harmful bug just not desirable. 
Comment 7 zohar 2002-02-06 05:42:14 UTC
so... 
no data loss - no fix? I agree it's not a P1/P2, but...
Did the trunk enter a "High Resistance mode"?
Comment 8 brinkley 2002-02-06 05:48:58 UTC
The bug is still open. It's been transferred to another module owner
as this not a jarpackager problem but either a projects or filesystems
problem. My statements on the bug are intended as additional
information for the new owner of the bug.
Comment 9 zohar 2002-02-18 15:42:27 UTC
Anyone taking a look at this?
Comment 10 Vitezslav Stejskal 2002-02-18 17:03:46 UTC
... pending on the list, stay tuned!
Comment 11 Vitezslav Stejskal 2002-03-01 09:47:03 UTC
It seems that something strange happens in Jar packager when 
filesystem is unmounted. I tried following scenarion:

1. mount two filesystems (fs1, fs2)
2. create Jar Recipe (JR) somewhere on fs1
3. add something from fs2 as a contents of JR
4. try to compile -> should work (contents is OK)
5. unmount fs2 -> error reading JR occures

This has nothing with projects, but seems to be a problem of Jar 
Packager.
Comment 12 zohar 2002-03-19 04:43:04 UTC
any progress?
Comment 13 zohar 2002-03-24 07:55:42 UTC
anybody home...?
Comment 14 Milos Kleint 2002-04-03 09:18:48 UTC
is duplicate of issue #21326, Roger has the fix ready, will commit soon.

*** This issue has been marked as a duplicate of 21326 ***
Comment 15 David Kaspar 2002-04-05 15:02:31 UTC
Verified
Comment 16 Quality Engineering 2003-07-01 10:01:33 UTC
Resolved for 3.4 or earlier, no new info since then -> closing.
Comment 17 Quality Engineering 2003-07-01 10:02:31 UTC
Resolved for 3.4 or earlier, no new info since then -> closing.