Obsolete packages not removed from Java Package Manager (232640)
The information in this article applies to:
- Microsoft virtual machine
- Microsoft SDK for Java 2.0
- Microsoft SDK for Java 3.1
- Microsoft SDK for Java 2.01
- Microsoft SDK for Java 2.02
- Microsoft SDK for Java 3.0
This article was previously published under Q232640 SYMPTOMS
If you have distributed version V1 (for example, 0,0,0,1) of a Distribution Unit (DU) containing packages A, B, and C, then upgrading to version V2 (for example 0,0,0,2) of the same DU containing packages A and C, with package B now being obsolete, would not remove package B from the Java Package Manager.
RESOLUTION
A workaround is to ship package B in version V2 of the DU (so that version V2 of the DU has packages A, B, and C) in such a way that you remove all the classes and/or resources from package B and replace them with a single dummy file (for instance, 'obsolete.txt').
STATUS
This behavior is by design.
MORE INFORMATION
The reason for keeping package B in the Java Package Manager is to accommodate incremental upgrades of the DU as given in the above example. In such a scenario, package B might not be really obsolete. It just might be that package B was not included in version V2 of the DU because it had not changed since version V1 of the DU.
Not removing obsolete packages from the Java Package Manager would result in the following side effects:
consumption of disk spaceyou would still be able to successfully compile against the old classes in package B
The workaround suggested would remove the obsolete package(s) and replace them with a dummy file, '0' bytes in size, thereby taking care of the above-mentioned side effects.
REFERENCES
For support information about Visual J++ and the SDK for Java, visit the following Microsoft Web site:
| Modification Type: | Major | Last Reviewed: | 6/14/2006 |
|---|
| Keywords: | kbFAQ kbJava kbprb KB232640 |
|---|
|