Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
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 sberyoz...@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 idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/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 Bosschaertdavid.bosscha...@gmail.com wrote: On 21 March 2012 15:34, Daniel Kulpdk...@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
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 Beryozkinsberyoz...@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 idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/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 Bosschaertdavid.bosscha...@gmail.com wrote: On 21 March 2012 15:34, Daniel Kulpdk...@apache.orgwrote: 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
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 sberyoz...@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 idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/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 Bosschaertdavid.bosscha...@gmail.com wrote: On 21 March 2012 15:34, Daniel Kulpdk...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
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
Hi David On 22/03/12 12:50, David Bosschaert wrote: On 22 March 2012 11:13, Daniel Kulpdk...@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
On 22 March 2012 13:41, Sergey Beryozkin sberyoz...@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
Hi Sergey, On 20 March 2012 22:09, Sergey Beryozkin sberyoz...@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
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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
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
On 21 March 2012 19:09, David Bosschaert david.bosscha...@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
David, Add to your ~/.m2/settings.xml something like: settings servers server idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/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 david.bosscha...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: CXF-DOSGi and the OSGi Remote Service Admin TCK
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 idapache.releases.https/id usernamedkulp/username passwordyourapachepassword/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 Bosschaertdavid.bosscha...@gmail.com wrote: On 21 March 2012 15:34, Daniel Kulpdk...@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
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 david.bosscha...@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 sberyoz...@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
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 Bosschaertdavid.bosscha...@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 Beryozkinsberyoz...@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
Hi Sergey, On 20 March 2012 09:47, Sergey Beryozkin sberyoz...@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
Hi David On 20/03/12 11:00, David Bosschaert wrote: Hi Sergey, On 20 March 2012 09:47, Sergey Beryozkinsberyoz...@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
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 sberyoz...@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
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
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
