I wouldn’t necessarily call these bad smells. If you don’t care about supporting UI users there is no need to support managed rules.
Post #87 indicates @Seaside may have found a way to support JSR223 which would enable UI support. But after scanning the the beta announcement posts above it doesn’t appear to have been implemented. As far as I know, JRule remains incompatible with UI rules (i.e. managed rules).
This also means it probably cannot be used in transformations.
I do believe it’s an automation addon now instead of a binding which is good and development continues.
@Seaside, one thing I noticed here was it was kind of hard to follow the releases/changes between releases because there are separate posts for each. The template for posts in this section of the marketplace does support a change log. It can be a lot easier for users to see that there is a new release and what’s in that release if the changelog is part of the top post. You can even see that from MainUI.
I think the template has changed a couple times since this was originally posted. The current template is:
> **Please remove this block and other instruction placeholders after reading these instructions**
>
> _:arrow_right: Your add-on must abide by the [Marketplace Rules](https://community.openhab.org/t/about-the-add-on-marketplace-category/123408#community-marketplace-contributing-rules-nov-2-2021-1), make sure to read them before submitting a new add-on._
>
> Remember to add the proper tags:
> - one tag denoting the type of the add-on is required: use one of _binding_, _automation_, _io_, _persistence_, _transformation_, _ui_
> - _published_ is necessary if you want users to see your entry in the UI. If you want to draft it before publishing, don't add the tag now and use the "Show Unpublished Entries" option in Settings > Community Marketplace to see it anyway in the UI until you're ready to add it.
> - self-assess the maturity level of your add-on with one of the _alpha_, _beta_, _stable_, _mature_ tags
> - you can package your add-on as a JAR or KAR file. In the former case, provide a direct link to the binary ending in .jar. In the latter case, provide a direct link to a binary ending in .kar, and add the _kar_ tag (mandatory). Don't name any Karaf feature "_openhab-something_", as the "_openhab_" prefix is reserved for the distribution features and have special behavior.
_[🖍 Add a brand logo here. The first image of the post will be promoted and put as an icon for the add-on when browsing in the UI. Change the alt name of the image to `logo` i.e.:
`![logo](url)`
otherwise it will be shown twice in the UI.]_
_[🖍 Replace with a general description. Everything above the first heading will be shown by default, the rest hidden and behind a "more" button - so remember to keep it short. You can add more heading to document the add-on in more detail if necessary.]_
## Changelog
_[🖍 Optional but recommended: Add a list of the changes you made for each version, as suggested below (remove example sections). The provided structure is for illustration only and can be changed freely.]_
### Version 0.2
- fixed: ...
- added: ...
### Version 0.1
- initial release
## Resources
_[🖍 Copy a ***direct and stable*** download link to a .jar or .kar file here, hosted by your preferred service - GitHub etc.]
_[🖍 MANDATORY: Copy a link to the source code (GitHub repository or other) - the marketplace rules mandate that the source of all Java-based add-ons be available]
And in fact, the way the add-on currently appears in MainUI is a little jumbled.
But over all, if you added and kept up to date a changelog section above the Resources it will allow users to see what’s changing without monitoring this thread or needing to scan through 140+ posts.