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.
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. 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? On Tue, Jul 3, 2012 at 7:04 PM, Holly Cummins <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> >>>> https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.util-parent-1.0.0/ >>>> https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.api-1.0.0/ >>>> >>>> Instructions for verifying the release are at >>>> http://aries.apache.org/development/verifyingrelease.html. >>>> Alternately, cut and paste the following to run a full check: >>>> >>>> wget --no-check-certificate >>>> https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh >>>> chmod a+x verify_staged_release.sh >>>> ./verify_staged_release.sh 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,https://repository.apache.org/content/repositories/orgapachearies-287/. >>>> >>>> Links to the *.zip files for each module are provided below. >>>> >>>> https://repository.apache.org/content/repositories/orgapachearies-287/org/apache/aries/blueprint/org.apache.aries.blueprint.api/1.0.0/org.apache.aries.blueprint.api-1.0.0-source-release.zip >>>> https://repository.apache.org/content/repositories/orgapachearies-287/org/apache/aries/org.apache.aries.util-parent/1.0.0/org.apache.aries.util-parent-1.0.0-source-release.zip >>>> >>>> The RAT and IANAL build checks passed. >>>> >>>> The vote will be open for 72 hours. >>>> >>>> [ ] +1 >>>> [ ] 0 >>>> [ ] -1 >>
