-
-
Notifications
You must be signed in to change notification settings - Fork 429
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 i18n-maven-plugin dependency #2584
Conversation
When the plugin dependency is managed you can also use the plugin without adding GAV parameters to commands. E.g. it allows for using it with: ``` mvn i18n:generate-default-translations ``` Related to openhab#2544 Signed-off-by: Wouter Born <[email protected]>
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.
LGTM. Thanks.
<plugin> | ||
<groupId>org.openhab.core.tools</groupId> | ||
<artifactId>i18n-maven-plugin</artifactId> | ||
<version>${project.version}</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.
@wborn This seems to break our release build as it is a SNAPSHOT dependency, which is not allowed - see https://ci.openhab.org/view/Sandbox/job/sandbox-openhab3-release/439/console.
We probably would have to maintain it in a separate repo just like SAT or only add this dependency after releasing version 3.2.
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.
The separate repo is probably the cleanest solution. You could also try to move the whole plugin configuration to a profile that is enabled by default but disabled during release. I'm not 100% sure if the no-snapshot check also includes disabled profiles, though.
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've reverted the PR for now. I'm not a big fan of many repos because of all the overhead and when code changes it can only be used after creating a release. Especially for new code like this tweaks may be necessary. 😉
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 understand your pov, but afaik you cannot build plugins and use them in the very same reactor. So they will require an independent release cycle - however we achieve this.
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.
It could also be an idea to put a different label on the "box" currently called "static-code-analysis" (build-tools?). Then the name would allow for putting more similar stuff into that box. 🙂
But it is still possible that when the data in OH-INF changes, the plugin would start depending on OHC snapshot dependencies to be able to parse it. So you'd not be able to use an updated version of the plugin until OHC is released.
When the plugin dependency is managed you can also use the plugin without adding GAV parameters to commands.
E.g. it allows for using it with:
Related to #2544