Auto-Update Experience

Brian Smith <[email protected]> Tue, 05 Nov 2002 16:47:54 -0600
Newsgroups gmane.comp.java.netbeans.modules.mdr.devel
Organization CollabNet Hosting
Message-ID <[email protected]>
Hi Everybody,

If you follow the instructions for installing MDR on NetBeans 3.4 on a 
clean installation, and you only have the "NetBeans Dev Alpha Auto 
Update Center" selected (not any of the non-dev update centers), then a 
new version of Open API's gets selected for installation. But, when the 
IDE tries to restart after downloading, NetBeans fails to start at all 
ever again (W2K, JDK 1.4.1, NB3.4). I have had this happen twice when 
testing it all out.

Oddly enough, it seems that if the MDR components are selected in some 
particular order, then the new OpenAPI modules doesn't get selected for 
installation for some reason. But then MDR Explorer won't start because 
the version of core/naming in NB Alpha Dev Auto Update Center has 
OpenIDE-Module-IDE-Dependencies: IDE/1 > 3.14 which is a very recent 
development version. Looks depends on core/naming and MDR Explorer 
depends on Looks. So when installing Core/Naming it is important that 
you choose the version that is in "NetBeans 3.4 Alpha Update Center" not 
the one in "NetBeans Alpha Dev Update Center."

When all the update centers are selected (not just dev alpha), then it 
seems that auto-update will install the NB3.4-compatible core/naming and 
everything works fine. But, I don't know if this is guarenteed behavior 
or just some kind of coincidence.

This is confusing and I wonder if there is some way around it? Couldn't 
the versions of the MDR modules in "NetBeans 3.4 Beta Auto Update 
Center" occasionally be updated to more recent versions so that people 
don't have to deal with the Dev Alpha Update Center (which really seems 
to be intended for 4.0 Dev builds)?

Also, the documentation refers to MDR Explorer to "MDR Explorer" but the 
auto-update center displays this as "Metadata Repository Explorer." I 
think the auto-update center should use the term "MDR Explorer" since 
that is what everybody calls it. Or, conversely, the module catagory 
shouldn't be named "MDR" if the goal is to avoid abbreviations.

- Brian