Allowing only plugins to run, and allowing options for them

[anthonyalayo]

This is a prototype solution for issue #168.

I would prefer a more cleaned up solution, especially regarding the plugin options.

[codecov]

Codecov Report

Attention: Patch coverage is 72.72727% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 83.28%. Comparing base (5d4054c) to head (2a51064).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #167      +/-   ##
==========================================
- Coverage   83.53%   83.28%   -0.25%     
==========================================
  Files          26       26              
  Lines         850      855       +5     
  Branches       64       66       +2     
==========================================
+ Hits          710      712       +2     
- Misses        113      114       +1     
- Partials       27       29       +2     

Files	Coverage Δ
...opes/protobufmavenplugin/AbstractGenerateMojo.java	100.00% <100.00%> (ø)
...tobufmavenplugin/generate/SourceCodeGenerator.java	79.05% <83.34%> (-0.76%)	⬇️
...es/protobufmavenplugin/execute/ArgLineBuilder.java	82.36% <33.34%> (-5.14%)	⬇️

[ascopes]

I mentioned this on the related issue but would setting Java support to be false in the existing configuration settings suffice for this feature, or is there another use case that you have in mind for this?

[anthonyalayo]

@ascopes let me try that out. I believe I tried that at first and it wasn't working, but I could have something else as the issue at that time.

[ascopes]

Would it be possible to add a JavaDoc to this field? Reason being it will be used to generate the documentation for this parameter in the generated GitHub pages. Worth adding a @since 1.3.0 here as well.

[ascopes]

I am wondering if we want to include metadata on plugins in a more controlled way whether it is worth revamping how plugins are defined so that you can tie options down to the specific plugins they apply to.

That'd possibly be an implication of a v2.0.0 release due to the breaking change (unless I keep the old ways of managing this around and just deprecate them) but I am more than happy to explore that possibility.

I did look into the idea of having just one way of specifying plugins that let you specify one of the path name, the URL, or the artifact... but I couldn't think of a good typesafe way of doing it. Nothing stopping me making another attempt though.

<plugins>
  <plugin>
    <type>PATH</type>
    <name>protoc-gen-grpc-java</name>
    <options>
      <option>foobarbaz</option>
    </options>
  </plugin>
</plugins>

What are your thoughts on this? I might try to throw a proof of concept together this afternoon for it.

[ascopes]

Thanks for raising this! I've added some comments on here and on the issue... like you say,
I think it is worth making sure we've covered all the cases we need so we don't have to come back and change this in a breaking way in the future. Will look forward to hearing your thoughts.

---

Just a side note that I've had to make some structural changes to the repo to keep versions more consistent between tests... so this will need to be rebased (sorry to cause hassle!)

Another change that has been made on the main today since you raised this is that I've changed how the ArgLineBuilder class works a bit. Originally this was to make it easier to test some behaviours and how they differ based on argline ordering, but it has the side effect that it introduces an internal Target interface in that class that can now hold stuff like additional parameters to inject. That means we can probably extend that to achieve a similar effect if we decide to go ahead with this solution.

[ascopes]

I've been thinking about this and I think that in the long run, it is going to be more beneficial to make a breaking change for this so that the plugin attributes in the config can take an options parameter each. This allows directing options to individual plugins rather than all plugins.

This would be breaking purely on the basis that I'd have to slightly change how URL and Path based plugins get provided in config.

I have some code locally that I can push later once I have tidied it up a bit, I will run that past you once it is ready.

Going to close this for now as there are some other architectural changes that I will likely include in this solution to keep stuff easy to test going forwards.

Thanks for taking the time to put this together though, and thanks for your patience, it is greatly appreciated!

[anthonyalayo]

@ascopes thanks! For that solution, could you also add an option to not fail if the plugin binary is not found? That was another angle that just came up yesterday for me. The current code supports this for missing proto sources, but not missing plugins. (I have optional plugins).

[ascopes]

Will see what I can do, are you able to raise a separate issue for it?

[anthonyalayo]

Done -- #182