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
