On Tue, Feb 25, 2014 at 12:36 PM, Michal Kleczek <michal.klec...@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
