river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wright <pdoubl...@gmail.com>
Subject Re: Closing out release 2.2.0
Date Fri, 27 Aug 2010 16:25:51 GMT
>> 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
> 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.


View raw message