river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Tue, 25 Feb 2014 18:18:00 GMT
On Tue, Feb 25, 2014 at 12:36 PM, Michal Kleczek <michal.kleczek@xpro.biz>wrote:

> 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.
>

Fair enough, it does need to be part of a specification.


>
> 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 provisioning requires every party to agree on a set
> of common repositories.
>

Not necessarily true. If there is no context for a repository in the
annotation then yes. An example where there is context is in the following
URL:

artifact:groupId/artifactId/version[/type[/classifier]][;
repository[@repositoryId]]


> 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.
>

This. I like this. How would this work, would it be an Entry, an attribute
of the service (perhaps similar to the ServiceUI factory?).

Regards

Dennis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message