Changing packaging for plugins

[tylerhawkes]

Changing packaging to jar and greatly simplifying the poms so that developing plugins is much easier. I don't necessarily expect this to be merged, however, after looking around and doing some testing - this looks like a much easier way to setup the pom structure as an example. It really requires no configuration in the individual plugins, just a reference to the parent pom. Since .jar extensions are fully supported and don't require unzipping on the file system I think they're the preferred plugin to keep sizes small in containers and not require writes at runtime.

This doesn't address any existing issues. I just wanted to start a discussion on how to make using this framework as easy as possible.

[coveralls]

Coverage decreased (-0.3%) to 57.111% when pulling e3a982e on tylerhawkes:master-pom-refactor into 44acc38 on decebals:master.

[coveralls]

Coverage remained the same at 57.388% when pulling 328a1c6 on tylerhawkes:master-pom-refactor into 44acc38 on decebals:master.

[decebals]

Is it complete functional?

[tylerhawkes]

It works for me and the demo has the expected output and it loads all the plugins. Go ahead and try it out.

I'm working on a more production ready setup using the maven shade plugin to always exclude slf4j and some others because that has been causing me some issues when starting up, but I'll include that as another pull request if this gets merged.

[decebals]

I tested and it's work.
Thanks for your contribution!
I have the same idea like you, to simplify the usage of PF4J to increase the adoption. PF4J has been designed from the ground to be easy to use and understand.

[decebals]

I see a little duplication in demo, we defined the plugin's metadata in both places: plugin.properties and pom.xml (the "properties" section). In the past "properties-maven-plugin" (Maven plugin) injected properties from plugin.properties file in pom.
So we can:

• use plugin.properties with properties-maven-plugin
• remove plugin.properties and put the values in properties section of plugin's pom.xml (the approach from this PR)
  I don't know how approach is better (simple).

[tylerhawkes]

I think having properties in the pom is simpler because they can be inherited from a parent pom and there's no dependency on having an extra file somewhere. I have another example that I'll submit in another pull request to demonstrate. I think it makes building plugins even easier.

[decebals]

@tylerhawkes

I have another example that I'll submit in another pull request to demonstrate. I think it makes building plugins even easier.

Can you show me the code or give me some info (eventually snippet/pseudo code)?

[tylerhawkes]

Take a look at https://github.com/tower-hawk/tower-hawk/tree/master-refactor-plugin/plugins
The maven shade plugin takes care of some of the issues with slf4j by always excluding it. The actual plugins themselves are pretty straightforward and only need to have the correct parent.

[decebals]

@tylerhawkes
Your approach with maven-shade-plugin looks clean and simple (only few lines). The project also looks clean (structure, ...).
I played with both approaches (where to store the plugin's metadata):

• plugin.properties
• JAR's MANIFEST.MF (pom.xml)

The approach with keep plugin's metadata in MANIFEST.MF (pom.xml) looks nice because you have some defaults/variables (artifactId, version, ...) and inheritance support from Maven. My only problem with this approach is that I cannot run the whole application (including all plugins) from IDE (IDEA InteliJ in my case). It's very useful for me, in development phase, to run the whole application using the main static method (like a banal Hello app). What I must to do is to set pf4j's mode on development (-Dpf4j.mode=development) and it's done.
How do you treat this aspect in your project (development, test, ...)? Do you use development mode?
In my opinion, to build the plugins' jars each time when I want to start app or to use mvn command exclusive it's a decrease in productivity.

[tylerhawkes]

If the plugin supported multiple directories then that could also solve the problem. In development mode it could look for something like plugins//target/-plugin.jar and load all of them. Then there would be nothing special required to get it to run and debug with an IDE and the pom's would look clean.

[decebals]

In development mode it could look for something like plugins//target/-plugin.jar and load all of them.

Yes, but the jar file is created on package Maven build lifecycle. In the compile phase the jar is not available and I don't want to run mvn package to create the jar file before I run the application.
The approach with plugin.properties works because the file is available after compile but MANIFEST.MF is only available after you package the jar.

[decebals]

@tylerhawkes Did you see my previous comment? Can you explain me how you run your plugins in the development phase?

[tylerhawkes]

For now I've just been having Intellij run mvn package -DskipTests before I start up. I takes about 8 seconds. I know it's not ideal, but I still want my pom to be as clean as possible.
I was looking for documentation about development mode and it's pretty light. Does it look inside of a target folder if available for the classes?
We have some options - either support multiple directories specified as a glob or list of globs, create a fake MANIFEST.MF file at compile time so that development works, or find something else. The multiple directories would be useful even in production. I'm sure we can find something that works.

[decebals]

@tylerhawkes

I was looking for documentation about development mode and it's pretty light. Does it look inside of a target folder if available for the classes?

Exactly.

Thanks for your explanation!