On Thu, Jul 5, 2012 at 3:34 PM, David Jencks <[email protected]> wrote:
[snip] >> 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 :-) Ah, thanks for clarifying. I wasn't sure if the r42 stuff needed to be *able* to compile against a 4.2 framework, or needed to actually *be* compiled against 4.2. Luckily, I had pretty much no enthusiasm for implementing my proposed solution. :) [snip] > > 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 had a play with the shade plugin but I didn't get very far before trying to find another solution. :) > > I'm ok with the current situation, so even adding a better javadoc jar would > be fine too. I think I now have the better javadoc being built, and so what we have is that the contents of the javadoc jar lines up with the user-consumable util bundle, whereas the source zips mirror what's in svn. This seems relatively neat to me, so I'll respin the release. Cheers, Holly > >> >> 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 >>>> >
