Hi Tobi, On Fri, 6 Dec 2013, Tobias Pietzsch wrote:
> As far as I see it, a big part of scijava-common is to be a dependency > injection framework. That is just part of it, but yes, it is a part. > It can provide an application context, it can harvest annotations from > my classes, it can even modify my eclipse projects. It can add a file to your Eclipse project that works around an incorrect interpretation of the Java specification, yes: annotation processing is only performed correctly by Eclipse if you add that file. > This is exactly the right thing to use if you are building an > application. And if you are building extensible frameworks with extension points, such as: segmentation and tracking plugins for TrackMate, feature plugins for the Trainable Segmentation, generic extensions for TrakEM2, commands for the 3D Viewer, and yes, also operations for scijava-ops. Extensibility is something that a lot of projects related to Fiji had to reinvent due to lack of a base library providing a common extensibility framework. With scijava-common, there is no more need to do so. I have to admit that it gets hard for me to accept that we are contesting about reusability here. Reusable classes in a library that weighs in with a whopping two hundred kilobytes. If you insist on not having such a dependency in imglib2-core, fine, I cannot change your mind, I can only point out that imglib2-core will have to reinvent at least a large part of scijava-common's functionality, one by one, and as ImgLib2 will be used for the most part in projects that already rely at least transitively on scijava-common (including your own big data viewer), that will be a true duplication. I rest my case because there is nothing else I can do, really. Dscho _______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
