Bug 188164 - .lastModified files not included in ZIP distribution so var/cache/lastModified does not work
.lastModified files not included in ZIP distribution so var/cache/lastModifie...
Status: VERIFIED FIXED
Product: apisupport
Classification: Unclassified
Component: Harness
6.x
All All
: P1 (vote)
: 7.0
Assigned To: Jesse Glick
issues@apisupport
69patch1
:
Depends on: 188601
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-28 16:51 UTC by harvan
Modified: 2010-07-16 13:50 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description harvan 2010-06-28 16:51:54 UTC
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
Comment 1 hg8496 2010-06-29 08:29:33 UTC
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
Comment 2 Antonin Nebuzelsky 2010-07-08 11:51:55 UTC
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?
Comment 3 hg8496 2010-07-08 12:47:25 UTC
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)
Comment 4 Jesse Glick 2010-07-08 13:53:46 UTC
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.
Comment 5 Jesse Glick 2010-07-08 13:54:18 UTC
core-main #d85a4a17167a
Comment 6 Quality Engineering 2010-07-09 03:23:14 UTC
Integrated into 'main-golden', will be available in build *201007090001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/d85a4a17167a
User: Jesse Glick <jglick@netbeans.org>
Log: #188164: .lastModified files not included in ZIP distribution so var/cache/lastModified does not work
Comment 7 hg8496 2010-07-09 08:24:49 UTC
Verified the fix with *201007090001*.
Now it works as expected.
Comment 8 Jesse Glick 2010-07-09 13:28:46 UTC
(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?
Comment 9 Jesse Glick 2010-07-12 15:29:27 UTC
Must not be backported without a fix of bug #188601 being backported as well.
Comment 10 Jaroslav Tulach 2010-07-12 16:43:16 UTC
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.
Comment 11 pgebauer 2010-07-13 10:18:17 UTC
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?
Comment 12 Jesse Glick 2010-07-13 14:27:46 UTC
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.
Comment 13 hg8496 2010-07-14 04:39:52 UTC
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.
Comment 14 Jesse Glick 2010-07-14 15:35:44 UTC
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.
Comment 15 Antonin Nebuzelsky 2010-07-14 16:03:44 UTC
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.
Comment 16 Martin Ryzl 2010-07-14 16:31:47 UTC
Approved for 6.9.1.
Comment 17 pgebauer 2010-07-16 13:50:45 UTC
The fix has been ported into the release691 branch.
http://hg.netbeans.org/release691/rev/cb7260836619


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo