-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add create, list-extensions and add-extension mojos #165
Conversation
Generate a test for the generated resources
Implementation of the list-extensions mojo Implementation of the add-extension mojo These Maven goals are related to #157
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am ok with this as long as it is understood that this is just a short term thing for M1, that will be replaced later.
Thinking about it I am not actually sure the main repo is the place for this. Would there be any real downside to having these CLI style mojo's under a different plugin artifact?
<dependency> | ||
<groupId>jline</groupId> | ||
<artifactId>jline</artifactId> | ||
<version>2.14.6</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should probably be managed in the parent pom
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1, will fix it.
If we move it outside of the main plugin, it needs another "prefix" and cannot reuse "shamrock" (or whatever it will be). So this would not be possible:
It would be something like:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a usability perspective then I guess it is better to just have them all in the same module then.
@@ -0,0 +1,185 @@ | |||
[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't really our long-term solution though, right? Wouldn't we want to maintain a published extension list of some sort?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely a placeholder for something better later. These commands are just there until we get a proper CLI.
For the extension, we will need a repository/registry somewhere. I've attempted to scan maven central, but it's not a good way (required > 24 hours to scan the artifacts...). I think this registry will be part of the web site.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We definitely need a real discovery mechanism. I am happy to merge this as it makes it easy for people to get started when we do the internal reveal, however I this we need to make sure that everyone understands that this is a temporary solution.
Example of usage:
This PR is related to #157