aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Date Thu, 05 Jul 2012 14:34:24 GMT

On Jul 5, 2012, at 10:01 AM, Holly Cummins wrote:

> On Thu, Jul 5, 2012 at 2:51 PM, Jeremy Hughes <jpjhughes@gmail.com> wrote:
>> On 3 July 2012 18:39, David Jencks <david_jencks@yahoo.com> 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 <holly.k.cummins@googlemail.com>
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
>>> 


Mime
View raw message