On Aug 27, 2010, at 1225PM, Patrick Wright wrote: >>> 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 point here is to first provide conventions for developers that use Maven to be able to easily create and start services that use River. > 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. And I was all for that when we discussed it, and I dont think it needs to be part of closing out release 2.2.0.
