Re: svn commit: r1044430 - /cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/systests2/multi/MultiBundleTools.java
Good point, Dan! I have just done this.
Cheers,
David
On 10 December 2010 17:00, Daniel Kulp wrote:
>
> David,
>
> I don't think this is completely a "maven version" issue. It looks like its
> an issue of not locking down the version of the plugins. Specifically teh
> maven-assembly-plugin.
>
> With maven 2.2, it's getting version 2.2-beta-2. With 3.0, it's getting 2.2-
> beta-5. The best best is to lock down the various versions of the plugins
> to make sure they are consistent no matter the maven version being used.
>
> Then fix the test. :-)
>
> Dan
>
>
> On Friday 10 December 2010 11:49:33 am dav...@apache.org wrote:
>> Author: davidb
>> Date: Fri Dec 10 16:49:33 2010
>> New Revision: 1044430
>>
>> URL: http://svn.apache.org/viewvc?rev=1044430&view=rev
>> Log:
>> Reverting system test change which apparently only applies to Maven 3 while
>> Hudson seems to be using 2.x
>>
>> Modified:
>>
>> cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/
>> systests2/multi/MultiBundleTools.java
>>
>> Modified:
>> cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/
>> systests2/multi/MultiBundleTools.java URL:
>> http://svn.apache.org/viewvc/cxf/dosgi/trunk/systests2/multi-bundle/src/te
>> st/java/org/apache/cxf/dosgi/systests2/multi/MultiBundleTools.java?rev=1044
>> 430&r1=1044429&r2=1044430&view=diff
>> ==
>> ---
>> cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/
>> systests2/multi/MultiBundleTools.java (original) +++
>> cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/
>> systests2/multi/MultiBundleTools.java Fri Dec 10 16:49:33 2010 @@ -44,7
>> +44,7 @@ public class MultiBundleTools {
>> }
>>
>> private static int getDistroBundles(File mdRoot, String pomVersion,
>> Map bundles, boolean discovery) throws Exception { -
>> File distroDir = new File(mdRoot,
>> "target/cxf-dosgi-ri-multibundle-distribution-" + pomVersion); +
>> File distroDir = new File(mdRoot,
>> "target/cxf-dosgi-ri-multibundle-distribution-" + pomVersion + ".dir");
>> Properties p = new Properties();
>> File confDir = new File(distroDir, "apache-cxf-dosgi-ri-" +
>> pomVersion + "/conf"); p.load(new FileInputStream(new File(confDir,
>> "felix.config.properties.append")));
>
> --
> Daniel Kulp
> dk...@apache.org
> http://dankulp.com/blog
>
Re: DOSGI: Update to CXF 2.2.9
Hi Eoghan, All I can say is that the system tests always work fine on my machine and that they also work fine on Hudson... http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/ Having said that, it's always a little tricky to get system tests right for all machines as there are so many things at play. Port numbers, timing, processor architecture, platform, they can all have an impact. I'm pretty sure the functionality tested by the system tests works, although the tests themselves might need a little tweaking to run on all machines (including yours - if you have any tips I would love to hear them :) Cheers, David On 19 July 2010 12:35, Eoghan Glynn wrote: > > Hi David, > >> This exception happens when the remote service doesn't appear within >> the timeout... Any chance of running it again and see if it still >> fails? > > OK, I ran the build a few more times and didn't see the same failure, so > lets put that one down to a once-off aberration. > > However, when cutting the release I'm seeing an apparent hang in > org.apache.cxf.dosgi.systests2.single.TestImportService. I've attached the > tail of the console output so you can see if anything rings a bell there. > > For the moment the release is in limbo, i.e. the poms are updated, the tag > is laid down and the artifacts partially uploaded to the staging area in > Nexus. The upload doesn't look like its going to complete, seeing as the > test has been hung for the last half hour, so either way I'll be killing > that. However if you need to get any further fixes in, let me know and I'll > also roll back the changes in SVN and start from scratch next time. > > If on the other hand you're confident about the integrity of the tests, I > could potentially re-run the release with -Darguments=-Dmaven.test.skip=true > but I'm leery about doing so unless we're fairly happy that I'm seeing a > phantom issue here. > > Cheers, > Eoghan > > > On 19 July 2010 10:30, wrote: >> >> Hi Eoghan, >> >> On 17 July 2010 12:59, Eoghan Glynn wrote: >> >> Eoghan would you have some cycles? >> > >> > Yeah. >> >> Excellent! >> >> > A couple of things before I go ahead and cut the release: >> > >> > - can you update the release notes[1] with a summary of what's new in >> > this >> > release? >> >> Done. >> >> > - does this TimeoutException[2] in >> > TestExportService.testAccessEndpoint() >> > ring any bells? >> >> Not really, to be honest... It always passes for me :) It also passed >> on the last hudson run: >> >> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/ >> >> This exception happens when the remote service doesn't appear within >> the timeout... Any chance of running it again and see if it still >> fails? >> >> Best regards, >> >> David > >
Re: DOSGI: Update to CXF 2.2.9
Hi Eoghan, On 17 July 2010 12:59, Eoghan Glynn wrote: >> Eoghan would you have some cycles? > > Yeah. Excellent! > A couple of things before I go ahead and cut the release: > > - can you update the release notes[1] with a summary of what's new in this > release? Done. > - does this TimeoutException[2] in TestExportService.testAccessEndpoint() > ring any bells? Not really, to be honest... It always passes for me :) It also passed on the last hudson run: http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/ This exception happens when the remote service doesn't appear within the timeout... Any chance of running it again and see if it still fails? Best regards, David
Fwd: svn commit: r964787 - in /cxf/dosgi/trunk: distribution/multi-bundle/ distribution/multi-bundle/src/main/resources/ distribution/single-bundle/ parent/ systests2/multi-bundle/src/test/java/org/
Sorry that should have said CXF 2.2.9.
The commit is good, the message has the typo.
Unfortunately no
svn commit --amend
yet...
David
On 16 July 2010 13:46, wrote:
> Author: davidb
> Date: Fri Jul 16 12:46:10 2010
> New Revision: 964787
>
> URL: http://svn.apache.org/viewvc?rev=964787&view=rev
> Log:
> Move DOSGi to CXF 2.0.9
> - This commit includes Sergey's work to pick up CXF 2.0.9
> - It moves the CXF bundle to the end of the list of bundles
> - And adds the proper start levels to the system tests
>
> Modified:
> cxf/dosgi/trunk/distribution/multi-bundle/pom.xml
>
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/resources/distro_bundles.xml
> cxf/dosgi/trunk/distribution/single-bundle/pom.xml
> cxf/dosgi/trunk/parent/pom.xml
>
> cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/systests2/multi/TestExportService.java
>
> cxf/dosgi/trunk/systests2/multi-bundle/src/test/java/org/apache/cxf/dosgi/systests2/multi/TestImportService.java
>
> Modified: cxf/dosgi/trunk/distribution/multi-bundle/pom.xml
> URL:
> http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/pom.xml?rev=964787&r1=964786&r2=964787&view=diff
> ==
> --- cxf/dosgi/trunk/distribution/multi-bundle/pom.xml (original)
> +++ cxf/dosgi/trunk/distribution/multi-bundle/pom.xml Fri Jul 16 12:46:10 2010
> @@ -63,6 +63,17 @@
> com.springsource.org.apache.commons.logging
> 1.1.1
>
> +
> + org.slf4j
> + com.springsource.slf4j.api
> + 1.5.10
> +
> +
> + org.slf4j
> + com.springsource.slf4j.jcl
> + 1.5.10
> +
> +
>
> org.jdom
> com.springsource.org.jdom
> @@ -180,7 +191,11 @@
> org.apache.servicemix.bundles.woodstox
> ${woodstox.bundle.version}
>
> -
> +
> + org.apache.servicemix.bundles
> + org.apache.servicemix.bundles.commons-pool
> + ${commons.pool.bundle.version}
> +
>
> org.apache.cxf
> cxf-bundle-minimal
>
> Modified:
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/resources/distro_bundles.xml
> URL:
> http://svn.apache.org/viewvc/cxf/dosgi/trunk/distribution/multi-bundle/src/main/resources/distro_bundles.xml?rev=964787&r1=964786&r2=964787&view=diff
> ==
> ---
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/resources/distro_bundles.xml
> (original)
> +++
> cxf/dosgi/trunk/distribution/multi-bundle/src/main/resources/distro_bundles.xml
> Fri Jul 16 12:46:10 2010
> @@ -10,6 +10,8 @@
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/spring-beans-${spring.version}.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/spring-context-${spring.version}.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/com.springsource.org.aopalliance-1.0.0.jar
> +
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/com.springsource.slf4j.api-1.5.10.jar
> +
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/com.springsource.slf4j.jcl-1.5.10.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/spring-aop-${spring.version}.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/spring-osgi-io-${spring.osgi.version}.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/spring-osgi-core-${spring.osgi.version}.jar
> @@ -23,12 +25,13 @@
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/org.apache.servicemix.bundles.xmlresolver-${xmlresolver.bundle.version}.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/org.apache.servicemix.bundles.neethi-${neethi.bundle.version}.jar
>
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/org.apache.servicemix.bundles.woodstox-${woodstox.bundle.version}.jar
> -
> cxf-dosgi-ri-multibundle-distribution-${project.version}.dir/apache-cxf-dosgi-ri-${project.version}/dosgi_bundles/c
Re: [VOTE] David Valeri for committer
+1 from me too. David On 10 March 2010 14:29, Daniel Kulp wrote: > > David's been doing a good job lately of answering questions on the > mailing lists and getting involved there. He's also submitted several high > quality patches for the ws-security and security-policy stuff. The patches > are all very complete with excellent unit tests and such. The WS-Security > stuff is a very complex area of code and he's doing a great job picking it up > and fixing issues in it. > > Here's my +1. Vote will be open for at least 72 hours. > > > -- > Daniel Kulp > dk...@apache.org > http://dankulp.com/blog >
Re: [DOSGi] Reworking the system tests
Thanks for the heads up Eoghan. I understood that the recent tiny bundles integration could take care of this. Have a look at the bottom example in http://wiki.ops4j.org/display/paxexam/ExamAndTinybundles. Do you think that will do it? Cheers, David 2010/1/22 Eoghan Glynn : > > David, > > One thing to note about pax-exam is that its doesn't AFAIK have a feature > analogous to the spring-osgi-test support for accessing and adding to the > manifest for the on-the-fly bundle. > > Now I don't know whether we could possibly live without this > manifest-mangling as currently done by the dOSGi systests, specifically > setting the DynamicImport-Package header to "*". > > If we can live without this setting, no worries. If not, its something to > consider about adopting pax-exam. > > Cheers, > Eoghan > > > 2010/1/22 >> >> Hi all, >> >> One of the things to-do for the DOSGi refactoring work that's >> currently happening on trunk is to re-enable the system tests. >> Now both Sergey and I have been fighting with the spring-osgi based >> testing system that's there before and I can tell you it's generally >> no fun at all. The biggest problem that I've encountered with it is >> the interference of the test framework with the CXF-DOSGi code as they >> both use Spring-DM but sometimes have conflicting requirements. >> >> So I'd like to spend a little bit of time refactoring the system tests >> to use Pax-Exam. I haven't used it in anger yet but I've heard good >> things about it and it should not suffer from the interference >> problem. >> >> Thoughts anyone? >> >> David > >
[DOSGi] Reworking the system tests
Hi all, One of the things to-do for the DOSGi refactoring work that's currently happening on trunk is to re-enable the system tests. Now both Sergey and I have been fighting with the spring-osgi based testing system that's there before and I can tell you it's generally no fun at all. The biggest problem that I've encountered with it is the interference of the test framework with the CXF-DOSGi code as they both use Spring-DM but sometimes have conflicting requirements. So I'd like to spend a little bit of time refactoring the system tests to use Pax-Exam. I haven't used it in anger yet but I've heard good things about it and it should not suffer from the interference problem. Thoughts anyone? David
Re: DOSGi deploy failing on Hudson
Ok - I'll take a look. I can't just change it to 1.0.0-SNAPSHOT because these classes are defined by the OSGi Alliance and their version is actually 1.0.0. But maybe we can avoid building this module separately, this module is only an internal artefact for DOSGi... Cheers, David 2009/12/18 Daniel Kulp : > > > The problem is due to: > parent/pom.xml: > 1.0.0 > > > Thus, the build of > dsw/cxf-osgi-remote-service-admin-interfaces/pom.xml > > is considered a release and is trying to deploy as a release. That version > number needs to change to a SNAPSHOT. > > Dan > > > On Fri December 18 2009 4:35:36 am dav...@apache.org wrote: >> Hi all, >> >> The DOSGi deploy build on Hudson is failing with the following: >> >> [INFO] Error deploying artifact: Authorization failed: Access denied >> to: >> https://repository.apache.org/service/local/staging/deploy/maven2/org/apac >> he/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remo >> te-service-admin-interfaces-1.0.0.jar >> >> See [1]. Anyone an idea what might be causing this or how to resolve it? >> >> Thanks! >> >> David >> >> [1] >> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org >> .apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console >> > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
DOSGi deploy failing on Hudson
Hi all, The DOSGi deploy build on Hudson is failing with the following: [INFO] Error deploying artifact: Authorization failed: Access denied to: https://repository.apache.org/service/local/staging/deploy/maven2/org/apache/cxf/dosgi/cxf-dosgi-remote-service-admin-interfaces/1.0.0/cxf-dosgi-remote-service-admin-interfaces-1.0.0.jar See [1]. Anyone an idea what might be causing this or how to resolve it? Thanks! David [1] http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi-deploy/81/org.apache.cxf.dosgi$cxf-dosgi-remote-service-admin-interfaces/console
Re: Should DOSGi have it's own JIRA?
2009/12/17 Daniel Kulp : > I've set it up: > https://issues.apache.org/jira/browse/DOSGI Nice! > On a related note, should we have a separate DOSGi space on the wiki as well > like we do for the docs? It could then have it's own navigation bar, > etc > > The top level page at cxf.apache.org would point dosgi project to a subdir > like > http://cxf.apache.org/dosgi > > or similar. Thoughts? > > Dan Personally I think that the DOSGi wiki within the CXF wiki as it is now is perfectly fine. It's a CXF subproject after all. Having the strong relation between the projects visible in the Wiki is a good thing IMHO. David
Re: Should DOSGi have it's own JIRA?
Yeah - I think its a good idea to put CXF DOSGi as a separate project in JIRA. Thanks, David 2009/12/17 Daniel Kulp : > > Is there any objections to moving the DOSGI stuff out to it's own JIRA? If > not, I'll do so on Friday. Speak now... :-) > > Dan > > > On Mon December 14 2009 2:39:17 pm Daniel Kulp wrote: >> Quick question: >> >> What are peoples thoughts about pulling the DOSGi stuff from the "CXF" JIRA >> into a separate CXFDOSGI (or just DOSGI) JIRA in the "Category: CXF" >> section at: >> https://issues.apache.org/jira/secure/BrowseProjects.jspa >> >> There are pluses and minuses: >> DOSGi has it's own release schedule, own version numbers,etc Thus, >> having it's own project in JIRA allows it to track those things properly >> without it affecting the main CXF project. >> >> Also, DOSGi has it's own components such as its own build system, local vs >> remote discovery, etc... Having it's own JIRA project would allow >> defining nice components for it's own uses. >> >> On the minus side, it does kind of lower the visibility of the DOSGi issues >> in the CXF JIRA since they wouldn't be there. >> >> >> One COULD argue that JAX-RS could also be pulled out. However, the JAX-RS >> stuff is currently part of the main build and released as part of the full >> CXF stuff. Thus, keeping it in is less of an issue. If we eventually >> split the builds into a "core", "webservices", "rest", etc... then it may >> make sense to do so at that time. >> >> Thoughts? >> > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Cyrille Le Clerc for committer....
+1 David 2009/12/3 Daniel Kulp : > > > Cyrille has submitted several patches to various management and logging > related things for CXF starting way back in February. I think he's up to 7 > or 8 submitted patches. He's also been hanging around the user list for > almost a year answering some questions. Thus, I think he's a bit over due > to become a committer. > > Here is my +1. > > Vote will be open for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Release CXF dOSGi 1.1
Big +1 from me! David 2009/11/25 Eoghan Glynn : > Folks, > > I'm calling a vote to release CXF Distributed OSGi 1.1. > > The dOSGi subproject of CXF provides the Reference Implementation of the > Remote Services Specification version 1.0, Chapter 13 in the OSGi Compendium > Specification [1]. > > The release notes contain a description of new features and issues fixed in > this release: > > > http://svn.apache.org/repos/asf/cxf/dosgi/trunk/distribution/multi-bundle/src/main/release/release_notes.txt > > The staging area is at: > > https://repository.apache.org/content/repositories/orgapachecxf-021 > > The various distributions can be downloaded as follows: > > - *Source:* > > https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-source-distribution/1.1 > - *Multi-bundle:* > > https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-multibundle-distribution/1.1 > - *Single-bundle:* > > https://repository.apache.org/content/repositories/orgapachecxf-021/org/apache/cxf/dosgi/cxf-dosgi-ri-singlebundle-distribution/1.1 > > This release is tagged with cxf-dosgi-ri-1.1 at: > > http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.1 > > The vote will remain open for at least 72 hours. > > Please consider this call to vote as my +1. > > Cheers, > Eoghan > > [1] http://www.osgi.org/Download/Release4V42 >
Re: [VOTE] Release CXF 2.2.5
+1 David 2009/11/15 Daniel Kulp : > > This is a vote to release CXF 2.2.5 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.2.4 release. Over 90 JIRA issues > are resolved for 2.2.5 > > > List of issues: > > The Maven staging area is at: > https://repository.apache.org/content/repositories/orgapachecxf-008/ > > The distributions are in: > https://repository.apache.org/content/repositories/orgapachecxf-008/org/apache/cxf/apache-cxf/2.2.5 > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.5 > > The vote will be open for 72 hours. > > I haven't had time to run the TCK on it yet, so I'll vote later, but I wanted > to get the vote started. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Release CXF 2.1.7
+1 David 2009/10/8 Daniel Kulp > > This is a vote to release CXF 2.1.7 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.1.6 release. Over 25 JIRA issues > are resolved for 2.1.7 > > > List of issues: > > The Maven staging area is at: > https://repository.apache.org/content/repositories/cxf-staging-006/ > > The distributions are in: > > https://repository.apache.org/content/repositories/cxf-staging-006/org/apache/cxf/apache-cxf/2.1.7/ > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.7 > > > Here is my +1. The vote will be open here for at least 72 hours. > > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Release CXF 2.2.4
+1 David 2009/10/8 Daniel Kulp > > This is a vote to release CXF 2.2.4 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.2.3 release. Over 59 JIRA issues > are resolved for 2.2.4. > > > List of issues: > https://issues.apache.org/jira/browse/CXF/fixforversion/12314136 > > The Maven staging area is at: > https://repository.apache.org/content/repositories/cxf-staging-009/ > > The distributions are in: > > https://repository.apache.org/content/repositories/cxf-staging-009/org/apache/cxf/apache-cxf/2.2.4 > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.4 > > > Here is my +1. The vote will be open here for at least 72 hours. > > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
DOSGi builds failing with a missing abdera artifact
Hi all, The CXF DOSGi builds have started failing this morning with the message below. Previously they were building fine. Does anyone know what happened to the abera 0.4.0-incubating dependencies which come in via the cxf-minimal bundle? See: http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/ Cheers, David 1) org.apache.abdera:abdera-core:jar:0.4.0-incubating Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.abdera -DartifactId=abdera-core -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.abdera -DartifactId=abdera-core -Dversion=0.4.0-incubating -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.cxf.dosgi:cxf-dosgi-ri-dsw-cxf:bundle:1.1-SNAPSHOT 2) org.apache.cxf:cxf-bundle-minimal:jar:2.2.3-SNAPSHOT 3) org.apache.abdera:abdera-core:jar:0.4.0-incubating
Re: [VOTE] Release CXF 2.2.2
+1 David 2009/5/22 Daniel Kulp : > > This is a vote to release CXF 2.2.2 > > With only 23 JIRA's resolved for 2.2.2, this doesn't have as many "fixes" as > many of the previous patch releases. HOWEVER, there is a one major new > feature: the JAX-RS 1.0 TCK now passes. Thus, it's worth a release. :-) > > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313901&styleName=Html&projectId=12310511&Create=Create > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.2.2 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.2 > > I'm going to leave the vote open till at least Wednesday due to the long > holiday weekend in the US and also due to me being on "vacation" next week so > I'm not sure when I'll have time to close the vote and push the release. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog > >
Re: [VOTE] Release CXF dOSGi 1.0 (take 2)
+1 David 2009/5/7 Eoghan Glynn : > Folks, > > I'm calling a second vote to release CXF Distributed OSGi 1.0. > > The main differences between this and the first take are: > > - addition of a sources distro > - LICENSE file now contains references to licenses for 3rd party dependencies > - removal of extraneous NOTICEs > - addition of top-level READMEs > - fix for algorithm used to compute DiscoveredServiceTracker property deltas > - fix for name clash on some osgi.remote.* properties > > The distributions are staged at: > > http://people.apache.org/~eglynn/stage_cxf_dosgi/dist > > and the maven artifacts at: > > http://people.apache.org/~eglynn/stage_cxf_dosgi/maven > > This release is tagged with cxf-dosgi-ri-1.0 at: > > http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 > > The vote will remain open for at least 72 hours. > > Please consider this call to vote as my +1. > > Cheers, > Eoghan >
Re: [VOTE] Release CXF dOSGi 1.0
+1 David 2009/5/1 Eoghan Glynn : > Folks, > > I'm calling a vote to release CXF Distributed OSGi 1.0. > > The dOSGi subproject of CXF provides the Reference Implementation of > the Distribution Software (DSW) component of the Distributed OSGi > Specification[1]. > > The staging area can be found at: > > http://people.apache.org/~eglynn/stage_cxf_dosgi > > This release is tagged with cxf-dosgi-ri-1.0 at: > > http://svn.apache.org/repos/asf/cxf/dosgi/tags/cxf-dosgi-ri-1.0 > > The vote will remain open for at least 72 hours. > > Please consider this call to vote as my +1. > > Cheers, > Eoghan > > [1] See RFC 119 in http://www.osgi.org/download/osgi-4.2-early-draft3.pdf >
Re: [VOTE] Release Apache CXF 2.0.11
+1 David 2009/4/21 Daniel Kulp : > This is a vote to release CXF 2.0.11 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.0.10 release. Over 36 JIRA issues > are resolved for 2.0.11. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313634&styleName=Html&projectId=12310511&Create=Create > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.0.11 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.11 > > > Here is my +1. The vote will be open here for at least 72 hours. > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Release CXF 2.1.5
+1 David 2009/4/21 Daniel Kulp : > This is a vote to release CXF 2.1.5 > > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.1.4 release. Over 87 JIRA issues > are resolved for 2.1.5. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313635&styleName=Html&projectId=12310511&Create=Create > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.1.5 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.5 > > > Here is my +1. The vote will be open here for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: Working towards a DOSGi 1.0 release
Hi all, I've been doing some work regarding CXF-1966, removing the Equinox jars and moving the system tests to use Felix 1.4.1. It now works with Spring 1.2.0-rc2-SNAPSHOT. As Eoghan says, there is still the missing functionality around the versions in the ServicePublication. The impact here is that if you have a service that exposes interface A version 1 and a consumer has interface A version 2, while these 2 are binary incompatible, the system is not capable of telling that there is a mismatch. The current code base simply assumes that they are compatible... While this is a gap that needs to be fixed, it might still be worth doing some sort of a release, as what's there today is quite useful in itself. Maybe we shouldn't call it 1.0, but something like 0.9 instead? Having a release out there means that folks can start using this without having to depend on SNAPSHOT jars. My understanding is that Spring 1.2.0 will be out some day this week. I think it would be good do to a release of some sort at that stage... Thoughts anyone? David 2009/3/26 Sergey Beryozkin : > Hi David > > I agree. CXF 2.2.1 should not be far away - perhaps in 4 weeks or 5 weeks > but with the TCK work 'looming' I'd probably not want to ask you to postpone > a release and find myself telling you later on ' I won't make it :-)'. DOSGI > users do need a release so I agree with what you suggested > > thanks, Sergey > > - Original Message - From: > To: > Sent: Thursday, March 26, 2009 8:26 PM > Subject: Re: Working towards a DOSGi 1.0 release > > >> Great to hear about the JAXRS component for DOSGi, Sergey! >> >> What is the expected release timeframe of CXF 2.2.1? >> If its a bit further out, why not do a DOSGi 1.0 release based on CXF >> 2.2 and then do another 1.1 release with the JAXRS stuff as soon as >> 2.2.1 is out? >> >> Cheers, >> >> David >> >> 2009/3/26 Sergey Beryozkin : >>> >>> Hi, >>> >>> I'm quite keen to emded a JAXRS component into DOSGI as I reckon we now >>> have >>> all the pieces in place (proxy based client api support, and Benson's >>> Aegis >>> provider) so it should, fingers crossed, be a fairly straighforward >>> exercise >>> - but then you never know what could actually happen at the development >>> time >>> :-) The only missing thing is that cxf-minimal bundle would need to be >>> upgraded to keep a jaxrs component (+ 250K - which may not be too bad) - >>> but >>> it will be released in 2.2.1 only so DOSGI release would need to be >>> postponed until then - so perhaps such an enhancement can be done later >>> on >>> >>> Cheers, Sergey >>> Hi all, Since CXF 2.2 is out now I was thinking about what work needs to be done for a DOSGi 1.0 release. I've just updated the poms to depend on CXF 2.2, but there's still a few things to do... * there is CXF-1966. It would be good to get a solution to this. I heard that Spring-DM 1.2.0 is going to be released within 2 weeks and that version should work with Felix 1.4.1, so I'm considering removing the checked in Equinox jar and moving to 1.2.0-RC1 using Felix for the moment until we can depend on Spring-DM 1.2.0. Are folks generally ok with that? Once Equinox 3.5 is released, maybe we can add it back in to system test runs as a second platform, by obtaining it from maven or wget or something once its available in a fixed place... * We need to make sure that all the API's we are using are exactly correct with the lasted RFC 119 version, e.g. I think we need to add something to the ServicePublication interface... Anything else we need to think of? Cheers, David >>> >>> > >
Re: Working towards a DOSGi 1.0 release
Great to hear about the JAXRS component for DOSGi, Sergey! What is the expected release timeframe of CXF 2.2.1? If its a bit further out, why not do a DOSGi 1.0 release based on CXF 2.2 and then do another 1.1 release with the JAXRS stuff as soon as 2.2.1 is out? Cheers, David 2009/3/26 Sergey Beryozkin : > Hi, > > I'm quite keen to emded a JAXRS component into DOSGI as I reckon we now have > all the pieces in place (proxy based client api support, and Benson's Aegis > provider) so it should, fingers crossed, be a fairly straighforward exercise > - but then you never know what could actually happen at the development time > :-) The only missing thing is that cxf-minimal bundle would need to be > upgraded to keep a jaxrs component (+ 250K - which may not be too bad) - but > it will be released in 2.2.1 only so DOSGI release would need to be > postponed until then - so perhaps such an enhancement can be done later > on > > Cheers, Sergey > >> Hi all, >> >> Since CXF 2.2 is out now I was thinking about what work needs to be >> done for a DOSGi 1.0 release. >> >> I've just updated the poms to depend on CXF 2.2, but there's still a >> few things to do... >> >> * there is CXF-1966. It would be good to get a solution to this. I >> heard that Spring-DM 1.2.0 is going to be released within 2 weeks and >> that version should work with Felix 1.4.1, so I'm considering removing >> the checked in Equinox jar and moving to 1.2.0-RC1 using Felix for the >> moment until we can depend on Spring-DM 1.2.0. Are folks generally ok >> with that? Once Equinox 3.5 is released, maybe we can add it back in >> to system test runs as a second platform, by obtaining it from maven >> or wget or something once its available in a fixed place... >> * We need to make sure that all the API's we are using are exactly >> correct with the lasted RFC 119 version, e.g. I think we need to add >> something to the ServicePublication interface... >> >> Anything else we need to think of? >> >> Cheers, >> >> David > >
Working towards a DOSGi 1.0 release
Hi all, Since CXF 2.2 is out now I was thinking about what work needs to be done for a DOSGi 1.0 release. I've just updated the poms to depend on CXF 2.2, but there's still a few things to do... * there is CXF-1966. It would be good to get a solution to this. I heard that Spring-DM 1.2.0 is going to be released within 2 weeks and that version should work with Felix 1.4.1, so I'm considering removing the checked in Equinox jar and moving to 1.2.0-RC1 using Felix for the moment until we can depend on Spring-DM 1.2.0. Are folks generally ok with that? Once Equinox 3.5 is released, maybe we can add it back in to system test runs as a second platform, by obtaining it from maven or wget or something once its available in a fixed place... * We need to make sure that all the API's we are using are exactly correct with the lasted RFC 119 version, e.g. I think we need to add something to the ServicePublication interface... Anything else we need to think of? Cheers, David
Re: [VOTE] Release Apache CXF 2.2
+1 David Bosschaert
Re: [VOTE] Andrzej Michalec for committer
+1 David Bosschaert 2009/2/16 Sergey Beryozkin : > As you all know we've been looking for people to help us with our JAXRS > project for a while. We've had some great feedback > > and a number of patches submitted from our JAXRS users which helped us > tremendously. Andrzej Michalec (Andy) has been > > the first user who contributed in a major way to our effort. > > Andy has completed a long pending task to do with JAXRS UriBuilder and > UriInfo implementations by submitting 3 high quality > > patches, by adapting his own private implementations to CXF ones. It was > a time consuming and difficult task which required anyone > > who'd attempt to tackle it to understand quite deeply the advanced HTTP > and URI concepts. Andy submitted a number of queries to a JAXRS user > > list to ensure CXF UriBuilder implementation matched the intentions of > JAXRS authors in a best possible way. > > Personally, I've been delighted with this task being completed and it > was of great and immediate help to us in the client api work - I > believe it saved us about 3 weeks. > > > > Andy has also highlighted the problems CXF JAXRS had around the dynamic > sub-resource resolution and helped us to get things right. He > experimented with the arbitrary > > regular expression support in CXF JAXRS and opened an issue suggesting > how one of edge cases might need to be solved. He also raised an issue > to do with the CXF logging. > > > > Finally, Andy has just gone ahead and improved the way CXF JAXRS > documentation can be bookmarked and accessed, as well as added a section > on dealing with UriBuilder and UriInfo. > > I do believe Andy has had an immediately positive impact on CXF JAXRS > and thus I offer this vote to CXF committers. > > > > Here's my +1. > > > Vote will remain open for at least 72 hours. > > > > Sergey > > > > > > > > > >
Re: [VOTE] Release Apache CXF 2.1.4 (Take 2)
+1 David Bosschaert
Re: [VOTE] Release CXF 2.0.10 (Take 2)
+1 David Bosschaert
Re: [VOTE] Release CXF 2.0.10
+1 David Bosschaert 2009/2/3 Daniel Kulp : > > Since it's been about 4 months since the 2.0.9 release, I decided to go ahead > and do a 2.0.10 release along with 2.1.4. > > This is a vote to release CXF 2.0.10 > > Once again, there have been a bunch of bug fixes and enhancements that > have been done compared to the 2.0.10 release. Over 35 JIRA issues > are resolved for 2.0.10. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313462&styleName=Html&projectId=12310511&Create=Create > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.0.10 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.0.10 > > > Here is my +1. The vote will be open here for at least 72 hours. > > --- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Re: [VOTE] Release Apache CXF 2.1.4
+1 David Bosschaert 2009/2/3 Daniel Kulp : > This is a vote to release CXF 2.1.4 > > With a longer than normal cycle, a LOT of stuff is in this. Over 88 JIRA > issues are resolved for 2.1.3 which is quite a bit of work. > > List of issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12313463&styleName=Html&projectId=12310511&Create=Create > > The staging area is at: > http://people.apache.org/~dkulp/stage_cxf/2.1.4 > > The distributions are in the "dist" directory. The "maven" directory > contains the stuff that will by pushed to the central repository. > > This release is tagged at: > http://svn.apache.org/repos/asf/incubator/cxf/tags/cxf-2.1.4 > > > Here is my +1. The vote will be open here for at least 72 hours. > > -- > Daniel Kulp > dk...@apache.org > http://www.dankulp.com/blog >
Distributed OSGi is now a CXF subproject
Hi all, The Distributed OSGi implementation in Apache CXF has graduated out of the sandbox to its new location as a CXF subproject: http://svn.apache.org/repos/asf/cxf/dosgi/trunk As a subproject it will have an independent release schedule to the main CXF code base. The current implementation provides most of the functionality for the DSW (Distribution Software) component as defined in OSGi RFC 119 (see http://www.osgi.org/download/osgi-4.2-early-draft2.pdf). It is also the official Reference Implementation of this part of the specification. It should work on any version 4.2 compliant OSGi runtime and is known to work with Felix 1.4.1 as well as with Equinox 3.5 milestone builds since December. For more information, see the documentation here: http://cwiki.apache.org/confluence/display/CXF/Distributed+OSGi Best regards, David Bosschaert
Would it make sense to add a Distributed-OSGi component to CXF-Jira?
Hi all, Currently all of the bugs against the Distributed OSGi code are filed in the 'OSGi' component in CXF. However I think this is potentially confusing as the 'OSGi' component really hints to me that it relates to OSGi properties of core CXF (e.g. the way OSGi metadata is added to OSGi-bundelized CXF libraries). Since this is quite a different area from the code that implements the Distributed OSGi specification I was wondering would it make sense to add a 'Distributed OSGi' component to JIRA as well for bugs relating to that code? Cheers, David
