Can we create seperate threads for these issues so that proper discussion can occur.

Simply creating a google spreadsheet and assigning ill defined tasks to other people isn't a very good strategy.

Anyway here's my take on the issues (largely guesswork except where I'm already aware of the issue)

JBOSGI-143 - DynamicImport-Package

There are three issues here:

1) The dynamic imports are not getting added to the ClassLoadingMetaData requirements (this is because of number 2)

2) The dynamic imports in jboss-cl don't support wildcards

3) Dynamic imports require some kind of lazy resolve handling when the bundle doesn't automatically progess through to ACTIVE.

(1) is trivial except for the handling of (2) which requires a change in jboss-cl. The PackageRequirement only accepts are a single explict package

as it stands.
(3) requires a change to the deployers to implement the Lifecycle api I defined in JBCL-131. JBCL-131 has only remained open because

I'm not sure its got all the details  correct until the deployers implement it and we can test edge cases.

JBOSGI-204 - Error semantics for OSGi Bundles

I don't know why JBDEPLOY-225 exists? This is an OSGi specific feature. It should implement its own ErrorHandler

to do what it wants. We don't want this semantic for normal deployments.

Why this is assigned to me I don't know? My only input on this topic was pointing out that the ErrorHandler exists. I know very little

about how it works since Ales implemented it. I could figure it out, but then so can you.

JBOSGI-206 - Wire to uninstalled deployments

This has two aspects and the first is actually JBOSGI-213 - Unexpected dependee state changes.

For me this is a bad semantic since it is likely to lead to memory leaks, but that's the OSGi spec so it should be configerd to OSGi bundles.

1) To avoid a bundle getting unresolved when a wire gets unresolved/undeployed then the OSGi requirements need to be able to

tell the RequirementDependencyItem not to update the dependsOnMe of the dependency. It is that which causes the cascade

of unresolution.

2) When an OSGi bundle gets unresolved. The classloader shouldn't be uninstalled from the classloading system. That should wait for

the refreshPackages(). That means whatever implements the package admin needs to keep track of unresolved classloaders and

properly uninstall them at that time.

The uninstall of the classloader is in the classloading deployers (with an additional safety check in DeployersImpl).

Besides the potential for memory leaks, there's other issues with (2). But any search on classloading FAQs for OSGi would likely

be more comprehensive than any list I can reproduce. ;-)

JBOSGI-209 - Resolver preferences

These are really aimed at resolving rules for ambiguous cases. I don't have a problem with tightening up these rules in jboss-cl

but two of them appear to be about split packages rather than ambiguities.

* A resolved exporter must be preferred over an unresolved exporter.

There is no notion of this in jboss-cl. There will be some preference for previously resolved dependencies

since it resolves first against the ClassLoaderSpace and only then looks at what is in the Domain.

But this is not the exact same semantic since the ClassLoaderSpace can contain unresolved stuff.

However, to me this is a split package and it should resolve to all them with the same version, unless some

rule (e.g. your split package policy) says otherwise.

* An exporter with a higher version is preferred over an exporter with a lower version.

This should already work. If it does not then show an example on a bug report.

* An exporter with a lower bundle ID is preferred over a bundle with a higher ID.

There is no direct notion of this in jboss-cl, but it should behave in a similar way since the Modules are stored in registration order in a List

inside the Domain. But again this is split package stuff.

NOTE: It is not a split package if they have the same package name but a different version. These are different packages.