river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafał Krupiński <rafal.krupin...@sorcersoft.com>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Tue, 25 Feb 2014 20:11:07 GMT
Dnia 2014-02-25, wto o godzinie 18:36 +0100, Michal Kleczek pisze:
> Hmm... I don't think it is an implementation detail - codebase 
> annotations must be understood by every client - so the format becomes a 
> part of the spec.
> For example Maven based naming 
> (groupId:artifactId:version:classifier:version) is incompatible with 
> Eclipse p2 (MANIFEST.MF OSGI metadata - in practice I would say it would 
> be bundleId:version or bundleId:version-range).
> Additionally - just name/version based artifact identification is not 
> enough - I would much rather see something like "strong names" from .NET 
> where signature is part of the identifier.
> Besides... Maven based provisionning requires every party to agree on a 
> set of common repositories.
> Ideal solution would be to decouple the client from the "how" code is 
> downloaded. Not having this is one of the problems with current River 
> architecture - all have to have http and httpmd URL handlers installed.
> This decoupling could be achieved if codebase annotations were objects - 
> that was my proposal discussed some time ago. It allows a service to 
> provide clients with "code downloaders" as annotations.

Another solution that should work with current River would be to publish
URL handlers as fat proxies. Only those handlers would need to be
published with http codebase. Clients could resolve the handlers with
URLStreamHandlerFactory implementation.


View raw message