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 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.parseinstead 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
@ctrueden I am in agreement that the
vX incarnation is probably the right decision
But it might seem strange if
org.scijava.v3.parse is part of the same "generation" as org.scijava.ops.engine, org.scijava.discovery, etc.
Is there a convention for
v3 coming between the group and artifact names? Because org.scijava.parse.v3 might look better
I think it just comes down to whether the version emphasis should be on SciJava, or on each component (i.e. Parse)
So we won't have
org.scijava.ops at all... only org.scijava.v3.ops. We could start at v1 though if you prefer. I don't feel strongly.
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 from v1 to v2, or even v3 to v4.
And obnoxiously, the artifactIds also need to incorporate that... so e.g.
scijava-v3-ops, scijava-v3-parse, and so on.
We could even name the repo
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 fromv1tov2, or evenv3tov4.
Does this scheme allow us to iterate on a particular component? Do you see us ever wanting to?
I just checked the doc where this is written up, and the thinking had evolved past what I'm saying above.
org.scijava.ops2 :arrow_right: org.scijava.ops3.
I forgot about that, sorry...
This is the equivalent of
org.scijava.v2.ops :arrow_right: org.scijava.v3.ops
And then the artifacts are named
scijava-ops2 and scijava-ops3 respectively.
I think we decided to do it this way because it still addresses the same issue (class name clashes across major versions), but is more in line with how popular OSS projects like Apache Commons do things.
But we do still need to decide how to name the packages being pulled out of SJC2, then.
E.g. since
org.scijava.parse is taken, we have to call it org.scijava.parse2, with artifactId scijava-parse2.
And since we want to do monoversioning of core scijava components now... are we going to allow heterogeneous generation numbers?
The monoversioning doc is here but it's pretty barebones right now.
I suppose the central idea is that this
OpEnvironment will do no discovery...
BasicOpEnvironment?
If anything, I'd say the basic one should be
DefaultOpEnvironment or BaseOpEnvironment, and then the fancy one should extend it? But it depends what functionality each one brings to the table.
@gselzer Could you please do a pass over the Road to SciJava Ops project board? I see issues in "To do" that I believe you have now tackled or have WIPs tackling. And there are issues in "In Progress" that are not currently assigned to you or anyone. All issues in "In Progress" should have at least one assignee. You can also drag-and-drop cards in order of priority, so that things at the top get looked at first, and things you feel should be saved till later (December) go more toward the bottom.
2 replies
Because at the end of the day, you are going to want to choose which of those
OpEnvironmentFactory objects you want to use, and that is pretty hard to do if you are getting them through ServiceLoader
5 replies
Here are slides from a hopefully-not-too-technical overview talk I gave today about SciJava Ops / ImageJ Ops 2.
Hey @gselzer! Remember how you said ops weren't being properly initialized in napari-imagej, even though they implement
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
7 replies
4 replies