NB6AutoupdateChanges

Summary of planned changes in Autoupdate/Plugin Manager after M10

What's new?

  • 07/09/04*
  • 07/08/08
  • The branch au_110566 was merged into trunk. IZ 110566 was fixed.
  • 07/08/04
  • 07/07/31
  • 07/07/23
  • 07/07/19
  • 07/07/18
  • 07/07/17
  • 1st version is ready to review.

Purpose of this document: Resume several proposals and ideas (attached below) and make final plan of changes. This plan must be reviewed and approved before implementation.

Contents


Abstract

Plugin Manager (since M10) allows do grouping set of NetBeans modules in UI units (aka feature). Plugin Manager handles install, update, uninstall or activate/deactivate these features. Content (set of modules) of features is declared in Update Center catalog, it's like 'branding', an central authority must group modules into features. It has some problems: doesn't work in NetBeans which are in offline mode. And requires declare new element for 3rd party contributors.

Opposite way how to declare group of modules is extending of module metadata and let Autoupdate to do grouping itself based of that metadata. It doesn't require an central authority to specify group and allows module owners/leads to control grouping.

On the basis of planned change then UI of Plugin Manager will be adjusted - less granularity, some columns replacement, Updates tab will change its behaviour.

Relevant documents

Change outline

Planned change is close of Trung's proposal ( NB6AutoupdateChangesTrungMail), it's only rectified in details.

  • The visibility of modules in Plugin Manager will be controlled by new one attribute in module's manifest (AutoUpdate-Show-In-Client by 5), possible values are true or false
  • true makes module to be shown in Plugin Manager and an user can manipulate them (set of allowed operations depends on the type of module)
  • false makes module hidden in UI
  • Restrict uninstall operation on module is allowed by attribute in module's manifest (AutoUpdate-Essential-Module by 3) where
  • true restricts users to manipulate this module
  • false as default, set of allowed operations is not restricted
  • A visible module becomes as a kit module. Handling of kit module means handling all directly or indirectly depending modules at once. With the exception of no-visible modules which are currently depending to another kit modules. Examples are following below.
  • Eager modules must be recognized by Autoupdate, it's means some another flag in UC DTD.
  • UC DTD will contain not-mandatory attribute eager w/ possible values false or true
  • By 1 UC DTD will contain not-mandatory attribute autoload w/ possible values false or true for symmetry

That's all.

I'm going to show now some examples of handling operations on modules after that a explanation why needed of special handing of eager modules and finally answers all Jesse's questions ( NB6AutoupdateChangesJesseAnswer).

Examples

Legend of diagram:

  • Bold rectangle - A module with AutoUpdate-Show-In-Client: true
  • Normal rectangle - A module without AutoUpdate-Show-In-Client
  • Dash-line rectangle - A module with AutoUpdate-Show-In-Client: false
  • Cylinder - Autoload module with AutoUpdate-Show-In-Client: false
  • Cross - Eager module with AutoUpdate-Show-In-Client: false
  • Arrow A-->B means a regular module-to-module dependency, i.e. A module depends on B module

File:NB6AutoupdateChanges/base-objects NB6AutoupdateChanges.png

Example A

  • What I can see in PM if all modules in diagram are installed already?
  • All kit modules Ruby, Ruby Debugging, Ruby Editing and JRuby
  • No modules with visibility attribute set to false, of course
  • And also I can see Bob's Ruby because it's 3rd party module (based on NB5.5) i.e. w/o any new attributes



\

Example B1

File:NB6AutoupdateChanges/install-jruby NB6AutoupdateChanges.png

Now let's suppose that no modules in the diagram are installed, all modules are new stuff now.

  • What will be installed if I would like to install JRuby?
  • Directly depending modules: Ruby Editing, Java Ruby Editing, Ruby Hints, Project API
  • Indirectly depending modules: Projects UI, Project's Support
  • What I can see in UI - Install wizard when installing JRuby?
  • JRuby module, of course, and all visible modules in JRuby's subtree as depending modules = Ruby Editing i.e. UI says: The following plugins were scheduled to installation: JRuby | The following plugins have to be added to the installation, because one or more plugins you are about to install depend on them: Ruby Editing.
  • Did I missed installation a eager module Ruby/JRuby bridge?
  • Yes, you missed it because no module can depending on eager module. A solution will be discussed in Handling eager modules.

Example B2

And then let's suppose a small correction of example above: now I have got platform already installed.

  • What will be installed if I would like to install JRuby in installed platform?
  • Directly depending modules: Ruby Editing, Java Ruby Editing, Ruby Hints (Project API is part of platform)
  • No indirectly depending modules because Projects UI, Project's Support are installed in the platform

Example B3

As same state of IDE installation before the example B2.

  • What I can see if I want to install Bob's Roby module?
  • Only Bob's Ruby module.
  • What will be installed?
  • Bob's Ruby and Java Ruby Support





\

Example B4.1 #4

File:NB6AutoupdateChanges/eager-autoload NB6AutoupdateChanges.png

Let's suppose only autoload AU1 module is installed.

  • What will be installed when I install R2?
  • Only R2. Nothing else.

Example B4.2

Let's suppose only R1 module is installed. No AU1, E1 nor R2 are installed.

  • What will be installed when I install R2?
  • R2 and PM utilizes autoload attribute and figure out that AU1 and E1 can be installed as well => PM will install R2, AU1, E1




\

Example C1 #2

File:NB6AutoupdateChanges/uninstall-ruby-editing NB6AutoupdateChanges.png

Let's supposed all modules are installed in IDE.

  • What I can see in UI (Uninstall wizard) when I would like to uninstall Ruby Editing?
  • PM traversals down and finds out all visible modules depending on Ruby Editing, i.e. Ruby and JRuby and then asks me if I am sure to uninstall Ruby Editing
  • What will be uninstalled if I would agree to uninstall Ruby Editing?
  • Uninstall Ruby Editing module, of course
  • PM traversals down and find all modules in Ruby Editing subtree, excludes such modules what are required by any other visible modules. In this case uninstall Ruby Hints as well. Because Projects API is most probably required by some any visible module, so doesn't uninstall it.
  • PM traversals up and makes depending modules deactivated (strictly speaking, the Openide Module Manager disables these modules rather than PM)
  • Shouldn't PM uninstall also those modules depending on Ruby Editing, i.e. Ruby and JRuby, rather then deactivating them w/o any chance to activate them again? It's a open issue for me. I don't have a strong opinion here. Maybe uninstallation towards up could be better.



\

Example C2

As same assumption as before.

  • What I can see in UI when I'm going to uninstall JRuby?
  • Only JRuby is displayed.
  • What will be uninstalled if I uninstall JRuby?
  • Only JRuby because Bob's Ruby is still installed and depends on Java Ruby Support module.
  • Did I missed uninstall also a eager module Ruby/JRuby bridge?
  • Yes, you missed it because no module can depending on eager module. A solution will be discussed now.

Handling eager modules

  • Autoupdate must pay a special attention to eager modules. See 4 use-case
  • While doing a operation on visible modules (install or uninstall) the Autoupdate should loop eager modules and check if its dependencies can be affected by being operation, it means if Autoupdate does Install operation then installs eager module in that case of all its dependencies could be satisfied. In opposite if Autoupdate does Uninstall then uninstall also affected eager module which dependencies have been being broken.
  • But it also means that modules which declared on UC must be marked as eager => need to special flag.
  • We can extend AutoUpdate-Show-In-Client attribute with more states, e.g. visible|hidden|eager or
  • we can declare another one attribute in module's manifest, e.g. OpenIDE-Module-Is-Eager or
  • extend UC DTD with new one attribute, e.g. eager=true|false
  • I prefer the last one because writing if the module is eager or not into manifest is duplicating information in Module system. But no strong opinion.




Example D1

  • What I can see in Download tab if I would like to install new one module from NBM?
  • The module in shown regardless AutoUpdate-Show-In-Client
  • Rest as same as in examples above.

Change Review

(in order Newest first)

(Jesse Review 2 NB6AutoupdateChangesJesseReview2 #5)

  • What about provide-require/need/recommend dependencies? They are not mentioned. Are they interpreted by AU?
  • Dependency.TYPE_REQUIRES is already handled
  • Dependency.TYPE_RECOMMENDS and Dependency.TYPE_NEEDS have been interpreted yet - filed as task IZ110273
  • I don't like using the "OpenIDE-Module-" prefix for manifest attributes which are not in fact interpreted by the module system. (-S-I-AU-C, proposed -Essential), I would not recommend using attribute names which imply permanent status in the official Modules API. Perhaps "AutoUpdate-" prefixed attributes would make it clearer that these exist solely for the benefit of the current Plugin Manager UI and behavior?
  • Regarding *-Essential attribute: maybe. Seems preferable to special-casing modules in the platform cluster, which would not work for some modules we would probably consider "essential", e.g. projectui. (Although projectuiapi, which a lot of things have a dep on, -Needs projectui, so this particular case would probably not pose a problem.) Could alternately combine both attributes into one AutoUpdate-Visibility attribute, with possible values "visible", "hidden", "essential"?

(based on Jesse review NB6AutoupdateChangesJesseReview #1)

  • If the default value of AutoUpdate-Show-In-Client is true, then there is there any reason to ever explicitly set it to true?
  • I think it's good thing to declare both states. Makes it more understandable to module owners. Moreover, it could be handy in next releases when we can decide filter out modules w/o this attribute. Modern modules should declare own visibility in PM.
  • If we add an 'eager' attr to the UC.xml DTD, we should also add an 'autoload' attr for symmetry; maybe we will want it in the future.
  • If low-level regular modules are hidden, it is still possible for them to be disabled without the user's knowledge or intent. Suppose for sake of example that someone has a hard dep on Core - Windows (o.n.c.windows) from a module in the uml cluster, for whatever reason - maybe an impl dep or something for some hacky reason; but that this is the _only_ such direct dep on that module. Now suppose the user has UML support installed but decides to disable it. What happens? o.n.c.windows is now a hidden module which was "used" only by a visible module which is now being disabled. So, it gets turned off - and the IDE explodes. This is why I believe that none of the proposals offered so far adequately account for platform modules. #3
  • PM handles modules in a different way: any modules in platform cluster cannot uninstall then in any way
  • next one attribute in module's manifest: OpenIDE-Module-Essential w/ values true or false
  • What would happen if you have a visible autoload or eager module? There is no explanation here and I think it would make no sense - you cannot manipulate it like a regular module.
  • PM recognizes such modules and doesn't allow to call activate/deactivate actions. Only install or uninstall. It's already solved in PM|NBM View.
  • It should not be real problem. All eager or autoload modules should have set AutoUpdate-Show-In-Client to false
  • In diagram, what happens if I disable "Ruby" (but leave on "Ruby Debugging" and "Ruby Editing")? Nothing, apparently. So why is it there?
  • Yes, it's weird. But I think my example should show a possible situation, not state in real-life situation where a kit module contains only another kit modules and nothing else. Take a technically view it's correctly, when I uninstall Ruby then only kit goes away, rest of modules alive it.
  • "if Autoupdate does Install operation then installs eager module in that case of all its dependencies could be satisfied" is likely incorrect. It should (IMO) only install it in case the eager module's dependencies would not be satisfied if the rest of the install operation were not taking place. Otherwise, the first time you installed _any_ module, you could get a bunch of totally unrelated eager modules installed as well. BTW this is also one place where you need to have the autoload flag in UC.xml, because you _must_ install any currently missing autoload deps of the new eager module but _must not_ install non-autoload deps.
  • Good catch. Proposed autoload flag can help here. PM tries satisfy dependencies to autoload modules, if are available then include them into collection modules to install.
  • See new one example 4
  • "we can declare another one attribute in module's manifest, e.g. OpenIDE-Module-Is-Eager" - no. The eager and autoload status is already defined in config/Modules/*.xml. I agree that eager (and autoload!) status should be represented in the UC DTD. (It is unnecessary in the NBM itself, i.e. Info.xml, since config/Modules/*.xml in the ZIP already has this information.)
  • Agreed, see NB6AutoupdateChanges#ChangeOutline.
  • NBM DTD shouldn't contain these attributes but NBMs are input for make Update Center ant task and will be helpful if will be there.
  • In section "Update Handling", what is the logic here for deciding what information to display? It is not explained at all. If you look carefully, you will see three categories from the tables above, plus one module (in the "Java" category but that is not shown).
  • TBD. Jano should contribute here.
  • "Shouldn't PM uninstall also those modules depending on Ruby Editing, i.e. Ruby and JRuby, rather than deactivating them w/o any chance to activate them again?" - yes, I think they should be uninstalled, not just disabled. If you want them back you can get them from AU.

(based on Jesse questions NB6AutoupdateChangesJesseAnswer)

  • 1. What, if any, NBM and/or UC.xml format changes are required relative to NB 5.x; including both actual format changes (new manifest attrs, DTD changes) and changes in conventional usage (e.g. special meaning of display category etc.).
  • New one attribute in manifest: AutoUpdate-Show-In-Client true|false
  • all modules with AutoUpdate-Show-In-Client: false are hidden in all cases in UI (except download tab - Example D1)
  • Is it mandatory? No, if the case it's missing the module is made visible (need to backward compatibility to NB5.x).
  • New one attribute eager in module element in UC DTD
  • important only when browsing content of UC, no need to write it down into module system nor update_tracking
  • No special meaning of display categories, no overloading them for declaring additional information.
  • 2. Definition of which entities (modules, kits, features, ...) are displayed in the PM dialog and what controls this selection.
  • Only AutoUpdate-Show-In-Client attribute
  • 3. Exact semantics of enable and disable operations for all visible entities, given in some kind of pseudocode, taking into account autoload and eager modules as appropriate.
  • I guess that examples above can answer here.
  • 4. Exact semantics of install and uninstall operations for all entities, again taking into account autoload and eager modules (and paying special attention here to the fact that the current UC.xml format does not distinguish autoload and eager modules so this information is currently missing for modules which have not yet been installed).
  • Also examples are showing meaning of install/uninstall operations
  • No special handling of autoupdate modules
  • Handling of eager modules is covered at Handling eager modules
  • 5. Treatment of low-level modules with UI which we would probably prefer users never manipulate or perhaps even see, e.g. Project UI or Window System.
  • All low-level modules are supposed to be hidden, i.e. AutoUpdate-Show-In-Client: false in its manifest
  • 6. Impact, if any, on RCP applications which use mostly platform-cluster modules; including both those which bundle PM (.au.ui module?) and those which do not.
  • I guess no impact.
  • 7. Special steps required, if any, by developers of extra standalone modules to be placed on AU, e.g. Mercurial support or Ant Manual; and compatibility implications for developers who ignore or are unaware of our PM changes.
  • No, backward compatibility shouldn't be broken. If AutoUpdate-Show-In-Client: false attribute is missing theirs modules are shown in PM.
  • 8. Special steps required by developers of larger suites of functionality to be placed on AU, e.g. Collaboration support, which we would prefer to display as a single entity.
  • Mark kit module Developer Collaboration as visible and rest of module as hidden (by AutoUpdate-Show-In-Client: true|false)
  • 9. Relationship to installer components, and expected UI of either removing a whole installed component, or adding a new installer component (e.g. Ruby Support) using PM.
  • Display categories of visible modules must follow proposed table Less granularity.
  • Install IDE component: select all modules in the same category and install - PM supports this use-case
  • Uninstall IDE component: select all modules in the same category and uninstall - PM supports this use-case
  • 10. Detailed examples of the new logic in action, using actual modules in our IDE (or update centers) for illustration.

UI changes

Less granularity

Full NetBeans distribution

See NB6VisiblePlugins.


List of regular modules on update center

Modules from development update center, for illustration only. Specific list TBD.

Module Category


Code Template Tools Editing
Insert Unicode Editing
Next Error Action Editing
Eclipse Project Importer Import
JBuilder Project Importer Import
Ant 1.7.0 Documentation Java
Archiver Java
Freeform Project Extras Java
INSANE module Java
Jackpot Java
Jalopy Java Source Code Formatter Java
JMX Java
Maven Java
NetBeans API Documentation NetBeans Plugin Development
NetBeans API Samples NetBeans Plugin Development
NetBeans Runtime Inspector NetBeans Plugin Development
NetBeans Scripting Language Development Tools NetBeans Plugin Development
Groovy Languages
PHP Languages
Prolog Editor Support Languages
Scala Languages
TCL Editor Support Languages
Velocity Editor Support Languages
Embedded JavaScript (EJS) Phobos
Ruby Samples Ruby
Load Generator Testing
Build Monitor Utilities
Developer Collaboration Utilities
DocBook Utilities
Explore from Here Utilities
Filters Utilities
Folder To Html Utilities
Generic Navigator Utilities
Group of Files Utilities
Mercurial Utilities
Mount Utilities
Object Type Changer Utilities
Project Minder Utilities
Project Packager Utilities
Quick File Chooser Utilities
Task List Utilities
GlassFish V3 Module Web and Java EE
GWT4NB Web and Java EE
HTML Project Support Web and Java EE


Update handling

File:NB6AutoupdateChanges/updates NB6AutoupdateChanges.png




\ Available updates notification in the Status Bar

  • I propose do regular checking of available updates (by given once-a-week period) and notify IDE users if any updates (new stuff is ignored for notification).
  • An icon in status bar is click able and can invoked Update wizard. Like in NB5.x but notifies only updates.

Plugin Manager change in columns

  • Install/Release Date are removed?
  • no, this column should stay there, it makes sense for the users who want to repeatedly check what's new on update centers
  • width of PM dialog should be extend
  • Category columns is added.
  • More precisely, PM will be in current NBM view. Plugin view is removed at all.

Tasks and Time-schedule

The list of tasks is at http://www.netbeans.org/nonav/issues/showdependencytree.cgi?id=110566

Building

Merged to trunk. Branch is now dead. Merge log

Automated tests relating to AU visibility

Open issues

  • Example C1 2 - uninstall major depending modules if its dependencies cannot be solved
  • Modules in platform cluster should be handled differently. 3
  • How to handle update of essential modules what are need but has no ancestor?

Postpone enable/disable/uninstall modules to the restart IDE

Problem

Plugin Manager allows to call disable/enable on many modules at once, disable is called for example on tens of modules. When disable of many module is executed (e.g. on Web and J2EE component or simple Form module when more forms are open in editor) then probably many exceptions are usually thrown, deadlock or a loop for forever are imminent. It makes this PM functionality unusable. Modules are not isolated with one another and fix all declared and undeclared dependencies is unmanageable in NB6 time frame.

Solution

  • leave NB Module system to handle disable/enable operation offline
  • Autoupdate would execute disable/enable operation either in IDE closing time or during IDE startup
  • Autoupdate will do Uninstall offline as well, autoupdate/updater will carry about deleting module's files

Tasks

  • Change Autoupdate handling of disable/enable/uninstall operations
  • Support new module's state in Plugin Manager UI See PluginUninstallation
  • AU/Updater handles removing module's files if modules are planned for uninstall

Tracked as IZ 114106

  • made branch
    offline_disable_114106
    through directories: autoupdate/services, autoupdate/ui and core/launcher
Not logged in. Log in, Register

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