Product Version = NetBeans IDE 6.9 (Build 201006101454)
Operating System = Windows XP version 5.1 running on x86
Java; VM; Vendor = 1.6.0_18
Runtime = Java HotSpot(TM) Client VM 16.0-b13
We have (probably) the same problem .
We are developing an NetBeans Plattform Application with 14 suits and more than 50 modules.
Internally we are producing releases for each commit for in-house testing.
Our installer will always override the application at its old location(Seems to be important).
If now someone installs a new version of our software(All files in same location) and starts it the old versions from <userdir>/var/cache is used. No matter if we change the specification version or not.
The only thing that seems to work around this is using a new installation directory or changing the userdir for every version. Both solutions are not good. Our customers dont want a parallel installation of all versions and the other solution will produce huge user profiles(also not very customer friendly).
To reproduce this bug:
1. Create a Module Suite Project s1 (This is one of the module suits that really contains code).
2. Create a Module on s1 s1m1.
3. Create a TopComponent and put a label with text "1.0.0" on it.
4. Create a Netbeans Plattform Application Project npa1 (This does not have any sourcecode. It is used for branding and combining the other suits).
5. Add the suit s1 as inter suit dependency to npa1
6. Build s1
7. Create zip for npa1
8. Extract the zip to folder <INST_DIR>
9. Execute from <INST_DIR>/bin
10. Look for the TopComponent.
11. Exit application
12. Change the label in s1m1 to "1.0.1"
13. Change the specification version of s1m1
14. Repeat steps 6-10(It is important to use(Override) the directory <INST_DIR>)
15. You will still see "1.0.0" in the label although the jars and xml state the new version.
Tested on Linux, MacOSX, WIN 7
Each cluster in your installation contains file .lastModified which needs to be touched if a module is updated in that cluster. The timestamp of .lastModified is compared to the timestamp stored in <userdir>/var/cache/lastModified/all-checksum.txt
Can you check if .lastModified in your cluster (e.g. <INST_DIR>/npa1/.lastModified) has a new modification time?
If I search the build directories of the suits I find a lastModified file for each suite.
If I create a zip for my suite no .lastModified is added(that zip is used to create our installer).
The install directory does not contain any .lastModified(neither after installation nor after first run)
Reproducible. I would have expected that the cache infrastructure would detect the lack of any .lastModified and disable the cache for that cluster, but it does not - it silently ignores any changes in the cluster.
Integrated into 'main-golden', will be available in build *201007090001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <email@example.com>
Log: #188164: .lastModified files not included in ZIP distribution so var/cache/lastModified does not work
Verified the fix with *201007090001*.
Now it works as expected.
(In reply to comment #4)
> I would have expected that the cache infrastructure would detect
> the lack of any .lastModified and disable the cache for that cluster, but it
> does not - it silently ignores any changes in the cluster.
Yarda can you comment on whether this is also a bug?
Must not be backported without a fix of bug #188601 being backported as well.
re: "lack of .lastModified" - for some reason the infrastructure keeps private $userdir/var/cache/lastModified/... files. Probably to allow caching of (read only) installation directories with missing .lastModified file. This can be changed, I am not sure however about the impact.
Only P1 stoppers are valid candidates for 6.9.1 since June 30. What's the reason to transplant this P3 issue into 6.9.1?
Then not a candidate, I guess. Not sure about exact priority, but probable workaround is to delete $userdir/var/cache/lastModified between restarts. The problem is that it may take some time before the user even realizes the bug is happening, and the workaround is certainly not obvious.
And it is not even clear how to delete the file. From within its own platform program its a bit too late since the wrong jars have already been loaded.
I think this i a high priority bug without workaround.
Better workaround would probably be to create a custom override in suite build.xml of build-zip target which calls super and then updates the ZIP inserting the .lastModified files in every cluster. Or instruct user to touch .lastModified in every affected subdir after unpacking ZIPs.
Raising priority to P1 and marking again as a 6.9.1 candidate.
Justification - even though there is a theoretical workaround, the users will not figure it out without an insight in the caching mechanism. Even worse, the users may first not realize at all that some problem occurred - everything looks like it is working at first, later the user may notice that an obsolete version of some modules is running.
Approved for 6.9.1.
The fix has been ported into the release691 branch.