On Jul 5, 2012, at 10:01 AM, Holly Cummins wrote: > On Thu, Jul 5, 2012 at 2:51 PM, Jeremy Hughes <[email protected]> wrote: >> On 3 July 2012 18:39, 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. >> >> 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.
That would break the r42 stuff which needs to be compiled against a 4.2 framework (without generics) so it will work against a 4.2 framework. If we could compile everything against a 4.3 framework we wouldn't be in this mess in the first place :-) > 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 > sufficient. It's possible to do some magic with the shade plugin to glue all the sources together, but I'm not enthusiastic about figuring out how to make it work reliably. I guess the real solution (long term) is to fix the maven-bundle-plugin to create source jars containing the sources for the classes it puts in the main bundle. I'm ok with the current situation, so even adding a better javadoc jar would be fine too. thanks david jencks > > Holly > >>> >>> 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 >>>
