Re: OSGi

bndtools eclipse plugin supports semantic versioning. Please refer the below links http://bndtools.org/ http://bnd.bndtools.org/chapters/170-versioning.html http://blog.osgi.org/2013/09/baselining-semantic-versioning-made-easy.html On Thu, Jan 26, 2017 at 10:04 AM, Bharath Kumar

Re: OSGi

OSGI has already recommended about versioning the package (semantic versioning). https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf OSGI follows a specific version format (major.minor.micro.qualifier). As the paper suggested, consumer will not be impacted if there are no changes in

Re: OSGi

This would be a DHCP like lease scheme. Gregg > On Jan 25, 2017, at 7:30 PM, Michał Kłeczek (XPro Sp. z o. o.) > wrote: > > I also think about adding leasing to the scheme. > If CodeBaseModule can be leased (and the client is capable of handling > declines of lease

Re: OSGi

Version ids on jar file names create proper versioning of codebases. So, you can deploy a new service with a well known interface and a different jar file with a different name (version number or some other part of the URL different) and you get versioning of URLs. You’ll get a new

Re: OSGi

I also think about adding leasing to the scheme. If CodeBaseModule can be leased (and the client is capable of handling declines of lease renewals) - it would be quite straightforward to implement auto-upgrade: the lease for a module "mymodule" ver 1.1 expires and you have to ask the code

Re: OSGi

Unfortunatelly this is not that easy - the assumption that "the same bundle is going to be resolved in the same way in another OSGI container" is false. Not only the containers must share common provisioning infrastructure (single view of the names) but - most importantly - the particular

Re: OSGi

So for a client and a service to be able to communicate they must agree on a common set of interchangeable CodeRepositories that would allow them to have a common understanding of names. In other words - to be able to work - any party first has to contact a CodeRepository that can authenticate

Re: OSGi

  So lets say for argument sake, that we've got River "bundles" that are annotated with package imports (dependencies) and exports. Using Bharath's proposed 3 bundle nomenclature for services... Lets say that a third party services defines a service api in a bundle.   Service api must only

Re: OSGi

Honestly - since I am fixed ( :-) ) on having mobile code treated as any other object - I see it something like: interface CodeBaseModule { ClassLoader createLoader() throws AnyImportantException; } interface CodeRepository { CodeBaseModule getCodeBaseModule(String name, Version version);

Re: OSGi

codebase identity So River codebase identity is currently any number of space delimited RFC 3986 normalised URI strings. httpmd uses a location filename and message digest. But should location be part of identity?  How can you relocate a codebase once remote objects are deployed? OSGi and

Re: OSGi

I haven't been aware of ObjectSpace Voyager. I just briefly looked at it and it seems like it is based on Java 1.x (ancient beast) and - as I understand it - the issues you describe are mainly caused by having only a single class name space (single ClassLoader). But sending IMHO class bytes