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:30:07 GMT
to summarize my other email....

On Jul 3, 2012, at 1:25 PM, Holly Cummins wrote:

> I have the work to change the group id of the util bundle from
> org.apache.aries to org.apache.aries.util ready to commit. It's a
> pretty drastic change, so it would be good to get to get more opinions
> on whether we think this is a good idea or not.

I'm -1 on this
> Opinions on whether we change the util folder to util-bundle also
> welcome, since we're currently at one +1, one -1, and one 0 on that
> one.

I'm minus a lot more than 1 on this, I haven't seen a rationale I can understand

> And, while we're collecting opinions, any +1s or -1s to overriding the
> deploy goal to prevent releasing the util-r42 and util-parent bits?

-1 on this because it won't work :-) (even though I suggested it)

IN summary I think what we have now is as good as we can produce using maven.

david jencks

> On Tue, Jul 3, 2012 at 7:04 PM, 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?
>> 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.
>> 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.
>> 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 <>
>>>>> 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