aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holly Cummins <>
Subject Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Date Thu, 05 Jul 2012 14:01:09 GMT
On Thu, Jul 5, 2012 at 2:51 PM, Jeremy Hughes <> wrote:
> On 3 July 2012 18:39, 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.
> Yes, that is a difference. Like you I'd prefer to not release util-42.

The only way I can see to make this work is to copy the util-r42
source into the util project as a pre-compile step, so that the
util-r42 project is only there to check things compile. I'm not sure
the slight reduction in complexity of the released artefacts justifies
the significant increase in build complexity. I do have build changes
so that the javadoc for the util bundle includes the javadoc for
everything, so that the externals are complete, and I'd argue this is


>> 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