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 16:02:44 GMT
On Thu, Mar 11, 2010 at 16:48, Jeremy Hughes <> wrote:
> On 11 March 2010 14:59, Guillaume Nodet <> wrote:
>> 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
>> 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.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)",;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
>>  * : 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 ?
> 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.
  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.

>>  * 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 trick
> to work (i.e. unzip the 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:
>>  * any zip we create as a binary distribution should be part of the
>> build and not manually generated.
> +1 ... automation is our friend.
>>> [1]
>>> Thanks,
>>> Jeremy
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog:
>> ------------------------
>> Open Source SOA

Guillaume Nodet
Open Source SOA

View raw message