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
Also3, Java 17 is out, take the chance and use that last LTS as base developing jdk, providing a
-jdk8 variant (Maven should have something similar but I dont know the term for that) for retro-compatibility
14 replies
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();
}
}I do think it would be fun to write a
Discovererbacked by classgraph, though.
Right, yeah. I just meant that it would not fix the problem we were talking about yesterday
public class ClassGraphDiscoverer implements Discoverer {
@Override
public <T> List<T> discover(Class<T> type) {
List<T> instances = new ArrayList<>();
try (ScanResult scanResult = new ClassGraph().enableAllInfo().scan()) {
ClassInfoList impls = scanResult.getSubclasses(type);
for (ClassInfo impl : impls) {
try {
Class<?> c = impl.loadClass();
if (!type.isAssignableFrom(c))) continue; // Not an implementation of the requested type.
T instance = (T) c.newInstance();
instances.add(instance);
}
catch (IllegalArgumentException exc) {
// NB: Could not load the class.
// TODO: Log the exception.
}
catch (ExceptionTypesThatNewInstanceThrows exc) {
// NB: Could not instantiate the class.
// TODO: Log the exception.
}
}
}
return instances;
}
}
Note that the above is completely untested. @elect86 Let us know if there is a better approach to using classgraph for this. In particular, I'm concerned that every call to
discover may rescan the classpath (‽).
Another concern is that
getSubclasses may return abstract layers, not only "leaf class" implementations. So probably more checking is needed here before trying to instantiate each class. Maybe also checking for a no-args constructor? I dunno.