>> Seeing as we've touched on Maven again, is anyone with some Maven experience >> able to help out with an implementation of Maven Provisioning of proxy jar >> artifacts. Seeing as everyone is starting to do this I'd like to see a >> standard way adopted. The proxy jar's can themselves depend on other Jar's >> since maven can provision those. By provisioning artefacts, it reduces the >> risk of denial of service. > > I dont think we should be concerned about this right now, furthermore, this > is generally out of scope [1] for what I think River should be focusing on > now, and for the foreseeable future. > > What would be more helpful is conventions on how developers that use River > and Maven should create their projects. We have had discussions on this in > the past (so this is mostly a review), I hope that we can agree on the > conventions, document them and eventually create a River archetype that > generates a default project structure that produces the requisite artifacts.
There are different issues being addressed here. With the current River system, I have no easy way to say, "this service's DL jars haven't been changed in while, so if you have a local copy that matches this checksum, use it and skip the download." That's was the point of having a service be able to provide a Maven (or similar) coordinate identifying the DL jar(s), possibly along with a checksum, that you need to use the service. This is orthogonal to the question of how to easily package a River service. The client should have an easy way to get at the API jars, yes, but the client will also need access to the DL jars at runtime. They shouldn't have to download the same jar files again and again. Maven has the advantage of having active development, a known and fairly straightforward repository structure, etc. so that's been proposed for part of the implementation. Regards Patrick
