blueprint distro release - NOT

[Jeremy Hughes <hu...@apache.org>]

As part of cutting releases for the Blueprint bundles and the Aries
bundles it depends on I'm now staring at the blueprint-distro module.
This hasn't been released yet. The idea was for it to be a zip of the
latest functional bundles in Aries Blueprint and other Aries bundles
they depend on that aren't in Aries Blueprint. So right now that would
be:

org.apache.aries.blueprint:blueprint-distro:jar:0.4-SNAPSHOT
+- org.apache.aries.blueprint:org.apache.aries.blueprint.annotation.api:jar:0.3.2:compile
+- org.apache.aries.blueprint:org.apache.aries.blueprint.annotation.impl:jar:0.3.2:compile
|  \- org.apache.aries:org.apache.aries.util:jar:0.4:compile
+- org.apache.aries.blueprint:org.apache.aries.blueprint.api:jar:0.3:compile
+- org.apache.aries.blueprint:org.apache.aries.blueprint.cm:jar:0.3.2:compile
+- org.apache.aries.blueprint:org.apache.aries.blueprint.core:jar:0.4:compile
|  +- org.apache.aries.quiesce:org.apache.aries.quiesce.api:jar:0.3:compile
|  \- org.apache.aries.proxy:org.apache.aries.proxy.api:jar:0.4:compile
\- org.apache.aries.blueprint:org.apache.aries.blueprint.jexl.evaluator:jar:0.1.0:compile

There are a few more dependencies, outside Apache Aries which I've
pulled out here:

\- org.apache.xbean:xbean-finder:jar:3.7:compile
   +- org.apache.xbean:xbean-bundleutils:jar:3.7:compile
   \- org.slf4j:slf4j-api:jar:1.5.11:compile
\- org.apache.commons:commons-jexl:jar:2.0:compile
   \- commons-logging:commons-logging:jar:1.1.1:compile

Note: commons-jexl for example is optional.

Also, the impl bundles aren't pulled in to the distro through the use
of the maven dependency plugin. I could hand code the pom to pull them
in, but it got me thinking: really, what is the use of the distro zip.
We'd like something easy for users to download to get started writing
Blueprint bundles. IMHO we have something like that in the
samples/blog/blog-assembly module, but that of course pulls in enough
of a 'platform' to run a complete application.

So my proposal for now is I'm not going to release distro. Users will
have blog-assembly when that is released to depend on the new
Blueprint releases. I think using that as a starting point for
creating an Aries application is a better approach than creating a
distro for Blueprint that means a user has to hunt around for
non-Apache Aries dependencies.

I'd be interested in any other view on this though.

Cheers,
Jeremy

Re: blueprint distro release - NOT

[Alasdair Nottingham <no...@apache.org>]

Do we want to include the annotations stuff? I thought it was a bit
experimental?

I think we should release the distro, although I can cope with doing it
later. This was about ensuring people know which of our many bundles they
needed to do blueprint. I think this is useful and if people need more we
won't get that feedback until we do a release.

Alasdair

On 26 October 2011 09:26, Jeremy Hughes <hu...@apache.org> wrote:

> As part of cutting releases for the Blueprint bundles and the Aries
> bundles it depends on I'm now staring at the blueprint-distro module.
> This hasn't been released yet. The idea was for it to be a zip of the
> latest functional bundles in Aries Blueprint and other Aries bundles
> they depend on that aren't in Aries Blueprint. So right now that would
> be:
>
> org.apache.aries.blueprint:blueprint-distro:jar:0.4-SNAPSHOT
> +-
> org.apache.aries.blueprint:org.apache.aries.blueprint.annotation.api:jar:0.3.2:compile
> +-
> org.apache.aries.blueprint:org.apache.aries.blueprint.annotation.impl:jar:0.3.2:compile
> |  \- org.apache.aries:org.apache.aries.util:jar:0.4:compile
> +-
> org.apache.aries.blueprint:org.apache.aries.blueprint.api:jar:0.3:compile
> +- org.apache.aries.blueprint:org.apache.aries.blueprint.cm:
> jar:0.3.2:compile
> +-
> org.apache.aries.blueprint:org.apache.aries.blueprint.core:jar:0.4:compile
> |  +- org.apache.aries.quiesce:org.apache.aries.quiesce.api:jar:0.3:compile
> |  \- org.apache.aries.proxy:org.apache.aries.proxy.api:jar:0.4:compile
> \-
> org.apache.aries.blueprint:org.apache.aries.blueprint.jexl.evaluator:jar:0.1.0:compile
>
> There are a few more dependencies, outside Apache Aries which I've
> pulled out here:
>
> \- org.apache.xbean:xbean-finder:jar:3.7:compile
>   +- org.apache.xbean:xbean-bundleutils:jar:3.7:compile
>   \- org.slf4j:slf4j-api:jar:1.5.11:compile
> \- org.apache.commons:commons-jexl:jar:2.0:compile
>   \- commons-logging:commons-logging:jar:1.1.1:compile
>
> Note: commons-jexl for example is optional.
>
> Also, the impl bundles aren't pulled in to the distro through the use
> of the maven dependency plugin. I could hand code the pom to pull them
> in, but it got me thinking: really, what is the use of the distro zip.
> We'd like something easy for users to download to get started writing
> Blueprint bundles. IMHO we have something like that in the
> samples/blog/blog-assembly module, but that of course pulls in enough
> of a 'platform' to run a complete application.
>
> So my proposal for now is I'm not going to release distro. Users will
> have blog-assembly when that is released to depend on the new
> Blueprint releases. I think using that as a starting point for
> creating an Aries application is a better approach than creating a
> distro for Blueprint that means a user has to hunt around for
> non-Apache Aries dependencies.
>
> I'd be interested in any other view on this though.
>
> Cheers,
> Jeremy
>



-- 
Alasdair Nottingham
not@apache.org