openhab-core: [JSR223] Most Java classes are no longer available after ESH migration
I’m testing this on S1534. Classes that were previously available can no longer be imported. Here is a list of the ones I have tested, when trying to update the openhab2-jython libraries. The ones with ##### worked, but the others did not.
# core.date
from org.openhab.core.library.types import DateTimeType as LegacyDateTimeType
#####from org.eclipse.smarthome.core.library.types import DateTimeType
#####from org.eclipse.smarthome.core.items import Metadata
#####from org.eclipse.smarthome.core.items import MetadataKey
from org.joda.time import DateTime
from org.eclipse.smarthome.automation.core.util import RuleBuilder
#####from org.openhab.core.automation import Rule as SmarthomeRule
#####from org.openhab.core.automation.handler import TriggerHandler
# core.triggers
from org.eclipse.smarthome.automation.core.util import TriggerBuilder
#####from org.openhab.core.automation import Trigger
#####from org.eclipse.smarthome.config.core import Configuration
#####from org.eclipse.smarthome.core.thing import ChannelUID, ThingUID, ThingStatus
from org.eclipse.smarthome.core.thing.type import ChannelKind
#####from org.eclipse.smarthome.core.types import TypeParser
# DirectoryEventTrigger
from org.eclipse.smarthome.core.service import AbstractWatchService
# JythonTransform
from org.eclipse.smarthome.core.transform import TransformationService
# JythonThingTypeProvider
#####from org.eclipse.smarthome.core.thing.binding import ThingTypeProvider
# JythonThingProvider
#####from org.eclipse.smarthome.core.thing import ThingProvider
# JythonItemChannelLinkProvider
from org.eclipse.smarthome.core.thing.link import ItemChannelLinkProvider
# JythonBindingInfoProvider
from org.eclipse.smarthome.core.binding import BindingInfoProvider
# personal.utils
from org.eclipse.smarthome.model.script.actions.Exec import executeCommandLine
from org.eclipse.smarthome.model.persistence.extensions import PersistenceExtensions
# core.actions
from org.openhab.core.scriptengine.action import ActionService
from org.eclipse.smarthome.model.script.engine.action import ActionService
@lewie reported this in openhab1-addons/#5281. @vbier also reported something similar in the forum.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 41 (21 by maintainers)
Commits related to this issue
- Add DynamicImport-Package for scripted automation Fixes #610 Signed-off-by: Scott Rushworth openhab@5iver.com (github: openhab-5iver) — committed to 5iver/openhab-core by deleted user 5 years ago
- Add DynamicImport-Package for scripted automation Fixes #610 Signed-off-by: Scott Rushworth openhab@5iver.com (github: openhab-5iver) Signed-off-by: Scott Rushworth <openhab@5iver.com> — committed to 5iver/openhab-core by deleted user 5 years ago
- Add DynamicImport-Package for scripted automation Fixes #610 Signed-off-by: Scott Rushworth <openhab@5iver.com> (github: openhab-5iver) — committed to 5iver/openhab-core by deleted user 5 years ago
- Add DynamicImport-Package for scripted automation Fixes #610 Signed-off-by: Scott Rushworth <openhab@5iver.com> — committed to 5iver/openhab-core by deleted user 5 years ago
- Add DynamicImport-Package for scripted automation (#663) Fixes #610 Signed-off-by: Scott Rushworth <openhab@5iver.com> — committed to openhab/openhab-core by deleted user 5 years ago
- Updated docs to reflect use of annotation is preferred. (#790) Closes #610 Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl> — committed to Rosi2143/openhab-core by Hilbrand 6 years ago
The majority of imports will be in the helper libraries. When this issue is resolved, I will be providing a release of the libraries to support the changes. This release will require that they are using a minimum version of OH that contains the fix. There have been other breaking changes in the API that required upgrades of the libraries. Users may need to change some imports in their scripts and modules, but that shoiuld be minor, and these will be the more experienced users. Anyone not using the libraries will have some work to do, but it would also be a good opportunity for them to switch over to using the libraries.
For the future, maybe OH3, the helper libraries, which show what users actually want to be doing with scripted automation, can be absorbed into some of the Automation classes and a new scripting API. Some (most?) can also be turned into Actions, which could then also be accessible directly through the NGRE. The ESH reintegration, repo moves, and lack of UI in the Core Development IDE have really been holding me back. But things seem to be settling down now, and with #635 finally committed, I will be working on Jython and Groovy bundles, and some of the Automation bugs. While doing this, I plan to open some discussions in the Developer section of the forum to discuss plans for moving forward with the NGRE and scripted automation… specifically, what needs to be done to get it mainstream in OH3. I would really like to see some Github projects setup in this repo for better visibility, prioritization, and coordination of efforts for Automation.
I like what you’re thinking, but for the time being, I think they just need to be made accessible again in order to get things working. 😄
BTW, could you please share the Demo app changes that you used to be able to test this? I think I am at the same place you were, where the engine is running, but scripts aren’t loading. At some point, I really need to get Jython scripts working in the IDE again too.