Is it good to have lot of .jars in seco/core/lib in source tree ?

[ponyatov]

I see lot of .jars in source tree.
.jar is derivative file type, like executable files and compiled resources -- is it good to have them in source tree ?

I understand this files present in binary release archive, GitHub has feature to plug any files to release, into seco-<relese>.zip or as separate seco-libs-<relese>.zip

And in seco/lib source I think it is good to have only wget/curl script to download .jars from external hosts, or (in case of HDGB) build it from sources in place.

[bolerio]

@ponyatov I agree, it's not ideal. But it does make life easier when you just want to clone the project and build it without having to track down dependencies. This project started before Maven took over the world. Now, it would be a good idea to Maven-ize it and perhaps, given the nature of the project, to actually remove all external dependencies and bootstrap just from the JDK.

I'm not even sure all the libs used in the project are in the Maven central. If some are not, it would be very annoying for someone to have to track them down. We'd have to host them somewhere reliable and if we do that, github is as good a place as any.

To reiterate, I think what we should be shooting for is reduce the external jars to a minimum, perhaps just the HGDB ones, mavenize the project and pull the rest from a Seco network that we should setup for dependencies. One thing I'd like to experiment with is managing dependencies at a class level, fine-grained, which is the direction of Seco. And for that, the way I'd see it is a jar file would be unarchived and each compiled class would be stored in the graph, as a blob. When a class is needed, only the necessary dependencies would be dynamically loaded and resolved class by class, rather than jar library by jar library.

This sort of experiment is probably not such a big project! More than a week-end project, but not a multi-month affair IMHO.