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.

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.

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.

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.

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

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.

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.

(In reply to comment #7)
> Very related to issue 146153.

Isn't it simply a duplicate?

Created attachment 105702 [details]
Making PluginManager class stable API

*** Bug 146153 has been marked as a duplicate of this bug. ***

Looks OK to me.

Okay for me too.

OK, let's integrate tomorrow.

ergonomics#fb99f9253b50

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