aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Runtime dependencies for our released artifacts
Date Thu, 11 Mar 2010 14:59:08 GMT
On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <> 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

> 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

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
  * : 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, 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]
> Thanks,
> Jeremy

Guillaume Nodet
Open Source SOA

View raw message