Mailing-List: contact aries-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: aries-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of gnodet@gmail.com designates
 209.85.220.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=gcwdFFqUTF7A1a/kkphecV5sljWNd/Pb1ll1X5AosrjqMIyWRV/d72/3kYFhPOLfkd
         sTZEzoAooknMFjQKLEBHraxR4EimW5VeGGbmadViay6WRe8ENCwT9OsQpbQaO2avTsC2
         7sIMXKhT2txbAjVCbWcYu+piZgOQ5gslnKTj0=
MIME-Version: 1.0
In-Reply-To: <adbf02b11003110536w58f257ffpe90eda4d4f3111f9@mail.gmail.com>
References: <adbf02b11003110536w58f257ffpe90eda4d4f3111f9@mail.gmail.com>
Date: Thu, 11 Mar 2010 15:59:08 +0100
Message-ID: <b23ecedc1003110659n433a8a26t22e75344a85dda67@mail.gmail.com>
Subject: Re: Runtime dependencies for our released artifacts
From: Guillaume Nodet <gnodet@gmail.com>
To: aries-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 11, 2010 at 14:36, Jeremy Hughes <hughesj@apache.org> 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