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 <bharathkuma...@gmail.com> wrote: > 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 major version. > For example, adding a method to a java interface will not impact > consumers. But it affects producers. > In this case, we will increment minor version. > > If we remove a method from interface, it affects both consumers and > providers. > In this case, we need to increment the major version. > > > For the POC, I added a class "net.jini.lookup.entry.ClassVersion" ( Entry > object), which is available in org,apache,river bundle. > I have followed the below steps before registering the service and lookup > a service. > > *service provider side* > > Before registering the river service, package version of the exported > classes are calculated. > ClasVersion entries with major,minor,micro,qualifier are created for each > of the exported class. > These entries are added to ServiceItem's attributeSets. > > Please refer the following classes in bootstrap bundle.. > org.apache.river.bootstrap.service.internal.RiverServiceAdvertiser > > > *Service consumer side* > > Before we lookup services based on ServiceTemplate object , we calculate > the package version of service interface classes (serviceTypes). We create > ClassVersion entry object with calculated major version. > > Reggie can return correct compatible proxies to the client based on these > entry objects. > > Please refer the below class in bootstrap bundle. > org.apache.river.bootstrap.client.internal.ServiceTemplateManager > > > > Thanks & Regards, > Bharath > > > > > > > On Thu, Jan 26, 2017 at 7:34 AM, Gregg Wonderly <ge...@cox.net> wrote: > >> 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.) < >> michal.klec...@xpro.biz> 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 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 server for a new CodeBaseModule - which in >> turn could return a newer patched version of it. >> > >> > Cheers, >> > Michal >> > >> > Michał Kłeczek (XPro Sp. z o. o.) wrote: >> >> 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 itself as a particular principal. The >> issue is that to find the CodeRepository one needs to communicate with >> ServiceRegistrar. And to communicate with ServiceRegistrar you need a >> CodeRepository!!!. So there needs to be some bootstrapping in place: >> >> - either ServiceRegistrar and CodeRepository constitute as single >> entity >> >> - there is a bootstrap well known CodeRepository (Maven central?) - >> its implementation is based on a well known URL and its implementation code >> is shipped with the framework. >> >> >> >> Thanks, >> >> Michal >> >> >> >> Michał Kłeczek (XPro Sp. z o. o.) wrote: >> >>> 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); >> >>> boolean isSameNamespace(CodeRepository other); >> >>> } >> >>> >> >>> class NamedCodeBase { >> >>> String name; Version version; >> >>> CodeRepository repository; >> >>> boolean equals(Object other) { //check name, version and repo } >> >>> } >> >>> >> >>> Now the question is about the implementation of "isSameNamespace". >> Since the protocol(s) to access code repository might differ (and there >> might be multiple available at the same time), location based equality >> won't work (although is the easiest to implement). My rough idea is for the >> CodeRepository to be able to authenticate as any of a set of Principals ( >> ie. satisfy the ServerMinPrincipal constraint ). Two CodeRepository >> instances are interchangeable if intersection of their principal sets is >> non-empty. >> >>> >> >>> At first I thought about having a global naming scheme - then >> cryptographic hash would constitute the part of the name. But that would >> make names obscure and difficult to remember and write by hand. >> >>> So I came up with an idea to abstract it away - according to "all >> problems in CS can be solved by introducing another level of indirection" :) >> >>> >> >>> Thanks, >> >>> Michal >> >>> >> >>> Peter wrote: >> >>>> 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 Maven use a name and version to identify a codebase. >> >>>> >> >>>> Might we also need codebase signers (if any) to be part of identity? >> >>>> >> >>>> If no, why not and if yes why? >> >>>> >> >>>> Regards, >> >>>> >> >>>> Peter. >> >>>> >> >>>> Sent from my Samsung device. >> >>>> >> >>>> Include original message >> >>>> ---- Original message ---- >> >>>> From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz> >> <mailto:michal.klec...@xpro.biz> >> >>>> Sent: 26/01/2017 08:30:58 am >> >>>> To: d...@riverapache.org <mailto:d...@riverapache.org> >> >>>> Subject: 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 in-band is not necessary (nor good). >> >>>> >> >>>> What is needed is: >> >>>> 1. Encoding dependency information in codebases (either in-band or by >> >>>> providing a downloadable descriptor) so that it is possible to >> recreate >> >>>> proper ClassLoader structure (hierarchy or rather graph - see below) >> on >> >>>> the client. >> >>>> 2. Provide non-hierarchical class loading to support arbitrary object >> >>>> graph deserialization (otherwise there is a problem with "diamond >> >>>> shaped" object graphs). >> >>>> >> >>>> A separate issue is with the definition of codebase identity. I guess >> >>>> originally Jini designers wanted to avoid this issue and left it >> >>>> undefined... but it is unavoidable :) >> >>>> >> >>>> Thanks, >> >>>> Michal >> >>>> >> >>>> Gregg Wonderly wrote: >> >>>>> That’s what I was suggesting. The code works, but only if you put >> the required classes into codebases or class paths. It’s not a problem >> with mobile code, it’s a problem with resolution of objects in mobile code >> references. That’s why I mentioned ObjectSpace Voyager. It automatically >> sent/sends class definitions with object graphs to the remote VM. >> >>>>> >> >>>>> Gregg >> >>>>> >> >>>>>> On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. o.)< >> michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> wrote: >> >>>>>> >> >>>>>> The problem is that we only support (smart) proxies that >> reference only objects of classes from their own code base. >> >>>>>> We do not support cases when a (smart) proxy wraps a (smart) >> proxy of another service (annotated with different codebase). >> >>>>>> >> >>>>>> This precludes several scenarios such as for example "dynamic >> exporters" - exporters that are actually smart proxies. >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Michal >> >>>>>> >> >>>>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >> >> > >> >> >
