This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 197914

Summary:	Autoupdate refuses to install autoload and eager modules if their deps are not satisfied
Product:	platform	Reporter:	_ rkubacki <rkubacki>
Component:	Autoupdate	Assignee:	Libor Fischmeistr <lfischmeistr>
Status:	NEW ---
Severity:	normal	CC:	jglick, jtulach
Priority:	P3
Version:	7.0
Hardware:	PC
OS:	Linux
Issue Type:	ENHANCEMENT	Exception Reporter:

Description _ rkubacki 2011-04-20 17:52:14 UTC

Same with NB6.9/6.9.1/7.0

Imagine an AUC containing following modules:
com.acme.foo - visible in AU
com.acme.foo.ext1 - eager module with implementation dependency on non-public module A from NB6.9
com.acme.foo.ext2 - eager module with implementation dependency on non-public module A from NB6.9.1
com.acme.foo.ext3 - eager module with dependency on module A from NB7.0

Now it is not possible to install com.acme.foo because AU issues warning about non satisfied dependencies in two modules. This is weird if you take into account that com.acme.foo does not declare any dependency on any of com.acme.foo.extX. The expectation is to include the extension through OpenIDE-Module-Recommends and it will lead to the same error.

The workaround is to make com.acme.foo.extX modules visible and explain that only one of them should be installed (I marked them eager to let module system handle it!).

An alternative with autoloads that fails to install again.
com.acme.foo - visible in AU, requires com.acme.foo.ext
com.acme.foo.ext1 - autoload module with implementation dependency on non-public module A from NB6.9, provides com.acme.foo.ext
com.acme.foo.ext2 - autoload module with implementation dependency on non-public module A from NB6.9.1, provides com.acme.foo.ext
com.acme.foo.ext3 - autoload module with implementation dependency on now public module A from NB7.0, provides com.acme.foo.ext

The same type of error:
Some plugins require plugin A to be installed.
The plugin A is requested in implementation
version xyz.

The decision whether selected modules can be installed or not should be only based on regular modules. Then when actually installing they should be accompanied with libraries and bridges.

As a result it is hard to build an IDE extension that contains support with dependencies on individual versions. A workaround with multiple autoupdate servers is bad because it does not support upgrades (how to migrate this setting stored in userdir?).

Comment 1 Jaroslav Tulach 2011-04-21 14:16:30 UTC

Sounds more like a feature request, then a high priority bug. 

Btw. Maybe this could be a good reason to contribute and make the API in question public?

Comment 2 _ rkubacki 2011-04-21 15:23:56 UTC

The goal of plugin manager is to bring NetBeans installation from a one valid state into another valid state. Addition of a module set that consists of regular modules with satisfied dependencies + some autoload/eager modules that can be turned off by runtime is a valid transition. But plugin manager refuses to do it. IMO it is a bug not an enhancement.

Your comment about making the API public is irrelevant here.
1. My extension can provide richer or simpler functionality based on a version of module that it binds with. It does not matter if the API is public or not.
2. There are too many APIs that are not public yet very useful. Forcing people to copy and paste is not a good way and sometimes it does not help. API review process does not work - it takes too long and it does not help you to create a module for released version.

Comment 3 Jesse Glick 2011-04-21 15:41:15 UTC

Agreed with reporter that this a defect. The real module system supports this scenario by quietly ignoring eager or recommended modules whose dependencies cannot be satisfied, and PM is supposed to follow the module system's semantics.

P2 is appropriate given that there is no known satisfactory workaround. May also be a blocker for publishing SQE for NB 7.0 - one component uses the Maven embedder which changed incompatibly, and I had hoped to publish two variants of this component (6.9- and 7.0+).

Comment 4 Jaroslav Tulach 2011-04-23 15:32:39 UTC

(In reply to comment #2)
> Your comment about making the API public is irrelevant here.

Not at all. The primary problem is that you are using implementation dependency (e.g. you are bypassing what is supported). As soon as you eliminate it, none of these tricks will be needed.

I accept the bug report, but I am not going to accept high priorities for something that should have been fixed by proper software engineering.

Comment 5 _ rkubacki 2011-04-25 16:12:04 UTC

Stable APIs are evolving as well so there is a case to have different implementation of some feature targeting particular version.

Comment 6 Jiri Rechtacek 2014-01-31 15:17:33 UTC

No intention for fixing this in the near future, it requires a bit complex changes in Auto Update Services which cannot be addressed during stabilization phase.