plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [EU-FOSSA 2 2019 Hackathon] Improved OSGi and Apache Karaf integration
Date Mon, 06 May 2019 17:42:15 GMT
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.dutz@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 <luke@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
    

Mime
View raw message