On 11 March 2010 15:48, Jeremy Hughes <[email protected]> wrote: > On 11 March 2010 14:59, Guillaume Nodet <[email protected]> wrote: >> 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 > > +1 there's a few JIRAs around this but not one to get rid. > >> * asm : we should embed it > > isn't this where cglib got into trouble. Adding this in just doesn't > feel very modular! > >> * org.osgi.framework.launch : no idea where this one come from, i >> can't find any reference in the whole project > > cool lets remove it > >> * 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 ? > > ok > >> >>> 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. > > +1 absolutely. I've just pulled in the Felix 'release' profile into > the Aries parent pom. As a consequence LICENSE and NOTICE files need > to be in SVN at every level. So, while adding them in at every > 'releaseable' level seems like a manageability issue, I think their > presence makes sure we remember that they are there and need to > maintained accurately.
Having said that, David did some work a few weeks back to have the LICENSE and NOTICE files from the top level module put into the built artifacts. Perhaps it would be best to provide a -project.zip only for top-level modules rather than all the sub-modules and that is what the draft download wiki page reflects at the moment. > >> * all the maven modules binary jars will all be available from the >> maven repos. Which one we advertise is a different story though. > > all the files that get installed into a local repo will end up going > to the remove repo at this rate. If there really is something that we > don't want to publish (and I'm not so convinced about testbundlea, > testbundleb and a few others), the we need to decide what to exclude. > At the moment we're heading towards publishing everything under a top > level module that we're releasing. In order for the -project.zip trick > to work (i.e. unzip the -project.zip and you can run mvn, without > having to do an svn checkout) then I think we'll need to release the > testsupport module. > > What we release to a maven repo and what we link to from a (new) Aries > download page on our web site aren't necessarily the same thing. Zoe > has started a page: > > http://cwiki.apache.org/confluence/display/ARIES/Release%20proposal I should mention that it doesn't have the uber jar as a download option at the moment. > >> * any zip we create as a binary distribution should be part of the >> build and not manually generated. > > +1 ... automation is our friend. > >> >>> >>> [1] http://www.apache.org/legal/3party.html >>> >>> Thanks, >>> Jeremy >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >
