Re: Auto-Update Experience

Martin,

To maintain backward compatibility with my own module I am compiling 
against NetBeans 3.4 openide JAR files instead of the 4.0 JAR files. The 
changes Jesse made seem to break modules at build time but if they are 
built against 3.4 then they will still run on dev builds.

The exception may be the modules that depend on openidex/looks. It is 
possible that openidex/looks has changed so that it won't run on 3.4 
anymore, I am not sure. But, in MDR's case this would only affect MDR 
explorer. The rest of MDR should work fine (that is, people should be 
able to use trunk MDR in their own modules).

Besides openidex/looks, has anything else changed? Maybe it is possible 
to just branch MDR Explorer instead of all of MDR?

Thanks,
Brian

Martin Matula wrote:
> Hi,
> as we will have to break compatibility of MDR with the NetBeans release 
> 3.4 (because of incompatible changes in openide in main trunk), I have 
> created a new branch in MDR named release34, that contains the latest 
> MDR compatible with NB 3.4. In the future (if it is requested) we can 
> commit all the important bugfixes from main trunk into this branch.
> Since autoupdate modules that are on dev Alpha center will no longer 
> work with 3.4, I have put the most recent version of MDR compatible with 
> 3.4 on the NetBeans 3.4 Alpha Update Center and also I have updated the 
> installation instructions to clarify that it is no longer advised to use 
> NetBeans dev Alpha Center from NetBeans 3.4 to get the daily updated 
> versions of MDR modules - you should rather use the regular NetBeans 3.4 
> Alpha Update Center to get MDR modules compatible with NB 3.4.
> Thanks for understanding,
> Martin
> 
> Martin Matula wrote:
> 
>> Hi Brian,
>> thanks for pointing this out.
>> I will update the modules on 3.4 autoupdate, and change the 
>> installation instructions to tell users to use appropriate autoupdate 
>> for each version of NetBeans - as now the modules on 4.0 dev 
>> autoupdate got incompatible with 3.4.
>> Martin
>>
>> Brian Smith wrote:
>>
>>> 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
>>>
>>
>>
>