[osgi-dev] enRoute Reactor question

[Paul F Fraser via osgi-dev]

Is it intended that all modules listed in the reactor are indexed.

In my case for some reason, only those referenced in the application start 
module(?) are indexed.

Paul Fraser

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Adding a Vaadin dependency causes trouble

[Paul F Fraser via osgi-dev]

Hi,

Building with (new) enRoute, all is well until I add a Vaadin dependency.

Video of problem https://youtu.be/MQX8ICmUHdc

Part of error report 

The default package '.' is not permitted by the Import-Package syntax.
 This can be caused by compile errors in Eclipse because Eclipse creates
valid class files regardless of compile errors.
The following package(s) import from the default package [net.qnenet.qVaadinOSGi] 
(biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)


more details in attachment.

Any ideas as to cause of problem?

Paul Fraser

https://youtu.be/MQX8ICmUHdc

The default package '.' is not permitted by the Import-Package syntax.
 This can be caused by compile errors in Eclipse because Eclipse creates
valid class files regardless of compile errors.
The following package(s) import from the default package 
[net.qnenet.qVaadinOSGi] 
(biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)

/qNoiseProtocol/pom.xml

bnd error: Calc manifest failed, state=
{

project.sourcepath=C:\Users\paulf\git\qne-maven-0.0.4\QProject\qNoiseProtocol\src\main\java,
 
project.buildpath=

C:\Users\paulf\.m2\repository\org\osgi\osgi.core\7.0.0\osgi.core-7.0.0.jar;

C:\Users\paulf\.m2\repository\org\osgi\osgi.cmpn\7.0.0\osgi.cmpn-7.0.0.jar;

C:\Users\paulf\.m2\repository\org\osgi\osgi.annotation\7.0.0\osgi.annotation-7.0.0.jar;

C:\Users\paulf\.m2\repository\org\slf4j\slf4j-api\1.8.0-beta2\slf4j-api-1.8.0-beta2.jar;

C:\Users\paulf\.m2\repository\com\esotericsoftware\kryo\4.0.2\kryo-4.0.2.jar;

C:\Users\paulf\.m2\repository\com\esotericsoftware\reflectasm\1.11.3\reflectasm-1.11.3.jar;

C:\Users\paulf\.m2\repository\org\ow2\asm\asm\5.0.4\asm-5.0.4.jar;

C:\Users\paulf\.m2\repository\com\esotericsoftware\minlog\1.3.0\minlog-1.3.0.jar;

C:\Users\paulf\.m2\repository\org\objenesis\objenesis\2.5.1\objenesis-2.5.1.jar;

C:\Users\paulf\.m2\repository\org\bouncycastle\bcprov-ext-jdk15on\1.59\bcprov-ext-jdk15on-1.59.jar;

C:\Users\paulf\.m2\repository\org\bouncycastle\bcpkix-jdk15on\1.59\bcpkix-jdk15on-1.59.jar;

C:\Users\paulf\.m2\repository\org\bouncycastle\bcprov-jdk15on\1.59\bcprov-jdk15on-1.59.jar;

C:\Users\paulf\.m2\repository\io\netty\netty-buffer\5.0.0.Alpha2\netty-buffer-5.0.0.Alpha2.jar;

C:\Users\paulf\.m2\repository\io\netty\netty-common\5.0.0.Alpha2\netty-common-5.0.0.Alpha2.jar;

C:\Users\paulf\.m2\repository\commons-io\commons-io\1.3.2\commons-io-1.3.2.jar;

C:\Users\paulf\.m2\repository\com\vaadin\vaadin-server\8.4.3\vaadin-server-8.4.3.jar;

C:\Users\paulf\.m2\repository\com\vaadin\vaadin-sass-compiler\0.9.13\vaadin-sass-compiler-0.9.13.jar;

C:\Users\paulf\.m2\repository\org\w3c\css\sac\1.3\sac-1.3.jar;

C:\Users\paulf\.m2\repository\com\vaadin\external\flute\flute\1.3.0.gg2\flute-1.3.0.gg2.jar;

C:\Users\paulf\.m2\repository\com\vaadin\vaadin-shared\8.4.3\vaadin-shared-8.4.3.jar;

C:\Users\paulf\.m2\repository\org\jsoup\jsoup\1.11.2\jsoup-1.11.2.jar;

C:\Users\paulf\.m2\repository\com\vaadin\external\gentyref\1.2.0.vaadin1\gentyref-1.2.0.vaadin1.jar,
 


settings=org.apache.maven.execution.SettingsAdapter@36c30d9d, 
-contract=*, 
Bundle-Name=qNoiseProtocol, 
maven.compiler.target=1.8, 
-snapshot=${tstamp}, 

project.output=C:\Users\paulf\git\qne-maven-0.0.4\QProject\qNoiseProtocol\target,
 
Bundle-Version=0.0.1.SNAPSHOT, 
project.build.sourceEncoding=UTF-8, 
project=MavenProject: 
net.qnenet:qNoiseProtocol:0.0.1-SNAPSHOT @ 
C:\Users\paulf\git\qne-maven-0.0.4\QProject\qNoiseProtocol\pom.xml, 

project.dir=C:/Users/paulf/git/qne-maven-0.0.4/QProject/qNoiseProtocol, 
-sources=true, 
maven.compiler.source=1.8, 
Bundle-SymbolicName=net.qnenet.qNoiseProtocol
} 
(biz.aQute.bnd:bnd-maven-plugin:4.0.0:bnd-process:default:process-classes)

org.apache.maven.plugin.MojoExecutionException: bnd error: Calc manifest 
failed, state=
{


project.sourcepath=C:\Users\paulf\git\qne-maven-0.0.4\QProject\qNoiseProtocol\src\main\java,
 
project.buildpath  =

Re: [osgi-dev] Wiring rules

[Eran Twili via osgi-dev]

Thanks Tom that does help.
In light of what you said, I have two questions please.

  1.  Isn't that even for the first set of bundles, the other bundle that 
exports the same package as the system bundle but with higher version, may be 
resolved before the importer of that package is resolved?

E.g. assume we have two bundles A and B.

Package a.b.c version 1.0.0 is exported from system bundle

Package a.b.c version 2.0.0 is exported from bundle A

Package a.b.c (no version) is imported from bundle B

FW is launched for the first time - system bundle is active

A and B are installed.

A is started (makes A resolved and then active).

Now B is started.

At this point we have bundle A and system bundle both resolved and exporting 
package a.b.c, but bundle A with higher version.

Doesn't that means that bundle B will be wired to A's export?

  1.  Regarding the fact that Equinox persist wiring.

How is that working with the system property 
org.osgi.framework.system.packages.extra, which is configurable between FW 
restarts?

I mean, after FW is stopped, we can change the system.extra property, and when 
we re-launch, the FW starts from persistent state, but the wires to the system 
bundle must change. Isn't that so?





Regards,
Eran

From: Thomas Watson [mailto:tjwat...@us.ibm.com]
Sent: Wednesday, May 09, 2018 5:18 PM
To: Eran Twili ; osgi-dev@mail.osgi.org
Subject: Re: [osgi-dev] Wiring rules

The resolution rule for preferred candidate ordering is, unfortunately, a fluid 
rule since bundles can be resolved dynamically and in different orders from one 
run to the next.

For the first resolution of a set of bundles your assertion is correct.  The 
system bundle will always be the first bundle to enter the resolved state.  So 
any exports from the system bundle will be preferred for that resolution.  But 
now consider a new set of bundles is installed after the first resolution.  If 
the first resolution contained another bundle that exported the same package 
name as the system bundle now we are in a state where two bundles are resolved 
that export the same package.  This was not true for the first resolution.  Now 
if that bundle exports the package at a higher version than the system bundle 
its package version will be preferred for the second resolution.

For restarting from a persistent state.  That depends on the framework's 
persistent implementation.  The specification does not require that a framework 
persist the resolution wiring on shutdown.  It is acceptable for the framework 
to start from an unresolved state when launching from a cached set of installed 
bundles and then re-resolve the bundles as it is launching again.  For example, 
the Felix framework does not persist the resolution wires and re-resolved all 
installed bundles on restart while the Equinox framework does persist the 
resolution wiring and will reuse the wiring state on a restart.

HTH

Tom



- Original message -
From: Eran Twili via osgi-dev 
mailto:osgi-dev@mail.osgi.org>>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List 
mailto:osgi-dev@mail.osgi.org>>
Cc:
Subject: [osgi-dev] Wiring rules
Date: Wed, May 9, 2018 9:01 AM


Hi,



I have some questions regarding wiring rules.

I know that spec says:

“The following list defines the preferences, if multiple choices are possible, 
in order of decreasing priority:

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

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

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



But I need clarification on some nuances:

1.   In case same package is exported by system bundle with version 1, and 
regular bundle with version 2, and the importers aren’t specifying a version.

Is it true to say that although regular bundles’ export version is higher, 
actually the system bundle export will be chosen (since it‘s always resolved 
first)?

Generally this means that system packages will always be preferred, even though 
there exist a bundle that exports the same package with higher version?

2.   Is the later true also after restarting the FW, going up from 
persistence area?

Generally, assuming we never make changes to bundles state after first 
activation, does wiring can change after stopping the FW and going up again 
from persistence area?



Regards,

Eran



Confidentiality: This communication and any attachments are intended for the 
above-named persons only and may be confidential and/or legally privileged. Any 
opinions expressed in this communication are not necessarily those of NICE 
Actimize. If this communication has come to you in error you must take no 
action based on it, nor must you copy or show it to anyone; please 
delete/destroy and inform the sender by e-mail immediately.
Monitoring: NICE Actimize may monitor incoming and outgoing