Hi Łukasz,
replying to what you wrote in slack:
- Yes I was running with Java 12 (Switched to that as this way I could find the
most build issues).
- And I also agree that an osgi module, which depends on the api and provides
the OSGI magic is also preferable from my point of view.
I would suggest to add an extra module to the integrations module. If the
addition is independent of karaf,
I would suggest to have a simple osgi integration module, if it's karaf
specific, then I would add it to the karaf-integration.
Chris
Am 06.05.19, 19:42 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Łukasz,
so I pulled in your changes locally and really like them.
I was a little hesitant regarding the OSGI dependency in the API module,
but as it's set to "provided" it's not that bad.
I guess we can live with that.
Regarding the PlcDriverManager, I would prefer to change it to
SimplePlcDriverManager instead of BasicPlcDriverManager.
Basic sort of sounds very similar to Base which implies it to be an
inheritance base ... but that just might be me.
However unfortunately I am having trouble with the build. When building the
karaf-features module fails with this report:
[INFO] --- karaf-maven-plugin:4.2.5:verify (default) @ karaf-features ---
[INFO] Using repositories:
https://repository.apache.org/content/repositories/snapshots@id=apache-snapshots@noreleases@snapshots,https://repo.maven.apache.org/maven2@id=central
[WARNING] Unable to resolve framework features: plc4x-api/0.4.0.SNAPSHOT
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=framework; type=karaf.feature;
filter:="(&(osgi.identity=framework)(type=karaf.feature))" [caused by: Unable
to resolve framework/4.2.5: missing requirement [framework/4.2.5]
osgi.identity; osgi.identity=org.ops4j.pax.logging.pax-logging-api;
type=osgi.bundle; version="[1.10.1,1.10.1]"; resolution:=mandatory [caused by:
Unable to resolve org.ops4j.pax.logging.pax-logging-api/1.10.1: missing
requirement [org.ops4j.pax.logging.pax-logging-api/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.xml.parsers)"]]
[WARNING] Unable to resolve framework features:
plc4x-ads-driver/0.4.0.SNAPSHOT
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=framework; type=karaf.feature;
filter:="(&(osgi.identity=framework)(type=karaf.feature))" [caused by: Unable
to resolve framework/4.2.5: missing requirement [framework/4.2.5]
osgi.identity; osgi.identity=org.ops4j.pax.logging.pax-logging-api;
type=osgi.bundle; version="[1.10.1,1.10.1]"; resolution:=mandatory [caused by:
Unable to resolve org.ops4j.pax.logging.pax-logging-api/1.10.1: missing
requirement [org.ops4j.pax.logging.pax-logging-api/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.xml.parsers)"]]
[WARNING] Unable to resolve framework features:
plc4x-ethernet-ip-driver/0.4.0.SNAPSHOT
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=framework; type=karaf.feature;
filter:="(&(osgi.identity=framework)(type=karaf.feature))" [caused by: Unable
to resolve framework/4.2.5: missing requirement [framework/4.2.5]
osgi.identity; osgi.identity=org.ops4j.pax.logging.pax-logging-api;
type=osgi.bundle; version="[1.10.1,1.10.1]"; resolution:=mandatory [caused by:
Unable to resolve org.ops4j.pax.logging.pax-logging-api/1.10.1: missing
requirement [org.ops4j.pax.logging.pax-logging-api/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.xml.parsers)"]]
[WARNING] Unable to resolve framework features:
plc4x-modbus-driver/0.4.0.SNAPSHOT
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=framework; type=karaf.feature;
filter:="(&(osgi.identity=framework)(type=karaf.feature))" [caused by: Unable
to resolve framework/4.2.5: missing requirement [framework/4.2.5]
osgi.identity; osgi.identity=org.ops4j.pax.logging.pax-logging-api;
type=osgi.bundle; version="[1.10.1,1.10.1]"; resolution:=mandatory [caused by:
Unable to resolve org.ops4j.pax.logging.pax-logging-api/1.10.1: missing
requirement [org.ops4j.pax.logging.pax-logging-api/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.xml.parsers)"]]
[WARNING] Unable to resolve framework features:
plc4x-s7-driver/0.4.0.SNAPSHOT
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=framework; type=karaf.feature;
filter:="(&(osgi.identity=framework)(type=karaf.feature))" [caused by: Unable
to resolve framework/4.2.5: missing requirement [framework/4.2.5]
osgi.identity; osgi.identity=org.ops4j.pax.logging.pax-logging-api;
type=osgi.bundle; version="[1.10.1,1.10.1]"; resolution:=mandatory [caused by:
Unable to resolve org.ops4j.pax.logging.pax-logging-api/1.10.1: missing
requirement [org.ops4j.pax.logging.pax-logging-api/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.xml.parsers)"]]
[WARNING] Unable to resolve framework features:
plc4x-simulated-driver/0.4.0.SNAPSHOT
[WARNING] Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=framework; type=karaf.feature;
filter:="(&(osgi.identity=framework)(type=karaf.feature))" [caused by: Unable
to resolve framework/4.2.5: missing requirement [framework/4.2.5]
osgi.identity; osgi.identity=org.ops4j.pax.logging.pax-logging-api;
type=osgi.bundle; version="[1.10.1,1.10.1]"; resolution:=mandatory [caused by:
Unable to resolve org.ops4j.pax.logging.pax-logging-api/1.10.1: missing
requirement [org.ops4j.pax.logging.pax-logging-api/1.10.1] osgi.wiring.package;
filter:="(osgi.wiring.package=javax.xml.parsers)"]]
[INFO] Features verified: 6, failures: 6, ignored: 0, skipped: 0
[INFO] Failures: plc4x-api/0.4.0.SNAPSHOT, plc4x-ads-driver/0.4.0.SNAPSHOT,
plc4x-ethernet-ip-driver/0.4.0.SNAPSHOT, plc4x-modbus-driver/0.4.0.SNAPSHOT,
plc4x-s7-driver/0.4.0.SNAPSHOT, plc4x-simulated-driver/0.4.0.SNAPSHOT
[INFO]
------------------------------------------------------------------------
Got any ideas what could be wrong?
Chris
Am 06.05.19, 17:52 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:
Hi Łukasz,
First of all, thank you very much for your work. It is greatly
appreciated and I know the guys at Ida analytics will appreciate that too.
Regarding your proposed changes: Well I don't think the renaming of the
class to BasicPlcDriverManager would be too bad. We would have to document it
as breaking change in the release documentation. However the API module should
still contain that class as otherwise the users would need to add dependencies
to two modules, which we had in the past and I would not like to reintroduce.
It doesn't do any harm if left in there and from a user perspective, I would
prefer it to stay in there too.
What do the others think?
Chris
Outlook für Android<https://aka.ms/ghei36> herunterladen
________________________________
From: Łukasz Dywicki <l...@code-house.org>
Sent: Monday, May 6, 2019 5:20:00 PM
To: dev@plc4x.apache.org
Subject: [EU-FOSSA 2 2019 Hackathon] Improved OSGi and Apache Karaf
integration
Dear all,
I had pleasure to meet PLC4X representatives in past weekend (4-5 May
2019) thanks to EU FOSSA 2 event. Thanks to time given to work on
Karaf-PLC4X integration I reached a point where I will be able to submit
first contribution to your project. In below mail I will briefly
describe what been done (from technical perspective) and what are
questions which needs to be answered in order to finalize OSGi support.
Things which I found during FOSSA was that:
- Generated feature sets were failing, modbus and ethernet-ip been
problematic due to some weird slf4j dance.
- `PlcDriverManager` does not work under OSGi out of the box.
I solved first one by turning feature sets in manually maintained file
which gives a complete control over how features are structured, what
are common parts and so on. Second issue with driver manager requires a
moment to introduce you to a case.
I turned every single `PlcDriver` into OSGi service. Trick is fairly
simple - each and every bundle which gets started is checked for
presence of `PlcDriver` META-INF/services entries. Any driver found
there will be registered as OSGi service:
https://github.com/ConnectorIO/plc4x/blob/eufossa/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/Activator.java#L70
When connection attempt is made a special kind of driver manager which
is OSGi aware look up for matching service:
https://github.com/ConnectorIO/plc4x/blob/eufossa/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/OsgiDriverManager.java#L62
For ease of use I decided to register `OsgiDriverManager` as OSGi
service:
https://github.com/ConnectorIO/plc4x/blob/eufossa/plc4j/api/src/main/java/org/apache/plc4x/java/osgi/Activator.java#L49
This means that as soon as plc4x-api is installed within OSGi framework
a matching service will be present waiting for other bundles which would
like to obtain connections. However, a general recommendation for OSGi
support is to defined interface which is used by service implementer and
later used by service consumer. Currently *PlcDriverManager* is a class
so I had to declare a `DriverManager` interface which I used only for
OSGi related testing.
I believe what such separation would be helpful for project and all AOP
related frameworks which could be used with typical Spring/Java EE
setups. I know these days mocking frameworks are quite powerful and do
not require interface, yet such separation adds additional boundary to
project APIs/SPIs.
Are you up for:
1) Declaring new interface to represent `PlcDriverManager`
functionality?
2) Renaming existing `PlcDriverManager` to `BasicPlcDriverManager`?
3) Moving `BasicDriverManager` to new module `plc4x/plc4j/core`?
4) Creation of plc4j/osgi module where OSGi integration will be kept?
Steps 2 and 3 will turn plc4j/api into interface only module, meaning a
proper API bundle. :-) I am aware that it will have impact on existing
java code thus would like to hear what is your opinion.
Kind regards,
Łukasz
--
http://connectorio.com
