You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <hu...@apache.org> on 2012/07/03 18:51:25 UTC
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
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 <ho...@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
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by Holly Cummins <ho...@googlemail.com>.
On Thu, Jul 5, 2012 at 3:34 PM, David Jencks <da...@yahoo.com> 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 <ho...@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
>>>>
>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by David Jencks <da...@yahoo.com>.
On Jul 5, 2012, at 10:01 AM, Holly Cummins wrote:
> On Thu, Jul 5, 2012 at 2:51 PM, Jeremy Hughes <jp...@gmail.com> wrote:
>> On 3 July 2012 18:39, David Jencks <da...@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 <ho...@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
>>>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by Holly Cummins <ho...@googlemail.com>.
On Thu, Jul 5, 2012 at 2:51 PM, Jeremy Hughes <jp...@gmail.com> wrote:
> On 3 July 2012 18:39, David Jencks <da...@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. 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.
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 <ho...@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
>>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by Jeremy Hughes <jp...@gmail.com>.
On 3 July 2012 18:39, David Jencks <da...@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.
>
> 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 <ho...@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
>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by David Jencks <da...@yahoo.com>.
to summarize my other email....
On Jul 3, 2012, at 1:25 PM, Holly Cummins wrote:
> 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.
I'm -1 on this
>
> 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.
I'm minus a lot more than 1 on this, I haven't seen a rationale I can understand
>
> 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?
-1 on this because it won't work :-) (even though I suggested it)
IN summary I think what we have now is as good as we can produce using maven.
thanks
david jencks
>
> On Tue, Jul 3, 2012 at 7:04 PM, Holly Cummins
> <ho...@googlemail.com> 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 <da...@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.
>>>
>>> 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 <ho...@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
>>>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by Holly Cummins <ho...@googlemail.com>.
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
<ho...@googlemail.com> 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 <da...@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.
>>
>> 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 <ho...@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
>>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by David Jencks <da...@yahoo.com>.
On Jul 3, 2012, at 11:04 AM, Holly Cummins 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?
I don't understand. There's a util pom project, containing a util-r42 _jar_ (not bundle) project and a util bundle project. The latter two both have code in them. The util bundle project uses bnd (through the maven-bundle-plugin) to pull in all the classes from the util-r42 project.
I think the bundle output from this should have symbolic name and artifactId org.apache.aries.util. I don't much care what anything else is named and I don't see why anyone else would either. I do think renaming the util pom project artifactId from org.apache.aries.util-parent to just util will be very confusing with the org.apache.aries.util bundle project. Since this case is not at all parallel with all the multi-bundle setups (there is only one output bundle) I don't have a problem with an odd artifactId for the file system parent.
So that's what I think. I don't understand which projects you are thinking of changing.
>
> 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.
I don't care much about this. I don't see the point in changing it. I don't think we'll ever have more than one aries-wide util bundle so I have no problem with the org.apache.aries groupId. All the other more specific groupIds have lots of bundles under them, this is unlikely to ever have more than one. My feeling is that consistency with past releases is more important than what I regard as specious consistency of groupIds.
>
> 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.
Thinking about this more it won't work. We need to publish the util-parent pom so you can find the scm info from published artifacts, even if it's not navigateable from the bundle pom. And we probably want at least a source jar from the util-r42 jar project and trying to only deploy the source is way too much work.
thanks
david jencks
>
> Holly
>
> On Tue, Jul 3, 2012 at 6:39 PM, David Jencks <da...@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.
>>
>> 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 <ho...@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
>>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by Holly Cummins <ho...@googlemail.com>.
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 <da...@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.
>
> 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 <ho...@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
>
Re: [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by David Jencks <da...@yahoo.com>.
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 <ho...@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
Re: [CANCELLED] [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by David Jencks <da...@yahoo.com>.
I haven't had a chance to look carefully at what Jeremy is saying, but I think he's probably wrong about util. Please note that there is only one intended output bundle from all the util stuff. Everything else is junk needed to build parts against two different osgi levels.
I don't think we need to change the groupId or artifactId of our previous util bundle. We should probably override the deploy mojo to skip deploy on everything except the intended util bundle.
more later
david jencks
On Jul 3, 2012, at 10:22 AM, Holly Cummins wrote:
> I agree that we need to get the group id right for this release. At
> the moment util is the only bundle with a group id of
> org.apache.aries, so it's a bit of an exception to our pattern. I'll
> make these changes and respin the release. I'm not entirely convinced
> that util-bundle is an improvement on util, but since that only
> determines where things are in subversion, and not any externals, I
> think we can probably choose what we like. :)
>
> On Tue, Jul 3, 2012 at 5:51 PM, Jeremy Hughes <hu...@apache.org> 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 <ho...@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
[CANCELLED] [VOTE] Aries util and blueprint.api 1.0.0 release candidates
Posted by Holly Cummins <ho...@googlemail.com>.
I agree that we need to get the group id right for this release. At
the moment util is the only bundle with a group id of
org.apache.aries, so it's a bit of an exception to our pattern. I'll
make these changes and respin the release. I'm not entirely convinced
that util-bundle is an improvement on util, but since that only
determines where things are in subversion, and not any externals, I
think we can probably choose what we like. :)
On Tue, Jul 3, 2012 at 5:51 PM, Jeremy Hughes <hu...@apache.org> 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 <ho...@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