On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <[email protected]> wrote: > Thanks Guillaume for creating the uber bundle for application. I can > see it is a merge of api, management, runtime and utils which is also, > really the minimum set you could use in a runtime. It happens to be a > transitively closed set w.r.t dependencies which is nice for > consumers.
Yeah, I would love to add the other optional bits, but I'm stuck because those really should be optional and blueprint has no way to handle that (see the other discussion on the dev list about this exact problem). > > The blueprint uber bundle isn't transitively closed - it needs asm, > cglib, osgi compendium, slf4j, > Import-Package: javax.xml.parsers,javax.xml.transform,javax.xml.transf orm.dom,javax.xml.transform.stream,javax.xml.validation,net.sf.cglib. proxy;resolution:=optional;version="[2.1,3)",org.objectweb.asm;resolu tion:=optional;version="[3.1,4)",org.objectweb.asm.commons;resolution :=optional;version="[3.1,4)",org.osgi.framework;version="[1.5,2)",org .osgi.framework.launch;version="[1.0,2)",org.osgi.service.cm;version= "[1.2.0,2.0.0)",org.osgi.service.event;resolution:=optional;version=" [1.2,2)",org.osgi.service.framework;resolution:=optional;version="[1. 0,2)",org.osgi.util.tracker;version="[1.4,2)",org.slf4j;version="[1.5 ,2)",org.w3c.dom,org.xml.sax Beyong the core JRE and osgi packages, we have: * cglib : we should get rid of that one * asm : we should embed it * org.osgi.framework.launch : no idea where this one come from, i can't find any reference in the whole project * org.osgi.service.cm : we should try to make it optional, but we'll have the same problem as for applications * org.osgi.service.event;resolution:=optional : it's optional and ok * org.osgi.service.framework;resolution:=optional : that's for composite bundles, given it's optional it's ok * org.osgi.util.tracker : we may want to embed it * org.slf4j : we discussed that and decided not to use a wrapper, so we could either import / export it or leave it as a mandatory import We should really get rid of cglib asap. cglib itself uses asm and we have our own layer on top of asm. I don't think we should have a mandatory import on org.osgi.service.cm, so either find a way to make it optional or exclude it ? > Which brings me on to how we're going > to point users to the dependencies they need in order to get started > and in particular how this looks on our download page. We could: > 1) link to the official download URL for each of the dependencies as > well as link to the uber jar in the Aries dist dir (but users have to > download them all individually), > 2) release a zip separate to the uber bundle containing all the > dependencies and link to that on our downloads page, as well as a link > to the uber jar in the Aries dist dir, > 3) #2 but include the uber jar in that zip as well, > 4) release sample with all the dependencies to run the sample, link to > that and the uber jar which are both stored in Aries dist dir > > Also include a zip of the mini-bundles. > > #2 & #4 mean we would be releasing a zip containing jars not developed > at Apache, so we need do of course need to adhere to the third party > licensing policy [1] > > I favour #4. > > What do you all think? Three points i'd like to stress: * we need source distributions for everything we release because this *is* the official release. * all the maven modules binary jars will all be available from the maven repos. Which one we advertise is a different story though. * any zip we create as a binary distribution should be part of the build and not manually generated. > > [1] http://www.apache.org/legal/3party.html > > Thanks, > Jeremy > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
