Skip to content
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

Merged
merged 1 commit into from
Dec 2, 2021
Merged

Conversation

wborn
Copy link
Member

@wborn wborn commented Dec 1, 2021

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 #2544

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]>
@wborn wborn requested a review from a team as a code owner December 1, 2021 21:19
Copy link
Contributor

@cweitkamp cweitkamp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks.

@cweitkamp cweitkamp merged commit e0544e2 into openhab:main Dec 2, 2021
@cweitkamp cweitkamp added this to the 3.2 milestone Dec 2, 2021
@wborn wborn deleted the add-i18n-dep branch December 2, 2021 07:27
<plugin>
<groupId>org.openhab.core.tools</groupId>
<artifactId>i18n-maven-plugin</artifactId>
<version>${project.version}</version>
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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. 😉

Copy link
Member

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.

Copy link
Member Author

@wborn wborn Dec 3, 2021

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.

wborn added a commit that referenced this pull request Dec 3, 2021
wborn added a commit that referenced this pull request Dec 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants