gselzer on sharpen-smooth
Add DefaultSmooth and DefaultSh… Preserve differentiation in sum… Rely on helper Ops to decrease … and 1 more (compare)
org.scijava.v3.parse
instead of org.scijava.parse
. I think we will want to do it, even though it's ugly, because it will give us a lot more power later to redo APIs as needed without breaking everything.
There is still a question whether we are going to inject the incarnation of everything prior to releasing anything. E.g.
org.scijava.v3.parse
instead oforg.scijava.parse
. I think we will want to do it, even though it's ugly, because it will give us a lot more power later to redo APIs as needed without breaking everything.
Oops, I forgot to respond to this
vX
incarnation is probably the right decision
org.scijava.v3.parse
is part of the same "generation" as org.scijava.ops.engine
, org.scijava.discovery
, etc.
v3
coming between the group and artifact names? Because org.scijava.parse.v3
might look better
org.scijava.ops
at all... only org.scijava.v3.ops
. We could start at v1
though if you prefer. I don't feel strongly.
org.scijava.ops
:arrow_right: org.scijava.ops.v2
, which is weird... I'd rather go from v1
to v2
, or even v3
to v4
.
scijava-v3-ops
, scijava-v3-parse
, and so on.
scijava/scijava-v3
instead of scijava/scijava
, although I favor the latter at the moment.
Otherwise, as soon as we want to iterate on the core scijava platform again (ha ha, hopefully never, but you know... might need to break some API later)... we go from
org.scijava.ops
:arrow_right:org.scijava.ops.v2
, which is weird... I'd rather go fromv1
tov2
, or evenv3
tov4
.
Does this scheme allow us to iterate on a particular component? Do you see us ever wanting to?
org.scijava.ops2
:arrow_right: org.scijava.ops3
.
org.scijava.v2.ops
:arrow_right: org.scijava.v3.ops
scijava-ops2
and scijava-ops3
respectively.
org.scijava.parse
is taken, we have to call it org.scijava.parse2
, with artifactId scijava-parse2
.
OpEnvironment
will do no discovery...
BasicOpEnvironment
?
DefaultOpEnvironment
or BaseOpEnvironment
, and then the fancy one should extend it? But it depends what functionality each one brings to the table.
OpEnvironmentFactory
objects you want to use, and that is pretty hard to do if you are getting them through ServiceLoader
Initializable
? I think the reason is that there are two Initializable
interfaces: one in scijava-common and one in imagej-ops. See imagej/imagej-ops#455