GoogleContainerTools
jib-maven-plugin does not offer a help goal
Environment:
- Jib version: 2.7.1
- Build tool: Maven
- OS: N/A
Description of the issue:
Invoking mvn jib:help results in error
[ERROR] Could not find goal 'help' in plugin com.google.cloud.tools:jib-maven-plugin:2.7.1 among available goals _skaffold-fail-if-jib-out-of-date, _skaffold-files-v2, _skaffold-init, _skaffold-package-goals, _skaffold-sync-map, build, buildTar, dockerBuild -> [Help 1]
Expected behavior:
Printable information on all available goals provided by the jib plugin.
Steps to reproduce:
- create a micronaut application using the command line tool mn create-function-app myfunction --features oracle-function --build=maven --lang-java
jib-maven-plugin Configuration:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<configuration>
<to>
<image>${jib.docker.image}:${jib.docker.tag}</image>
</to>
<container>
<args>${exec.mainClass}::handleRequest</args>
<mainClass>${exec.mainClass}</mainClass>
</container>
</configuration>
</plugin>
Log output:
It's customary (but not mandated) to provide a help goal when writing Maven plugins.
@aalmiray Thanks for the feature request! This is a good issue for anyone willing to contribute.
I've been looking at this for a bit and while I'm not 100% sure (really the first time I've worked with Gradle) it looks like the underlying Gradle plugin: io.freefair.maven-plugin should already run the DescriptorGeneratorMojo Task. I expect this should generate the help Mojo during compilation.
As far as I can tell, the task is in the build cycle but the plugin isn't generating anything. We could create a HelpMojo that artificially patches this issue but I'm not sure if that's the intent of this Issue or if I'm just completely lost.
FWIW I use
plugins {
id 'de.benediktritter.maven-plugin-development' version '0.3.1'
}
And it does create the help mojo.
I was able to take the Mojo generated by that plugin and do something similar. It's still a new Mojo, but it at least reads the generated plugin-help.xml then parses it into the help text. I'll pull together a unit test and send a push soon.
@meltsufin I added a PR request to address the issue it needs a review before it can be merged. Let me know if there's any issues.
One particular disadvantage of this approach is that any changes made to the mojos must be reflected on the HelpMojo, this is why it's preferred to generate the HelpMojo rather that having it as explicit source.
I tried to work around that thought process by reading the generated descriptor and generating the help text from the XML. So while it's not ideal compared to having the entire Mojo generate at compile time, the checkstyles and testing requirements of this repository prevent the generated Mojo from being accepted.
Then I’d suggest adding the generated sources to a skip list, after all those sources are generated from templates not by a developer. The only caveat would be if generated sources become part of the source release or source jar (that would be really weird).
I guess what I’m trying to say is, if the tooling/conventions get in the way and force you down a path that’s not optional then challenge the tooling/conventions.
I'm at loss for this one. Someone else can take this as I can't find a clear solution without creating a new plugin to perform the same task.
Thank you for giving this a try. I'll keep this issue open and see if anyone else is interested in trying to implement this feature.
