So that's why we have the therapi-based thing. It's the "least bad" way we could come up with to do this.
In seriousness: I am a huge fan of dependency management systems, making things small and modular, etc., but I have to admit that there is a lot of power in dependency-free libraries, still. They are vastly simpler, because they avoid the necessary deployment complexity imposed by any dependency management system.
Or building uber-JARs?
Whatever, it's more complicated than having one JAR that is the thing.
There is a reason
ij.jar is still a single JAR after all these years. It brings a lot of downsides, but also advantages.
but I dont want to argue further :p
@/all I have published a draft of the SciJava Incubator README. It is incomplete, but still maybe useful to start grokking what the point of the scijava/incubator is. It describes motivations, requirements, and so forth, for the next Java-11-based set of SciJava libraries currently in the works.
if I may,regarding the dev process: you don't need any real "beast", with gradle would be enough to simply have just a bare repo having only build configuration files, then on the side all the major projects (scijava/scifio/imagej/fiji). All these projects have to be of course checked out to the right experimental branch and then the "beast" would simply include their build (composite build in gradle terms).
1 reply
Also, jitpack is awesome, but for simple projects, as soon as you have complicate and advanced projects then you start hitting its limitations (I created a curated list here). Moreover, jitpack builds on the first request. Our (sciview/scenery) build process is the following, you push and then you pull from the other project. At that time jitpack starts building (there is a way to build ahead, but then you cannot rely on the commit id, but you have to use
Moreover, this is a pure waste if you think about it, because the artifact is already built (also much faster) locally on your machine.
The ideal process would be to simply publish the very artifact you just build as a snapshot with a super simple versioning, ie:
-SNAPSHOT, which of course doesn't always guarantees it fetches what you are thinking). However, gradle request goes in overtime and then the synchronization gets interrupted as unresolved and you have to trigger it again.Moreover, this is a pure waste if you think about it, because the artifact is already built (also much faster) locally on your machine.
The ideal process would be to simply publish the very artifact you just build as a snapshot with a super simple versioning, ie:
${lastTag}+$numberOfCommits and then you can immediately consume somewhere else
1 reply
I currently have
src/it/discovery-test, should I put the tests in there?
So I currently have regression tests for:
- Determining the number of Ops/
OpInfos discoverable usingServiceLoader - Determining the number of OpCollections/
OpInfos discoverable usingServiceLoader - Determining the number of Ops/
OpInfos discoverable using Therapi (this number is currently zero)
Do we want a matching regression test? If so, what Ops should be tested? There are some math Ops which make sense to test, but what about adapt Ops? simplify Ops?
10 replies
Time to switch ImageJ Ops2 over to Therapi!
Will finish tomorrow
See scijava/incubator@94523aa for progress
Going to do the rebasing now
public static Iterable<Discoverer> all(Function<Class<Discoverer>, ? extends ServiceLoader<Discoverer>> func) {
return (ServiceLoader<Discoverer>) func.apply(Discoverer.class);
}
It would be slick if we could enforce broader generics on that discoverer
I'm thinking this will work?
static <T> Iterable<Discoverer> all(Function<Class<T>, ? extends ServiceLoader<T>> func) {
try {
ServiceLoader<Discoverer> d = (ServiceLoader<Discoverer>) func.apply((Class<T>) Discoverer.class);
List<Discoverer> list = d.stream().map(p -> p.get()).collect(Collectors.toList());
list.add(Discoverer.using(func));
return list;
} catch (ClassCastException e) {
return Collections.emptyList();
} catch (ServiceConfigurationError e) {
return Collections.emptyList();
}
}