Pros and Cons for the modular approach and what can be improved?

[FDelporte]

Regarding the modular approach of Pi4J V2.

Pro

• allows having a flexible architecture
• is open for further extension (providers)

Cons

• causing confusion on how to configure a context
• not clear how to add the required dependencies
• can't create a FAT jar

The use of Pi4J.newAutoContext() is also not clear in this matter as to which providers are loaded and can be used to control the GPIOs. First idea: should we remove this method and force the user to define which context (providers) they want to use?

Are there ideas, suggestions, contributions which can make this approach more clear and easy to use?

Some of the related issues and discussions

• Digital Output state change does not change pin voltage #161
• Java modules: add more info to website, document how/why, alternative approach with jlink/graalvm? #84
• Cannot extract native libraries from jar on Pi 4B #39
• PrviderNotFoundException #126

[camueller]

Pi4J started as a library to provide access to Raspberry Pi GPIO pins. That's what people look for in order to enable their Java appliactions to interact with those GPIO pins. I'm using Pi4J 1.x since 5 years and it worked well so far.

In my opinion the modular approach of Pi4J V2 add just many layers of abstraction with no use for most users. Even worse, it uses pigpio only and not pigpiod which would not force to run the process as root. You may have a look at pigpioj which provides access to both. Therefore it is not correct to state that Pi4J has to run with sudo because of pigpio. sudo is required because Pi4J does not support pigpiod which is a design flaw of Pi4J.

[tpnela]

I am very grateful that you guys took it upon yourself to reboot the pi4j project.
Shedding external dependencies like wiringpi and allowing for newer Java versions was truly necessary. I already had started learning Python (Lordy!) because I had hit a wall with Java and the Raspberry 4.

I can not comment too much on the V2 yet because I just now started fooling around in a sandbox. But I can give my opinion on a number of topics, I think are relevant in this discussion.

• Java modules. I don't know whether the module approach isn't a bit over-engineered. I understand where the need for jigsaw came from but the applications that are likely going to use pi4j are not the ones that drown in dependency issues. Probably using the classic package systems wouldn't do any harm.
• Running as fat jar. Now that makes life so much easier. I package all my existing applications in fat jars, drop them via ssh and fire them up. Easy. I would hate to give that up
• Running as sudo. What I am doing here on the raspberry is just hobby. I wouldn't mind running with sudo. But in my dayjob, I do real IIoT in a manufacturing environment and our security auditor would never sign off on anything that runs in sudo. And rightly so. So this depends on how serious you want to be taken with the library.

[mipastgt]

In the foojay article you provide a differnt list of pros and cons. Maybe you could harmonize that with the pros and cons given here.

I'd also need some more details because some arguments are not obvious to me and I'd tend to disagree with them. E.g., why do you think you have to use a module.info? Nobody forces you to provide a module.info in order to support some modular design. I also don't understand why using a ServiceLoader should preclude using a FAT jar. I guess I am missing some context here.

[FDelporte]

Thanks @mipastgt @tpnela and @camueller for your feedback. I took some time of last week, but will get back to you asap with some more info to get this topic sorted asap.

[FDelporte]

As I needed some more info myself to fully understand the fat jar issue, I documented this further. You can find it as a new page on our Pi4J website: https://pi4j.com/documentation/building/fat-jar/

There is also an open issue related to the use of modules: #84

[mipastgt]

So your fat-jar issue is basically a shortcoming (or I would even call it a bug) of the maven-assembly-plugin then, isn't it?

[FDelporte]

Good thinking... let me check out if I can find more info regarding the maven-assembly-plugin. Bumping to latest version seems to still be the same issue.

[FDelporte]

maven-shade-plugin gives more output and actually shows this exact problem

[INFO] Including org.slf4j:slf4j-api:jar:1.7.32 in the shaded jar.
[INFO] Including org.slf4j:slf4j-simple:jar:1.7.32 in the shaded jar.
[INFO] Including com.pi4j:pi4j-core:jar:2.0 in the shaded jar.
[INFO] Including com.pi4j:pi4j-plugin-raspberrypi:jar:2.0 in the shaded jar.
[INFO] Including com.pi4j:pi4j-plugin-pigpio:jar:2.0 in the shaded jar.
[INFO] Including com.pi4j:pi4j-library-pigpio:jar:2.0 in the shaded jar.
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
[WARNING] Discovered module-info.class. Shading will break its strong encapsulation.
[WARNING] pi4j-core-2.0.jar, pi4j-example-fatjar-0.0.1.jar, pi4j-library-pigpio-2.0.jar, pi4j-plugin-pigpio-2.0.jar, pi4j-plugin-raspberrypi-2.0.jar, slf4j-api-1.7.32.jar, slf4j-simple-1.7.32.jar define 1 overlapping resource: 
[WARNING]   - META-INF/MANIFEST.MF
[WARNING] pi4j-core-2.0.jar, pi4j-library-pigpio-2.0.jar, pi4j-plugin-pigpio-2.0.jar, pi4j-plugin-raspberrypi-2.0.jar define 3 overlapping resources: 
[WARNING]   - LICENSE.txt
[WARNING]   - NOTICE.txt
[WARNING]   - README.md
[WARNING] pi4j-plugin-pigpio-2.0.jar, pi4j-plugin-raspberrypi-2.0.jar define 1 overlapping resource: 
[WARNING]   - META-INF/services/com.pi4j.extension.Plugin
[WARNING] maven-shade-plugin has detected that some class files are
[WARNING] present in two or more JARs. When this happens, only one
[WARNING] single version of the class is copied to the uber jar.
[WARNING] Usually this is not harmful and you can skip these warnings,
[WARNING] otherwise try to manually exclude artifacts based on
[WARNING] mvn dependency:tree -Ddetail=true and the above output.
[WARNING] See http://maven.apache.org/plugins/maven-shade-plugin/

[mipastgt]

You should have a look at resource transformers: https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html There is one specifically for this case: ServicesResourceTransformer

[FDelporte]

thanks will do!

[FDelporte]

The FAT JAR issue is fixed! Jieha ;-)

Thanks to the feedback in this discussion and replies to this tweet by Robert Scholte and Karl Heinz Marbaise, a working example could be created.

Full info on: https://pi4j.com/getting-started/minimal-example-application-fatjar/

More detailed FAT JAR info on: https://pi4j.com/documentation/building/fat-jar/