On 11 March 2010 16:02, Guillaume Nodet <[email protected]> wrote: > On Thu, Mar 11, 2010 at 16: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. > > I'm not personally very fond of this scheme because it usually does > not make sense to have a source *distribution* (i.e. something that > can be build, not the source jar generated by maven) for each module.
Yeah, this makes sense. If it were me I'd want to be able to unzip the -project.zip, make changes and build it. I think we should have one -project.zip for each top level module though, not every sub module. > People interested in the source distribution want to be able to > change things. And we would still miss the parents and such. > If we release everything in one go, we should have a single source > distribution. If we release subsprojects separatly, each subproject > should have its own source distribution imho. > +1 >> >>> * 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 >> >>> * 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 >>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
