Bug 194518 - Add API for calling org.netbeans.modules.autoupdate.ui.api.PluginManager.openInstallWizard(OperationContainer<InstallSupport> oc);
Add API for calling org.netbeans.modules.autoupdate.ui.api.PluginManager.open...
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Plugin Manager
7.0
All All
: P2 (vote)
: 7.0
Assigned To: Jaroslav Tulach
au-issues
: API, API_REVIEW_FAST
: 146153 (view as bug list)
Depends on: 146153
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-20 10:02 UTC by David Strupl
Modified: 2011-02-16 11:42 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Making PluginManager class stable API (50.43 KB, patch)
2011-02-07 14:14 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Strupl 2011-01-20 10:02:08 UTC
We need to be able to show the wizard for downloading and installing a module from the update center from mobility UI.
Comment 1 Adam Sotona 2011-01-20 10:41:07 UTC
this is the changeset with the full fix we need: 
http://hg.netbeans.org/jet-main/rev/d286690e4f14

this is the changeset commenting-out the not-yet-approved dependency on autoupdate.ui module: 
http://hg.netbeans.org/jet-main/rev/18af8dd2e3a7

Pushback of the second commit enables the fix functionality using the already available friend API.
Comment 2 Jesse Glick 2011-01-21 12:57:01 UTC
Mobility usecase might no longer be valid; asotona can comment.

I also have a patch in progress (might or might not be used) that involves downloading an NBM plus its dependencies. Currently it works without any new API, but it is somewhat awkward to do (I had to search source code to find an example) and the UI is much cruder than the normal AU experience. Excerpted code:

String module = ...;
for (UpdateUnit unit : UpdateManager.getDefault().getUpdateUnits(UpdateManager.TYPE.MODULE)) {
  if (unit.getCodeName().equals(module)) {
    List<UpdateElement> updates = unit.getAvailableUpdates();
    if (updates.isEmpty()) {
      ...check to see if it is installed but disabled?
    }
    OperationContainer<InstallSupport> oc = OperationContainer.createForInstall();
    UpdateElement element = updates.get(0);
    if (!oc.canBeAdded(unit, element)) {
      ...
    }
    for (UpdateElement req : oc.add(element).getRequiredElements()) {
      oc.add(req);
    }
    String license = element.getLicence();
    String moduleLabel = element.getDisplayName();
    if (license != null) {
      if (DialogDisplayer.getDefault().notify(new NotifyDescriptor.Confirmation(license, ..., NotifyDescriptor.OK_CANCEL_OPTION)) != NotifyDescriptor.OK_OPTION) {
        continue;
      }
    }
    try {
      // make cancelable somehow...
      ProgressHandle handle = ProgressHandleFactory.createHandle(BrokenReferencesCustomizer_downloading(moduleLabel));
      InstallSupport is = oc.getSupport();
      Validator validator = is.doDownload(handle, false);
      Installer installer = is.doValidate(validator, null);
      Restarter restarter = is.doInstall(installer, null);
      if (restarter != null) {
        is.doRestart(restarter, null);
      } else {
        // new module appears asynch something soon
      }
    } catch (OperationException x) {
      // ...
    }
  }
}
// handle case that module was not found...

Being able to replace everything starting with "String license" with one call that opened the standard wizard UI would be nice.

In fact this whole block, which is pretty generic, ideally could be replaced with a simple high-level API like

void downloadModule(String cnb) throws ...;

which would block and then either return normally after the module had been installed and enabled (in my patch it is necessary to wait for this using Thread.sleep); restart the platform; or throw some exception for cases such as:

1. No such module found on AU.
2. User rejected download, say because of license.
3. Download failed.
4. Install failed.
5. Install succeeded but could not be enabled in current session and user declined to restart.
6. Dependencies missing or rejected.
Comment 3 Adam Sotona 2011-01-24 10:12:20 UTC
It is still valid case for Mobility. 
I would prefer to invoke current InstallWizard through the existing (friend) API instead of making and maintenance of a new UI.
Comment 4 Jaroslav Tulach 2011-01-24 14:30:36 UTC
Right Jesse, when I objected against the patch, I wanted Adam to use the autoupdate.services in a way you propose in comment #2. I admit, this is not straightforward and there shall be an API to make it simpler and actually we have an implementation: org/netbeans/modules/ide/ergonomics/fod/ConfigurationPanel.java

That one creates a JComponent which can be inserted anywhere to handle the whole process of downloading. That JComponent could for example be used inside the mobility project wizard to do everything in one place and not to require the user to deal with other, overlapping dialogs.


org.netbeans.api.autoupdate.ui.Utitilites (in new or existing module?)

would probably be the right place for putting methods dealing with the dialog as well as even higher level void downloadModule(String cnb) which would wrap the above into a DialogDisplayer.
Comment 5 Adam Sotona 2011-01-24 15:18:10 UTC
There is already a friend API in autoupdate.ui module.
It is simple, working and alrady used by several modules:
 com.sun.tools.dlight.tools.customizer
 org.netbeans.modules.autoupdate.pluginimporter
 org.netbeans.modules.cnd.toolchain
 com.microchip.mplab.nbide.embedded

Truly - I don't understand this discussion. 
We don't have enough resources for basic tasks and here we are going to spend time of several engineers to design a new API that is not necessary.

I don't see any other requirements then to be able to invoke the AU UI.
Please add mobility.project module into list of the friends or make the API public for wider audience.

Thanks,
Adam
Comment 6 Jesse Glick 2011-01-24 17:36:36 UTC
openInstallWizard(OperationContainer<InstallSupport>) would probably suffice for most if not all clients (including my patch in progress) - opening the standard Plugin Manager wizard is generally fine. I agree with Adam that we should start with that; just clean up the package and class name in autoupdate.ui and expose it as public rather than just to friends. The impl in FoD could be factored out into a more powerful API in the future if there are enough potential clients that require an embeddable component.
Comment 7 Jaroslav Tulach 2011-02-02 15:01:42 UTC
Very related to issue 146153. Btw. Adam, if you want, you can add yourself to list of friends. I am making this bug P2, with the goal to redesign the API for 7.0 version and make it stable.
Comment 8 Jesse Glick 2011-02-03 00:21:44 UTC
(In reply to comment #7)
> Very related to issue 146153.

Isn't it simply a duplicate?
Comment 9 Jaroslav Tulach 2011-02-07 14:14:34 UTC
Created attachment 105702 [details]
Making PluginManager class stable API
Comment 10 Jaroslav Tulach 2011-02-07 14:15:58 UTC
*** Bug 146153 has been marked as a duplicate of this bug. ***
Comment 11 Jesse Glick 2011-02-07 19:41:21 UTC
Looks OK to me.
Comment 12 Jiri Rechtacek 2011-02-08 08:16:33 UTC
Okay for me too.
Comment 13 Jaroslav Tulach 2011-02-14 09:09:56 UTC
OK, let's integrate tomorrow.
Comment 14 Jaroslav Tulach 2011-02-15 10:37:48 UTC
ergonomics#fb99f9253b50
Comment 15 Quality Engineering 2011-02-16 11:42:34 UTC
Integrated into 'main-golden', will be available in build *201102160501* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/fb99f9253b50
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #194518: PluginManager.openInstallWizard is now stable API


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