OSGi's license is Apache License Version 2. What is wrong with that?
 
--

BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
hargr...@us.ibm.com
 
 
----- Original message -----
From: Dave Cramer <davecra...@gmail.com>
Sent by: osgi-dev-boun...@mail.osgi.org
To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
Cc:
Subject: Re: [osgi-dev] building osgi for rpm's or deb's
Date: Tue, Jan 26, 2016 3:02 PM
 
Hi Tim,
 
Sorry my request was poorly stated.
 
The problem is that the OSGI licence is incompatible with REDHAT's . We already use Maven to build it. They do not allow anything to be pulled from maven repo's.
 
I was going to ask if there was a way to just re-license the interfaces, but again you would not want anyone changing them (this is their objection to your license)
 
Suggestions ?
 
Dave Cramer
 
On 26 January 2016 at 11:14, Timothy Ward <tim.w...@paremus.com> wrote:
Hi Dave,
 
I don’t really have any experience building rpms or debs, however the JDBC driver should be just another JAR/bundle, and I’m assuming that its built using Maven (the pom file for the official release in maven central seems to indicate that this is true).
 
In this case you simply need the following things:
 
  1. To package the JDBC driver as an OSGi bundle - this means that you need a few manifest headers to supply OSGi metadata. I would recommend the bnd-maven-plugin as a good way to automatically generate this metadata without having to manually maintain the list of imports (https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin)
  2. I’m not sure which OSGi interfaces you need to compile against, but I’m guessing that you’ll want the JDBC service API (for your DataSourceFactory)
 
<dependency>
    <groupId>org.osgi</groupId>
    <artifactId>org.osgi.service.jdbc</artifactId>
    <version>1.0.0</version>
</dependency>
 
and probably also the core OSGi API (assuming that you have an Activator to register the service):
 
<dependency>
    <groupId>org.osgi</groupId>
    <artifactId>org.osgi.core</artifactId>
    <version>6.0.0</version>
</dependency>
 
You may choose to use a lower version of the core API than 6 (the latest) to be compatible with older frameworks. How far back you go is up to you, but there’s probably no reason to go lower than 4.3.1 (which includes some generics fixes).
 
One final thing - make sure that all of your exports (f you have any) are properly versioned, and that your package imports have version ranges. Most people make the mistake of assuming that:
 
Import-Package: xxx.yyy.zzz;version=1.0.0
 
Means “import at version 1.0.0”. This is *not* true. An import with no upper version means “to infinity” which is a bad forward compatibility situation. A correct version range looks like:
 
Import-Package: xxx.yyy.zzz;version=“[1.0.0,2.0.0)”
 
Regards,
 
Tim
 
On 25 Jan 2016, at 14:14, Dave Cramer <davecra...@gmail.com> wrote:
Redhat is currently trying to build the PostgreSQL JDBC driver. We expose an OSGI service and require a few interfaces to be imported. 
How do other distro's handle building the dependency ?
 
Dave Cramer
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to