aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Date Tue, 03 Jul 2012 20:27:57 GMT

On Jul 3, 2012, at 11:04 AM, Holly Cummins wrote:

> Hi David,
> I think there are two relatively independent issues. One is how we
> name the util folder - should it be util, for consistency with the
> bundle symbolic name, or util-bundle, to make it clear it's an
> aggregator?

I don't understand.  There's a util pom project, containing a util-r42 _jar_ (not bundle)
project and a util bundle project.  The latter two both have code in them.  The util bundle
project uses bnd (through the maven-bundle-plugin) to pull in all the classes from the util-r42

I think the bundle output from this should have symbolic name and artifactId org.apache.aries.util.
 I don't much care what anything else is named and I don't see why anyone else would either.
 I do think renaming the util pom project artifactId from org.apache.aries.util-parent to
just util will be very confusing with the org.apache.aries.util bundle project.  Since this
case is not at all parallel with all the multi-bundle setups (there is only one output bundle)
I don't have a problem with an odd artifactId for the file system parent.

So that's what I think.  I don't understand which projects you are thinking of changing.

> The other issue is the group id of the various util artefacts. It
> looks like the group id was forgotten from the util pom, because it's
> the only bundle we have whose group id is org.apache.aries rather than
> org.apache.aries.somecomponent. So I think we do need to change the
> group id of the bundle, just to bring it in line with our conventions
> for 'normal' bundles.

I don't care much about this.  I don't see the point in changing it.  I don't think we'll
ever have more than one aries-wide util bundle so I have no problem with the org.apache.aries
groupId.  All the other more specific groupIds have lots of bundles under them, this is unlikely
to ever have more than one.  My feeling is that consistency with past releases is more important
than what I regard as specious consistency of groupIds.  

> Overriding the deploy to ensure the parent or r42 bundles aren't
> inadvertently consumed is a good idea. I think that and the comments
> on the util poms would be sufficient to ensure that it's clear that
> the util bundle is produced by aggregating util and util-r42.

Thinking about this more it won't work.  We need to publish the util-parent pom so you can
find the scm info from published artifacts, even if it's not navigateable from the bundle
pom.  And we probably want at least a source jar from the util-r42 jar project and trying
to only deploy the source is way too much work.

david jencks

> Holly
> On Tue, Jul 3, 2012 at 6:39 PM, David Jencks <> wrote:
>> WRT util, I disagree.  There's only one real output bundle from the util goo, org.apache.aries:org.apache.aries.util.
 The util-42 and util-parent are goo necessary (AFAICT) to build against 2 osgi framework
levels but neither one should be released.  If we do anything it should be to override the
deploy plugin in the util-parent and util-42 modules to skip deploy.  I don't see a need to
change the groupId or artifactId of the util bundle.
>> util is completely different from blueprint where the "bundle" artifact contains
a lot of stuff all of which is intended to also be available separately.  The util-42 artifact
is compoletely useless by itself and should not be released.
>> thanks
>> david jencks
>> On Jul 3, 2012, at 9:51 AM, Jeremy Hughes wrote:
>>> The util modules look odd. trunk/util used to be a single module with
>>> no sub-modules and produced a single bundle. This is the first time
>>> we're trying to release util since it changed to a multi-bundle
>>> project. It hasn't followed the pattern of the rest of Aries and so
>>> since this is a 1.0 release I think we should get it right. e.g.
>>> org.apache.aries.util-parent should be groupId org.apache.aries.util
>>> artifactId util.
>>> Blueprint has blueprint/blueprint-bundle which outputs a bundle with
>>> symbolic name org.apache.aries.blueprint. blueprint-bundle pulls
>>> together content from multiple other sibling modules. Also, the
>>> blueprint bundle has:
>>> <groupId>org.apache.aries.blueprint</groupId>
>>> <artifactId>org.apache.aries.blueprint</artifactId>
>>> So, I'm thinking we should have util/util-bundle with BSN
>>> org.apache.aries.util and that can pull together content from util-42
>>> as it does today. OK, it's a bit different to blueprint because
>>> blueprint-bundle is *just* about pulling together content from other
>>> sub-modules. Along with this set the groupId to be
>>> org.apache.aries.util and the artifactId to the same (that's how we do
>>> it in blueprint) ... I appreciate this is a change to the maven
>>> groupId but the BSN does stay the same.
>>> Another thing is the javadoc. It would be good to have a single
>>> javadoc jar but the more I look at it, the more I think, this is just
>>> a nit.
>>> Jeremy
>>> On 29 June 2012 14:46, Holly Cummins <> wrote:
>>>> I've staged a release candidate for the Aries 1.0.0 util and
>>>> blueprint.api bundles. The modules are staged and tagged in
>>>> Instructions for verifying the release are at
>>>> Alternately, cut and paste the following to run a full check:
>>>> wget --no-check-certificate
>>>> chmod a+x
>>>> ./ 287 mytempdirectory 2>&1 | tee verifyresults.txt
>>>> grep FAIL verifyresults.txt
>>>> grep ERROR verifyresults.txt
>>>> Failures are reported since there are no SHAs for the
>>>> archetype-catalog.xml file in the repository, but I believe this is
>>>> acceptable (and I can update the script to filter these out if
>>>> everyone else agrees).
>>>> Artifacts are in one staged
>>>> repo,
>>>> Links to the *.zip files for each module are provided below.
>>>> The RAT and IANAL build checks passed.
>>>> The vote will be open for 72 hours.
>>>> [ ] +1
>>>> [ ]  0
>>>> [ ] -1

View raw message