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
wrote:
> 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 ma
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 renewals) - it would be qui
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 URLClassLoa
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 serve
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
wirin
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 i
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 chang
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);
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 Mav
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
11 matches
Mail list logo
