Skip to content

Cleanly separate core ops infrastructure from ops discovery #59

@ctrueden

Description

@ctrueden

For ops discovery, we want to use an industry standard mechanism (or mechanisms). Maybe Spring (#55), maybe plain ServiceLoader via JPMS module-info.java, maybe even something else. The Ops design should not conflate this with the engine itself, which has only the OpEnvironment interface, and accessor(s) for the OpInfos it has in its bag. Similarly, OpService as built on the SciJava service framework is a separate thing, which should not be part of the core ops engine at all.

To ensure this, the scijava-ops-api and scijava-ops-engine modules (or whatever they end up being named) must not depend on scijava-indexer, scijava-plugin, scijava-context, and similar layers relating to discovery, dependency injection, or application containers. It must be possible to create a "vanilla" OpEnvironment with a explicitly specified bag of ops.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions