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 Tue, 07 May 2019 07:46:21 GMT
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.dutz@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.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