You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by David Bosschaert <da...@gmail.com> on 2012/02/19 01:42:37 UTC
CXF-DOSGi and the OSGi Remote Service Admin TCK
Hi all,
I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
to make sure it's still compliant with the spec.
It turned out that the changes made between 1.2 and 1.3 cause a number
of TCK failures, so I've been looking at fixing them.
Here's a quick summary.
* the single-bundle distro (which is used with the TCK) now includes
the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
export/import the types defined in there which meant that these types
existed twice in the VM, once inside the single bundle distro and once
outside. This caused issues with ConfigAdmin and some event types
since communication with the outside world wasn't possible with these
types any more.
I fixed this for the single-bundle distro (it doesn't apply to the
multi-bundle distro).
* ExportReferenceImpl, which is really a wrapper, was used in a Map
but missing hashCode and equals(). I added these.
* There were some issues around close() calls not completely properly
behaving, I fixed those
* RemoteServiceAdminCore was putting objects of the wrong type in the
collection returned by exportService()
Some more changes may be needed in order to fully pass the TCK, but
I've committed the above in r1290914.
Cheers,
David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, March 22, 2012 01:41:00 PM Sergey Beryozkin wrote:
> I'm seeing 1.4-SNAPSHOT in poms, I guess I can update that easily later
> on to 1.3.2-SNAPSHOT as I won't have enough 'material' to call a 1.4
> release in few months time, the upgrade to Blueprint would of course go
> to 1.4 :-), but I'm not sure when exactly it will happen...
Well, in a few months, hopefully CXF 2.6 will be out and maybe an upgrade to
that with the "little bundles" instead of the big bundle may warrant calling
it 1.4. :-)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
On 22 March 2012 13:41, Sergey Beryozkin <sb...@gmail.com> wrote:
> I'm seeing 1.4-SNAPSHOT in poms, I guess I can update that easily later on
> to 1.3.2-SNAPSHOT as I won't have enough 'material' to call a 1.4 release in
> few months time, the upgrade to Blueprint would of course go to 1.4 :-), but
> I'm not sure when exactly it will happen...
Yes, I wasn't completely sure what the convention was. The poms
already contained 1.4-SNAPSHOT. I wasn't sure whether we wanted to
move back to 1.3.2-SNAPSHOT, but I would have no problems with it...
Cheers,
David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On 22/03/12 12:50, David Bosschaert wrote:
> On 22 March 2012 11:13, Daniel Kulp<dk...@apache.org> wrote:
>> On Thursday, March 22, 2012 08:47:16 AM David Bosschaert wrote:
>>> Yes, the changes to settings.xml helped. That got me past that issue.
>>>
>>> However, I ended up having some problems with the GPG side of things
>>> (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
>>> It seems like the artifacts were signed by a subkey which apparently
>>> doesn't work. So it looks like I need to do things over again.
>>> Does it harm doing mvn release:prepare and mvn release:perform a
>>> second time with the same version? I guess this will mean that the tag
>>> gets moved?
>>
>> Just make sure you "svn rm" the tag first. Then it should be OK to just
>> redo it.
>>
>> Dan
>
> Ok, that seems to have worked now.
> I have the CXF-DOSGi 1.3.1 artifacts staged here:
> https://repository.apache.org/content/repositories/orgapachecxf-101/
>
> Could someone please confirm that I did this correctly?
>
> Before calling the vote I would like to run the actual artifacts
> through the OSGi TCK to ensure that everything is still green.
> Is there anything else that needs to be done before the vote can be called?
>
I quickly tested the greeter demo against single & multi bundles
distros, downloading all from the staged repo, looks ok.
I'm seeing 1.4-SNAPSHOT in poms, I guess I can update that easily later
on to 1.3.2-SNAPSHOT as I won't have enough 'material' to call a 1.4
release in few months time, the upgrade to Blueprint would of course go
to 1.4 :-), but I'm not sure when exactly it will happen...
Thanks, Sergey
> Cheers,
>
> David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
On 22 March 2012 11:13, Daniel Kulp <dk...@apache.org> wrote:
> On Thursday, March 22, 2012 08:47:16 AM David Bosschaert wrote:
>> Yes, the changes to settings.xml helped. That got me past that issue.
>>
>> However, I ended up having some problems with the GPG side of things
>> (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
>> It seems like the artifacts were signed by a subkey which apparently
>> doesn't work. So it looks like I need to do things over again.
>> Does it harm doing mvn release:prepare and mvn release:perform a
>> second time with the same version? I guess this will mean that the tag
>> gets moved?
>
> Just make sure you "svn rm" the tag first. Then it should be OK to just
> redo it.
>
> Dan
Ok, that seems to have worked now.
I have the CXF-DOSGi 1.3.1 artifacts staged here:
https://repository.apache.org/content/repositories/orgapachecxf-101/
Could someone please confirm that I did this correctly?
Before calling the vote I would like to run the actual artifacts
through the OSGi TCK to ensure that everything is still green.
Is there anything else that needs to be done before the vote can be called?
Cheers,
David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, March 22, 2012 08:47:16 AM David Bosschaert wrote:
> Yes, the changes to settings.xml helped. That got me past that issue.
>
> However, I ended up having some problems with the GPG side of things
> (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
> It seems like the artifacts were signed by a subkey which apparently
> doesn't work. So it looks like I need to do things over again.
> Does it harm doing mvn release:prepare and mvn release:perform a
> second time with the same version? I guess this will mean that the tag
> gets moved?
Just make sure you "svn rm" the tag first. Then it should be OK to just
redo it.
Dan
>
> Cheers,
>
> David
>
> [1] https://issues.sonatype.org/browse/OSSRH-1525
>
> On 21 March 2012 20:44, Sergey Beryozkin <sb...@gmail.com> wrote:
> > Yes, this is what I did.
> >
> > David, I think we also need to get your public gpg key added to
> > http://pgp.mit.edu/, here are some links I found useful.
> >
> > http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html
> >
> > https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatu
> > res+With+Maven
> >
> > You should be able to login to
> > https://repository.apache.org/index.html#welcome
> >
> > with your apache login/password,
> >
> > This guide is good:
> > http://www.apache.org/dev/publishing-maven-artifacts.html
> >
> > but this one on the Codehaus is also good:
> > http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usa
> > ge+Guide
> >
> > HTH, thanks for deciding to give it a go :-) I'll get you a pint :-)
> >
> > Cheers, Sergey
> >
> > On 21/03/12 20:34, Daniel Kulp wrote:
> >> David,
> >>
> >> Add to your ~/.m2/settings.xml something like:
> >>
> >>
> >> <settings>
> >> <servers>
> >> <server>
> >> <id>apache.releases.https</id>
> >> <username>dkulp</username>
> >> <password>yourapachepassword</password>
> >> </server>
> >> </servers>
> >> </settings>
> >>
> >> to setup your credentials needed to deploy to Nexus. If that works,
> >> let
> >> me
> >> know and I'll update the release page. (or feel free to update it)
> >>
> >>
> >> Dan
> >>
> >> On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote:
> >>> On 21 March 2012 19:09, David Bosschaert<da...@gmail.com>
> >>
> >> wrote:
> >>>> On 21 March 2012 15:34, Daniel Kulp<dk...@apache.org> wrote:
> >>>>> If you are willing to do the release, then I think it's a good idea.
> >>>>> I'd
> >>>>> rather have a release often type thing if it fixes a few issue that
> >>>>> are
> >>>>> needed. Do you know if it needs a new CXF proper release or is
> >>>>> 2.5.2
> >>>>> OK? If it's just a release of the DOSGi stuff, then it should be
> >>>>> pretty simple. I think a simple:
> >>>>>
> >>>>> mvn release:prepare
> >>>>> mvn release:perform
> >>>>>
> >>>>> should handle most of it. The release-manangement page for cxf
> >>>>> might
> >>>>> have more details about setting up the gpg stuff, Nexus, etc...
> >>>>
> >>>> It's the gpg and Nexus stuff that I'm unsure about in relation to how
> >>>> releases are done at Apache, but I see things are documented well on
> >>>> that page, so I'll give it a try soon.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> David
> >>>
> >>> I successfully completed the release:prepare (I think) but the
> >>> release:perform fails with the error below.
> >>>
> >>> Any ideas? Sergey, how did you do this before?
> >>>
> >>> David
> >>>
> >>> [INFO] BUILD FAILURE
> >>> [INFO]
> >>> ----------------------------------------------------------------------
> >>> --
> >>> [INFO] Total time: 7.789s
> >>> [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
> >>> [INFO] Final Memory: 10M/81M
> >>> [INFO]
> >>> ----------------------------------------------------------------------
> >>> --
> >>> [WARNING] The requested profile "deploy" could not be activated
> >>> because
> >>> it does not exist.
> >>> [ERROR] Failed to execute goal
> >>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
> >>> (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
> >>> Could not transfer artifact
> >>> org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
> >>> apache.releases.https
> >>> (https://repository.apache.org/service/local/staging/deploy/maven2):
> >>> Failed to transfer file:
> >>>
> >>> https://repository.apache.org/service/local/staging/deploy/maven2/org/
> >>> apac he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return
> >>> code is: 401 -> [Help 1]
> >>> ... more stuff ...
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On 22/03/12 08:47, David Bosschaert wrote:
> Yes, the changes to settings.xml helped. That got me past that issue.
>
> However, I ended up having some problems with the GPG side of things
> (GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
> It seems like the artifacts were signed by a subkey which apparently
> doesn't work. So it looks like I need to do things over again.
> Does it harm doing mvn release:prepare and mvn release:perform a
> second time with the same version? I guess this will mean that the tag
> gets moved?
>
I got the Jettison release failing like this once, so what I did I
reverted to the revision which was there before I started the release
process, and then started again.
Cheers, Sergey
> Cheers,
>
> David
>
> [1] https://issues.sonatype.org/browse/OSSRH-1525
>
> On 21 March 2012 20:44, Sergey Beryozkin<sb...@gmail.com> wrote:
>> Yes, this is what I did.
>>
>> David, I think we also need to get your public gpg key added to
>> http://pgp.mit.edu/, here are some links I found useful.
>>
>> http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html
>>
>> https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
>>
>> You should be able to login to
>> https://repository.apache.org/index.html#welcome
>>
>> with your apache login/password,
>>
>> This guide is good:
>> http://www.apache.org/dev/publishing-maven-artifacts.html
>>
>> but this one on the Codehaus is also good:
>> http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide
>>
>> HTH, thanks for deciding to give it a go :-) I'll get you a pint :-)
>>
>> Cheers, Sergey
>>
>>
>>
>>
>> On 21/03/12 20:34, Daniel Kulp wrote:
>>>
>>>
>>> David,
>>>
>>> Add to your ~/.m2/settings.xml something like:
>>>
>>>
>>> <settings>
>>> <servers>
>>> <server>
>>> <id>apache.releases.https</id>
>>> <username>dkulp</username>
>>> <password>yourapachepassword</password>
>>> </server>
>>> </servers>
>>> </settings>
>>>
>>> to setup your credentials needed to deploy to Nexus. If that works, let
>>> me
>>> know and I'll update the release page. (or feel free to update it)
>>>
>>>
>>> Dan
>>>
>>>
>>>
>>> On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote:
>>>>
>>>> On 21 March 2012 19:09, David Bosschaert<da...@gmail.com>
>>>
>>> wrote:
>>>>>
>>>>> On 21 March 2012 15:34, Daniel Kulp<dk...@apache.org> wrote:
>>>>>>
>>>>>> If you are willing to do the release, then I think it's a good idea.
>>>>>> I'd
>>>>>> rather have a release often type thing if it fixes a few issue that are
>>>>>> needed. Do you know if it needs a new CXF proper release or is 2.5.2
>>>>>> OK? If it's just a release of the DOSGi stuff, then it should be
>>>>>> pretty simple. I think a simple:
>>>>>>
>>>>>> mvn release:prepare
>>>>>> mvn release:perform
>>>>>>
>>>>>> should handle most of it. The release-manangement page for cxf
>>>>>> might
>>>>>> have more details about setting up the gpg stuff, Nexus, etc...
>>>>>
>>>>>
>>>>> It's the gpg and Nexus stuff that I'm unsure about in relation to how
>>>>> releases are done at Apache, but I see things are documented well on
>>>>> that page, so I'll give it a try soon.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> David
>>>>
>>>>
>>>> I successfully completed the release:prepare (I think) but the
>>>> release:perform fails with the error below.
>>>>
>>>> Any ideas? Sergey, how did you do this before?
>>>>
>>>> David
>>>>
>>>> [INFO] BUILD FAILURE
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] Total time: 7.789s
>>>> [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
>>>> [INFO] Final Memory: 10M/81M
>>>> [INFO]
>>>> ------------------------------------------------------------------------
>>>> [WARNING] The requested profile "deploy" could not be activated because
>>>> it does not exist.
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
>>>> (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
>>>> Could not transfer artifact
>>>> org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
>>>> apache.releases.https
>>>> (https://repository.apache.org/service/local/staging/deploy/maven2):
>>>> Failed to transfer file:
>>>>
>>>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
>>>> he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is:
>>>> 401 -> [Help 1]
>>>> ... more stuff ...
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
Yes, the changes to settings.xml helped. That got me past that issue.
However, I ended up having some problems with the GPG side of things
(GPG on Mac OSX) - similar to [1] so I couldn't close the stage repo.
It seems like the artifacts were signed by a subkey which apparently
doesn't work. So it looks like I need to do things over again.
Does it harm doing mvn release:prepare and mvn release:perform a
second time with the same version? I guess this will mean that the tag
gets moved?
Cheers,
David
[1] https://issues.sonatype.org/browse/OSSRH-1525
On 21 March 2012 20:44, Sergey Beryozkin <sb...@gmail.com> wrote:
> Yes, this is what I did.
>
> David, I think we also need to get your public gpg key added to
> http://pgp.mit.edu/, here are some links I found useful.
>
> http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html
>
> https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
>
> You should be able to login to
> https://repository.apache.org/index.html#welcome
>
> with your apache login/password,
>
> This guide is good:
> http://www.apache.org/dev/publishing-maven-artifacts.html
>
> but this one on the Codehaus is also good:
> http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide
>
> HTH, thanks for deciding to give it a go :-) I'll get you a pint :-)
>
> Cheers, Sergey
>
>
>
>
> On 21/03/12 20:34, Daniel Kulp wrote:
>>
>>
>> David,
>>
>> Add to your ~/.m2/settings.xml something like:
>>
>>
>> <settings>
>> <servers>
>> <server>
>> <id>apache.releases.https</id>
>> <username>dkulp</username>
>> <password>yourapachepassword</password>
>> </server>
>> </servers>
>> </settings>
>>
>> to setup your credentials needed to deploy to Nexus. If that works, let
>> me
>> know and I'll update the release page. (or feel free to update it)
>>
>>
>> Dan
>>
>>
>>
>> On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote:
>>>
>>> On 21 March 2012 19:09, David Bosschaert<da...@gmail.com>
>>
>> wrote:
>>>>
>>>> On 21 March 2012 15:34, Daniel Kulp<dk...@apache.org> wrote:
>>>>>
>>>>> If you are willing to do the release, then I think it's a good idea.
>>>>> I'd
>>>>> rather have a release often type thing if it fixes a few issue that are
>>>>> needed. Do you know if it needs a new CXF proper release or is 2.5.2
>>>>> OK? If it's just a release of the DOSGi stuff, then it should be
>>>>> pretty simple. I think a simple:
>>>>>
>>>>> mvn release:prepare
>>>>> mvn release:perform
>>>>>
>>>>> should handle most of it. The release-manangement page for cxf
>>>>> might
>>>>> have more details about setting up the gpg stuff, Nexus, etc...
>>>>
>>>>
>>>> It's the gpg and Nexus stuff that I'm unsure about in relation to how
>>>> releases are done at Apache, but I see things are documented well on
>>>> that page, so I'll give it a try soon.
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>
>>>
>>> I successfully completed the release:prepare (I think) but the
>>> release:perform fails with the error below.
>>>
>>> Any ideas? Sergey, how did you do this before?
>>>
>>> David
>>>
>>> [INFO] BUILD FAILURE
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] Total time: 7.789s
>>> [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
>>> [INFO] Final Memory: 10M/81M
>>> [INFO]
>>> ------------------------------------------------------------------------
>>> [WARNING] The requested profile "deploy" could not be activated because
>>> it does not exist.
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
>>> (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
>>> Could not transfer artifact
>>> org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
>>> apache.releases.https
>>> (https://repository.apache.org/service/local/staging/deploy/maven2):
>>> Failed to transfer file:
>>>
>>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
>>> he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is:
>>> 401 -> [Help 1]
>>> ... more stuff ...
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Sergey Beryozkin <sb...@gmail.com>.
Yes, this is what I did.
David, I think we also need to get your public gpg key added to
http://pgp.mit.edu/, here are some links I found useful.
http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/gpg-cs.html
https://docs.sonatype.org/display/Repository/How+To+Generate+PGP+Signatures+With+Maven
You should be able to login to
https://repository.apache.org/index.html#welcome
with your apache login/password,
This guide is good:
http://www.apache.org/dev/publishing-maven-artifacts.html
but this one on the Codehaus is also good:
http://docs.codehaus.org/display/HAUSMATES/Codehaus+Maven+Repository+Usage+Guide
HTH, thanks for deciding to give it a go :-) I'll get you a pint :-)
Cheers, Sergey
On 21/03/12 20:34, Daniel Kulp wrote:
>
> David,
>
> Add to your ~/.m2/settings.xml something like:
>
>
> <settings>
> <servers>
> <server>
> <id>apache.releases.https</id>
> <username>dkulp</username>
> <password>yourapachepassword</password>
> </server>
> </servers>
> </settings>
>
> to setup your credentials needed to deploy to Nexus. If that works, let me
> know and I'll update the release page. (or feel free to update it)
>
>
> Dan
>
>
>
> On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote:
>> On 21 March 2012 19:09, David Bosschaert<da...@gmail.com>
> wrote:
>>> On 21 March 2012 15:34, Daniel Kulp<dk...@apache.org> wrote:
>>>> If you are willing to do the release, then I think it's a good idea.
>>>> I'd
>>>> rather have a release often type thing if it fixes a few issue that are
>>>> needed. Do you know if it needs a new CXF proper release or is 2.5.2
>>>> OK? If it's just a release of the DOSGi stuff, then it should be
>>>> pretty simple. I think a simple:
>>>>
>>>> mvn release:prepare
>>>> mvn release:perform
>>>>
>>>> should handle most of it. The release-manangement page for cxf
>>>> might
>>>> have more details about setting up the gpg stuff, Nexus, etc...
>>>
>>> It's the gpg and Nexus stuff that I'm unsure about in relation to how
>>> releases are done at Apache, but I see things are documented well on
>>> that page, so I'll give it a try soon.
>>>
>>> Cheers,
>>>
>>> David
>>
>> I successfully completed the release:prepare (I think) but the
>> release:perform fails with the error below.
>>
>> Any ideas? Sergey, how did you do this before?
>>
>> David
>>
>> [INFO] BUILD FAILURE
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 7.789s
>> [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
>> [INFO] Final Memory: 10M/81M
>> [INFO]
>> ------------------------------------------------------------------------
>> [WARNING] The requested profile "deploy" could not be activated because
>> it does not exist.
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
>> (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
>> Could not transfer artifact
>> org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
>> apache.releases.https
>> (https://repository.apache.org/service/local/staging/deploy/maven2):
>> Failed to transfer file:
>> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
>> he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is:
>> 401 -> [Help 1]
>> ... more stuff ...
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Daniel Kulp <dk...@apache.org>.
David,
Add to your ~/.m2/settings.xml something like:
<settings>
<servers>
<server>
<id>apache.releases.https</id>
<username>dkulp</username>
<password>yourapachepassword</password>
</server>
</servers>
</settings>
to setup your credentials needed to deploy to Nexus. If that works, let me
know and I'll update the release page. (or feel free to update it)
Dan
On Wednesday, March 21, 2012 07:55:24 PM David Bosschaert wrote:
> On 21 March 2012 19:09, David Bosschaert <da...@gmail.com>
wrote:
> > On 21 March 2012 15:34, Daniel Kulp <dk...@apache.org> wrote:
> >> If you are willing to do the release, then I think it's a good idea.
> >> I'd
> >> rather have a release often type thing if it fixes a few issue that are
> >> needed. Do you know if it needs a new CXF proper release or is 2.5.2
> >> OK? If it's just a release of the DOSGi stuff, then it should be
> >> pretty simple. I think a simple:
> >>
> >> mvn release:prepare
> >> mvn release:perform
> >>
> >> should handle most of it. The release-manangement page for cxf
> >> might
> >> have more details about setting up the gpg stuff, Nexus, etc...
> >
> > It's the gpg and Nexus stuff that I'm unsure about in relation to how
> > releases are done at Apache, but I see things are documented well on
> > that page, so I'll give it a try soon.
> >
> > Cheers,
> >
> > David
>
> I successfully completed the release:prepare (I think) but the
> release:perform fails with the error below.
>
> Any ideas? Sergey, how did you do this before?
>
> David
>
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 7.789s
> [INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
> [INFO] Final Memory: 10M/81M
> [INFO]
> ------------------------------------------------------------------------
> [WARNING] The requested profile "deploy" could not be activated because
> it does not exist.
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
> (default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
> Could not transfer artifact
> org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
> apache.releases.https
> (https://repository.apache.org/service/local/staging/deploy/maven2):
> Failed to transfer file:
> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac
> he/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom. Return code is:
> 401 -> [Help 1]
> ... more stuff ...
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
On 21 March 2012 19:09, David Bosschaert <da...@gmail.com> wrote:
> On 21 March 2012 15:34, Daniel Kulp <dk...@apache.org> wrote:
>> If you are willing to do the release, then I think it's a good idea. I'd
>> rather have a release often type thing if it fixes a few issue that are
>> needed. Do you know if it needs a new CXF proper release or is 2.5.2 OK?
>> If it's just a release of the DOSGi stuff, then it should be pretty simple.
>> I think a simple:
>>
>> mvn release:prepare
>> mvn release:perform
>>
>> should handle most of it. The release-manangement page for cxf might
>> have more details about setting up the gpg stuff, Nexus, etc...
>
> It's the gpg and Nexus stuff that I'm unsure about in relation to how
> releases are done at Apache, but I see things are documented well on
> that page, so I'll give it a try soon.
>
> Cheers,
>
> David
I successfully completed the release:prepare (I think) but the
release:perform fails with the error below.
Any ideas? Sergey, how did you do this before?
David
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.789s
[INFO] Finished at: Wed Mar 21 19:51:53 GMT 2012
[INFO] Final Memory: 10M/81M
[INFO] ------------------------------------------------------------------------
[WARNING] The requested profile "deploy" could not be activated
because it does not exist.
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy
(default-deploy) on project cxf-dosgi-ri: Failed to deploy artifacts:
Could not transfer artifact
org.apache.cxf.dosgi:cxf-dosgi-ri:pom:1.3.1 from/to
apache.releases.https
(https://repository.apache.org/service/local/staging/deploy/maven2):
Failed to transfer file:
https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-ri/1.3.1/cxf-dosgi-ri-1.3.1.pom.
Return code is: 401 -> [Help 1]
... more stuff ...
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
On 21 March 2012 15:34, Daniel Kulp <dk...@apache.org> wrote:
> If you are willing to do the release, then I think it's a good idea. I'd
> rather have a release often type thing if it fixes a few issue that are
> needed. Do you know if it needs a new CXF proper release or is 2.5.2 OK?
> If it's just a release of the DOSGi stuff, then it should be pretty simple.
> I think a simple:
>
> mvn release:prepare
> mvn release:perform
>
> should handle most of it. The release-manangement page for cxf might
> have more details about setting up the gpg stuff, Nexus, etc...
It's the gpg and Nexus stuff that I'm unsure about in relation to how
releases are done at Apache, but I see things are documented well on
that page, so I'll give it a try soon.
Cheers,
David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Daniel Kulp <dk...@apache.org>.
David,
On Tuesday, March 20, 2012 11:00:12 AM David Bosschaert wrote:
> The TCK compliance work I did was part of the OSGi 4.3 Compendium
> cycle and I expect that the RIs for that (of which CXF-DOSGi is part)
> will be collected soon - within 2 weeks is my guess, but I can get a
> more detailed deadline if needed.
> If we want a released version of CXF-DOSGi to be part of that RI, we
> need to have that release before then. Otherwise they'll take the
> current version which is based on a 1.4 snapshot...
> Would there be an issue with just releasing what's there now (read:
> really soon) and maybe do a 1.3.2 in June/July?
> I've never done an Apache release so I'm not really sure how much work
> is involved, but if it's just a matter of a few commands, I think it
> would be worth it doing it now - but obviously that all depends on
> time people have available too...
If you are willing to do the release, then I think it's a good idea. I'd
rather have a release often type thing if it fixes a few issue that are
needed. Do you know if it needs a new CXF proper release or is 2.5.2 OK?
If it's just a release of the DOSGi stuff, then it should be pretty simple.
I think a simple:
mvn release:prepare
mvn release:perform
should handle most of it. The release-manangement page for cxf might
have more details about setting up the gpg stuff, Nexus, etc...
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
Hi Sergey,
On 20 March 2012 22:09, Sergey Beryozkin <sb...@gmail.com> wrote:
> How does this Compendium cycle work ? Having CXF DOSGi RI 'endorced' as
> TCK-compliant is a strong enough reason to try to cut an interim release in
> the next few weeks, however, I'm wondering, when would be DOSGi CXF 1.3.1
> (released say in June/Jule) collected during the next cycle ?
The RI's don't get collected automatically. However during the RI/TCK
cycle of the Compendium 4.3 it was discovered that CXF-DOSGi had some
failures. That's when I started looking into things.
Every time an OSGi release is done, the TCKs are run with the RI
implementations that are checked in to the OSGi systems at that time.
So if there is a new CXF-DOSGi release we can always update the one in
the OSGi systems and have it be part of the next run.
The Compendium 4.3 run is due to close down really soon. The next
RI/TCK cycle after that is the Enterprise R5 cycle, which is currently
planned for June this year.
> I guess you are right in won't take long to quickly do another release, my
> priorities are all on CXF 2.6.0 (and related projects) due in 2-3 weeks, but
> I guess this can be done quickly enough. Personally I'd prefer to have at
> least couple of user-reported issues addressed along the way but I
> definitely have no time for it now,
>
> So if the collection can be easily organized in the next few months then I'd
> prefer to wait till then, but if not doing this release now would mean the
> collection will happen in one year time then I guess we should go for it.
So yes, we can certainly wait and have a released version checked in
for Enterprise R5, it will just mean that the Compendium R4.3 will
have a non-released version of CXF as the RI.
Cheers,
David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On 20/03/12 11:00, David Bosschaert wrote:
> Hi Sergey,
>
> On 20 March 2012 09:47, Sergey Beryozkin<sb...@gmail.com> wrote:
>> Hi David
>>
>> On 20/03/12 08:00, David Bosschaert wrote:
>>>
>>> I just got confirmation that the current trunk of the CXF-DOSGi passes
>>> the TCK again.
>>
>> Great news, thanks for the support from your side,
>>
>>> It would be *really* good if we could release this
>>> version so that the Remote Services and RSA RI in the OSGi systems is
>>> a released version of CXF-DOSGi rather than a snapshot. Sergey, could
>>> I maybe ask you to do a release again?
>>
>> I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs
>> have been opened against 1.3 so I'll try to address some of them too before
>> cutting a new release.
>
> The TCK compliance work I did was part of the OSGi 4.3 Compendium
> cycle and I expect that the RIs for that (of which CXF-DOSGi is part)
> will be collected soon - within 2 weeks is my guess, but I can get a
> more detailed deadline if needed.
> If we want a released version of CXF-DOSGi to be part of that RI, we
> need to have that release before then. Otherwise they'll take the
> current version which is based on a 1.4 snapshot...
> Would there be an issue with just releasing what's there now (read:
> really soon) and maybe do a 1.3.2 in June/July?
> I've never done an Apache release so I'm not really sure how much work
> is involved, but if it's just a matter of a few commands, I think it
> would be worth it doing it now - but obviously that all depends on
> time people have available too...
How does this Compendium cycle work ? Having CXF DOSGi RI 'endorced' as
TCK-compliant is a strong enough reason to try to cut an interim release
in the next few weeks, however, I'm wondering, when would be DOSGi CXF
1.3.1 (released say in June/Jule) collected during the next cycle ?
I guess you are right in won't take long to quickly do another release,
my priorities are all on CXF 2.6.0 (and related projects) due in 2-3
weeks, but I guess this can be done quickly enough. Personally I'd
prefer to have at least couple of user-reported issues addressed along
the way but I definitely have no time for it now,
So if the collection can be easily organized in the next few months then
I'd prefer to wait till then, but if not doing this release now would
mean the collection will happen in one year time then I guess we should
go for it.
Thoughts ?
>
>>> Here's a summary of the fixes:
>>> * Fixed exports from Single Bundle Distro
>>> * Fixed deadlock
>>> * Fixed cleanup
>>> * Fixed ExportReferenceImpl.equals() and hashCode()
>>> * Fixed RemoteServiceAdminCore.exportService()
>>>
>>> As these issues are all exposed by the OSGi TCK I didn't write any
>>> additional tests for them in the CXF-DOSGi codebase.
>>> As an aside. Note that it is possible for Apache committers to run the
>>> OSGi TCK. If anyone is interested let me know and I'll dig up the
>>> details.
>>
>> Is that info in the public domain ? If yes then may be you can add this info
>> to the DOSGi wiki ?
>
> It is documented for Felix and Equinox projects that implement other
> OSGi specs, but I'll take an action item to document this on the DOSGi
> wiki as well.
>
Sounds good, thanks
Sergey
> Cheers,
>
> David
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
Hi Sergey,
On 20 March 2012 09:47, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi David
>
> On 20/03/12 08:00, David Bosschaert wrote:
>>
>> I just got confirmation that the current trunk of the CXF-DOSGi passes
>> the TCK again.
>
> Great news, thanks for the support from your side,
>
>> It would be *really* good if we could release this
>> version so that the Remote Services and RSA RI in the OSGi systems is
>> a released version of CXF-DOSGi rather than a snapshot. Sergey, could
>> I maybe ask you to do a release again?
>
> I'm planning to do a 1.3.1 release in the June/July time frame, few JIRAs
> have been opened against 1.3 so I'll try to address some of them too before
> cutting a new release.
The TCK compliance work I did was part of the OSGi 4.3 Compendium
cycle and I expect that the RIs for that (of which CXF-DOSGi is part)
will be collected soon - within 2 weeks is my guess, but I can get a
more detailed deadline if needed.
If we want a released version of CXF-DOSGi to be part of that RI, we
need to have that release before then. Otherwise they'll take the
current version which is based on a 1.4 snapshot...
Would there be an issue with just releasing what's there now (read:
really soon) and maybe do a 1.3.2 in June/July?
I've never done an Apache release so I'm not really sure how much work
is involved, but if it's just a matter of a few commands, I think it
would be worth it doing it now - but obviously that all depends on
time people have available too...
>> Here's a summary of the fixes:
>> * Fixed exports from Single Bundle Distro
>> * Fixed deadlock
>> * Fixed cleanup
>> * Fixed ExportReferenceImpl.equals() and hashCode()
>> * Fixed RemoteServiceAdminCore.exportService()
>>
>> As these issues are all exposed by the OSGi TCK I didn't write any
>> additional tests for them in the CXF-DOSGi codebase.
>> As an aside. Note that it is possible for Apache committers to run the
>> OSGi TCK. If anyone is interested let me know and I'll dig up the
>> details.
>
> Is that info in the public domain ? If yes then may be you can add this info
> to the DOSGi wiki ?
It is documented for Felix and Equinox projects that implement other
OSGi specs, but I'll take an action item to document this on the DOSGi
wiki as well.
Cheers,
David
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On 20/03/12 08:00, David Bosschaert wrote:
> I just got confirmation that the current trunk of the CXF-DOSGi passes
> the TCK again.
Great news, thanks for the support from your side,
> It would be *really* good if we could release this
> version so that the Remote Services and RSA RI in the OSGi systems is
> a released version of CXF-DOSGi rather than a snapshot. Sergey, could
> I maybe ask you to do a release again?
>
I'm planning to do a 1.3.1 release in the June/July time frame, few
JIRAs have been opened against 1.3 so I'll try to address some of them
too before cutting a new release.
> Here's a summary of the fixes:
> * Fixed exports from Single Bundle Distro
> * Fixed deadlock
> * Fixed cleanup
> * Fixed ExportReferenceImpl.equals() and hashCode()
> * Fixed RemoteServiceAdminCore.exportService()
>
> As these issues are all exposed by the OSGi TCK I didn't write any
> additional tests for them in the CXF-DOSGi codebase.
> As an aside. Note that it is possible for Apache committers to run the
> OSGi TCK. If anyone is interested let me know and I'll dig up the
> details.
Is that info in the public domain ? If yes then may be you can add this
info to the DOSGi wiki ?
Thanks, Sergey
>
> Cheers,
>
> David
>
> On 13 March 2012 07:30, David Bosschaert<da...@gmail.com> wrote:
>> Just a little update on this.
>> I made some more changes and at this point in time we're getting
>> close. For me the OSGi Remote Services and Remote Service Admin TCKs
>> are 100% passing but other people did report a failure that we have to
>> investigate a little further.
>>
>> I'll chime in again when everything is good, as we could do a release
>> at that point.
>>
>> Cheers,
>>
>> David
>>
>> On 20 February 2012 22:38, Sergey Beryozkin<sb...@gmail.com> wrote:
>>> Hi David
>>>
>>> On 19/02/12 00:42, David Bosschaert wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
>>>> to make sure it's still compliant with the spec.
>>>> It turned out that the changes made between 1.2 and 1.3 cause a number
>>>> of TCK failures, so I've been looking at fixing them.
>>>> Here's a quick summary.
>>>> * the single-bundle distro (which is used with the TCK) now includes
>>>> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
>>>> export/import the types defined in there which meant that these types
>>>> existed twice in the VM, once inside the single bundle distro and once
>>>> outside. This caused issues with ConfigAdmin and some event types
>>>> since communication with the outside world wasn't possible with these
>>>> types any more.
>>>> I fixed this for the single-bundle distro (it doesn't apply to the
>>>> multi-bundle distro).
>>>> * ExportReferenceImpl, which is really a wrapper, was used in a Map
>>>> but missing hashCode and equals(). I added these.
>>>> * There were some issues around close() calls not completely properly
>>>> behaving, I fixed those
>>>> * RemoteServiceAdminCore was putting objects of the wrong type in the
>>>> collection returned by exportService()
>>>>
>>>> Some more changes may be needed in order to fully pass the TCK, but
>>>> I've committed the above in r1290914.
>>>>
>>> Cool, guess you are thinking about 1.3.1 already :-)
>>> Cheers, Sergey
>>>
>>>> Cheers,
>>>>
>>>> David
>>>
>>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
I just got confirmation that the current trunk of the CXF-DOSGi passes
the TCK again. It would be *really* good if we could release this
version so that the Remote Services and RSA RI in the OSGi systems is
a released version of CXF-DOSGi rather than a snapshot. Sergey, could
I maybe ask you to do a release again?
Here's a summary of the fixes:
* Fixed exports from Single Bundle Distro
* Fixed deadlock
* Fixed cleanup
* Fixed ExportReferenceImpl.equals() and hashCode()
* Fixed RemoteServiceAdminCore.exportService()
As these issues are all exposed by the OSGi TCK I didn't write any
additional tests for them in the CXF-DOSGi codebase.
As an aside. Note that it is possible for Apache committers to run the
OSGi TCK. If anyone is interested let me know and I'll dig up the
details.
Cheers,
David
On 13 March 2012 07:30, David Bosschaert <da...@gmail.com> wrote:
> Just a little update on this.
> I made some more changes and at this point in time we're getting
> close. For me the OSGi Remote Services and Remote Service Admin TCKs
> are 100% passing but other people did report a failure that we have to
> investigate a little further.
>
> I'll chime in again when everything is good, as we could do a release
> at that point.
>
> Cheers,
>
> David
>
> On 20 February 2012 22:38, Sergey Beryozkin <sb...@gmail.com> wrote:
>> Hi David
>>
>> On 19/02/12 00:42, David Bosschaert wrote:
>>>
>>> Hi all,
>>>
>>> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
>>> to make sure it's still compliant with the spec.
>>> It turned out that the changes made between 1.2 and 1.3 cause a number
>>> of TCK failures, so I've been looking at fixing them.
>>> Here's a quick summary.
>>> * the single-bundle distro (which is used with the TCK) now includes
>>> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
>>> export/import the types defined in there which meant that these types
>>> existed twice in the VM, once inside the single bundle distro and once
>>> outside. This caused issues with ConfigAdmin and some event types
>>> since communication with the outside world wasn't possible with these
>>> types any more.
>>> I fixed this for the single-bundle distro (it doesn't apply to the
>>> multi-bundle distro).
>>> * ExportReferenceImpl, which is really a wrapper, was used in a Map
>>> but missing hashCode and equals(). I added these.
>>> * There were some issues around close() calls not completely properly
>>> behaving, I fixed those
>>> * RemoteServiceAdminCore was putting objects of the wrong type in the
>>> collection returned by exportService()
>>>
>>> Some more changes may be needed in order to fully pass the TCK, but
>>> I've committed the above in r1290914.
>>>
>> Cool, guess you are thinking about 1.3.1 already :-)
>> Cheers, Sergey
>>
>>> Cheers,
>>>
>>> David
>>
>>
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by David Bosschaert <da...@gmail.com>.
Just a little update on this.
I made some more changes and at this point in time we're getting
close. For me the OSGi Remote Services and Remote Service Admin TCKs
are 100% passing but other people did report a failure that we have to
investigate a little further.
I'll chime in again when everything is good, as we could do a release
at that point.
Cheers,
David
On 20 February 2012 22:38, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi David
>
> On 19/02/12 00:42, David Bosschaert wrote:
>>
>> Hi all,
>>
>> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
>> to make sure it's still compliant with the spec.
>> It turned out that the changes made between 1.2 and 1.3 cause a number
>> of TCK failures, so I've been looking at fixing them.
>> Here's a quick summary.
>> * the single-bundle distro (which is used with the TCK) now includes
>> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
>> export/import the types defined in there which meant that these types
>> existed twice in the VM, once inside the single bundle distro and once
>> outside. This caused issues with ConfigAdmin and some event types
>> since communication with the outside world wasn't possible with these
>> types any more.
>> I fixed this for the single-bundle distro (it doesn't apply to the
>> multi-bundle distro).
>> * ExportReferenceImpl, which is really a wrapper, was used in a Map
>> but missing hashCode and equals(). I added these.
>> * There were some issues around close() calls not completely properly
>> behaving, I fixed those
>> * RemoteServiceAdminCore was putting objects of the wrong type in the
>> collection returned by exportService()
>>
>> Some more changes may be needed in order to fully pass the TCK, but
>> I've committed the above in r1290914.
>>
> Cool, guess you are thinking about 1.3.1 already :-)
> Cheers, Sergey
>
>> Cheers,
>>
>> David
>
>
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
On 19/02/12 00:42, David Bosschaert wrote:
> Hi all,
>
> I was recently running the CXF-DOSGi 1.3 release through the OSGi TCK
> to make sure it's still compliant with the spec.
> It turned out that the changes made between 1.2 and 1.3 cause a number
> of TCK failures, so I've been looking at fixing them.
> Here's a quick summary.
> * the single-bundle distro (which is used with the TCK) now includes
> the org.osgi.enterprise-4.2.0.jar. This is fine, but it didn't
> export/import the types defined in there which meant that these types
> existed twice in the VM, once inside the single bundle distro and once
> outside. This caused issues with ConfigAdmin and some event types
> since communication with the outside world wasn't possible with these
> types any more.
> I fixed this for the single-bundle distro (it doesn't apply to the
> multi-bundle distro).
> * ExportReferenceImpl, which is really a wrapper, was used in a Map
> but missing hashCode and equals(). I added these.
> * There were some issues around close() calls not completely properly
> behaving, I fixed those
> * RemoteServiceAdminCore was putting objects of the wrong type in the
> collection returned by exportService()
>
> Some more changes may be needed in order to fully pass the TCK, but
> I've committed the above in r1290914.
>
Cool, guess you are thinking about 1.3.1 already :-)
Cheers, Sergey
> Cheers,
>
> David