NetBeans IDE 6.7 RC1 (Build 200905282243)
I tried to install SOA plugins and IDE reported success but dod not show
installed plugins after restart. Installed plugins were still presented on
"Available" tab page and it was possible to install them again.
Then I tried to install UML plugin. After installation it did not appear
on installed page immediately, only after pressing "Reload catalog". In
same time SOA plugins appeared as installed. So it might be treated as kind
Then I uninstalled SOA plugins, restarted IDE and got set of exceptions
including FileNotFound exception and ClassNotFound exception.
After restart IDE still shows uninstalled plugins in list but as text
only without icons. Check screenshot.
Created attachment 82972 [details]
Strange, but if it's reproducible only on one platform .. I would say we can live with that for RC1 ... would be nice to
find root cause and fix for RC2
Hm... looks like I can reproduce it as well on both Solaris x86 and sparc, was not able to reproduce on Windows.
Workaround that helps (I don`t know why) is
$ rm ~/.netbeans/6.7rc1/var/cache/lastModified/soa2
SOA is installed into installation directory. Just after SOA installation and restart the timestamps are:
2009-05-29 22:02:18.444541000 +0400 (~/netbeans-6.7rc1/soa2/.lastModified)
2009-05-29 21:59:10.930217000 +0400 (~/.netbeans/6.7rc1/var/cache/lastModified/soa2 )
2009-05-29 22:02:19.816460000 +0400 (~/.netbeans/6.7rc1/.lastModified)
Autoupdate does know nothing about <userdir>/var/cache/lastModified.
Additional manual touching of .lastModified file (both in install and usedir) has very strange affect:
- closing IDE, touching those files and starting it again - SOA shown as not installed.
- closing IDE again, touching those files again and starting IDE again - SOA shown as installed.
Unlikely the AU issue - reassigning to platform for further evaluation.
Maybe some wrong magic in o.n.bootstrap/src/org/netbeans/Stamps.java (but also maybe AU should handle that somehow...)
These timestamp manipulations are Yarda's; I have little idea how it is supposed to work and what to do when it doesn't.
Still unable to reproduce on x86 for latest truck build.
SPARC affected as described.
Product Version: NetBeans IDE Dev (Build 200906010201)
Java: 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b15
System: SunOS version 5.11 running on x86; UTF-8; en_US (nb)
Ok, this issue is considered as a stopper for RC2/FCS
AutoUpdate shall not care about $userdir/var/cache/lastModified/cluster at all. Something is wrong in the platform.
There were few problems in the Stamps code and I addressed two of them in ergonomics#ef2526558afb. However I am not
sure if it helps this particular problem. It shall. Please verify in
I'll likely have no time to do "the paperwork" tomorrow. But it shall be simple. To merge to release67 just:
hg pull -r ef2526558afb http://hg.netbeans.org/ergonomics/
hg ci -m "Merge of #166254"
Yarda, thanks for your help. We'll verify that tomorrow and I'll ask Tonda for transplate into release67.
... and keep it open for NB 6.7
It would be a pull, not a transplant operation.
this issue hasn't been ported to release67 yet, as I know.
Does it work there ?
RC2 checked today is free of this issue so I assumed it fixed as planned.
Looks like setting of "Force install into shared directories" make
sense to reproduce this issue.
Integrated into 'main-golden', will be available in build *200906031401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <firstname.lastname@example.org>
Log: #166254: Don't create any lastModified info for non-existing clusters. Also reset the result for each cluster to isolate it from the influence on previous results.
Thanks a lot Jarda!
Issue was not fixed completely. Installation looks workable now but
after uninstallation IDE shows lot of exceptions like:
ZipException: error in opening zip file;
Again only SPARC platform affected.
I'd suggest to report another bug against installer. The uninstall problem is something unrelated to the P1 bug I
fixed and I doubt it classifies for P1 priority. Better to track it in separate issue.
Otherwise I am glad to hear that the cache problem is solved.
Original title of this issue was not changed -- it's about installation and uninstallation.
But if you prefer to keep them separated -- not a problem.
The fix does not work for me - I`ve tried RC2 build 2009-06-04_01-12-31 and SOA is still in "Available" list after its
What I did :
0) Clean ~/.netbeans
1) Use "full" bundle, install as user all IDE features, no servers.
2) Run IDE, opened Tools->Plugins, reload catalog, install SOA
3) Restart, again opened Tools->Plugins. SOA is still in "Available" plugins list.
No exception thrown in the log.
I think it might be RANDOM.
SOA and XML Schema
I just tested the behaviour on my SunRay and it worked without a problem.
I was able to reproduce as well using host provided by Dmitry. I used same
shared homedir (so same jdk and other staff) as with other host, but result
vary from host to host and stable on each host so I don't know is this really
RANDOM or just depends on yet unknown reasons.
I still have not managed to reproduce the problem. But I found another issue that might cause it. Please try again
Jarda, could you please attach new <nbdir>/platform10/lib/boot.jar file with this fix?
It will help to check the fix in less time...
Created attachment 83345 [details]
boot.jar which does not include non-existing clusters in all-checksum.txt
Dmitry, if you are able to reproduce the problem, can you please debug Stamps class and find out why the caches are
not invalidated when the list of clusters changes (this shall invalidate the content of all-checksum.txt file) or when
something new gets installed into existing cluster (this shall change timestamp of its .lastModified file)?
The issue is still reproducible with the attached boot.jar, I`m debugging Stamps at the moment...
Thanks in advance for help. The puzzle imho is why method private File file(String cache, int len) at line 160-190
There is some mess with timestamps.
File f = new File(System.getProperty("user.home"), ".lastModified");
long diff = System.currentTimeMillis() - f.createNewFile().lastModified();
On my Windows system diff is either 0 or small positive value.
On Linux system with $HOME located on the current disk drive the diff is small positive value.
On Solaris (Sparc,x86) and Linux system with HOME mounted via NFS the "diff" is negative value. Really weird...
At least UpdaterDispather.touchLastModified() should be fixed - I`m working on that.
And likely Stamps.discardCachesImpl() should be fixed as well...
UpdaterDispatcher fixed in
I haven`t touched Stamps.
In case installation is done on the local partition (e.g. in /tmp) this issue is not reproducible (I`ve tried pure RC2)
as well as 166569.
So the bug likely comes from the mistiming of the desktop system and the server which $HOME partition is stored at.
*** Issue 166569 has been marked as a duplicate of this issue. ***
I am not sure, but probably there is no need to fix Stamps. Stamps only read .lastModified file's time, never write it
down. Hopefully the problem disappears just after your a67c224dfb8d fix.
Unfortunately it does not disapper even with a67c224dfb8d.
To reproduce the issue, likely it is enough to set desktop time, say, one hour before the time set on the NFS server
(with respect to time zones) which the home partition is been stored at.
Hasn't been fixed in release67 yet.
After a discussion with jtulach - we agreed on that this is not a stopper for NB 6.7 .
Jindra will help me emulate the problem. However it seems that there needs to be some misconfiguration between the
desktop and server for the bug to happen. Do I also need to have installation on server and userdir locally? Or is it
possible to reproduce the problem while both userdir and installation are on the same (nfs) disk?
> Do I also need to have installation on server and userdir locally?
> Or is it possible to reproduce the problem while both userdir and installation are on the same (nfs) disk?
Hard to say... I have $HOME partition on NFS and installed NB on it. So both userdir and installation are on this
I managed to simulate the problem. My changes done in main#0db4fcae704a seem to fix it. What are their other
implications remains to be seen.
Integrated into 'main-golden', will be available in build *200906110201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Dmitry Lipin <email@example.com>
Log: Issue #166254 Plugin installation/deinstallation work badly on Solaris SPARC
verified with 200906110201.
Issue 166569 still reproducible, so we need to reopen this
issue or clear "duplicate" status from other one.
Looks like theory about same cause for both issues is not
As nobody answered, doing by myself.
Issue 166569 marked as duplicate of this issue and still reproducible. Reopen.
This issue gets pretty long and fuzzy. Some problems got fixed, some may remain, but I'd rather reopen the duplicate
issue 166569 or create some new ones then continue in this one. I hope this is acceptable to all sides.