Return-Path: X-Original-To: apmail-cxf-dev-archive@www.apache.org Delivered-To: apmail-cxf-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 12AFC9D00 for ; Tue, 24 Jan 2012 22:20:25 +0000 (UTC) Received: (qmail 69721 invoked by uid 500); 24 Jan 2012 22:20:24 -0000 Delivered-To: apmail-cxf-dev-archive@cxf.apache.org Received: (qmail 69578 invoked by uid 500); 24 Jan 2012 22:20:24 -0000 Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list dev@cxf.apache.org Received: (qmail 69570 invoked by uid 99); 24 Jan 2012 22:20:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jan 2012 22:20:23 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [64.85.173.253] (HELO server.dankulp.com) (64.85.173.253) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Jan 2012 22:20:18 +0000 Received: by server.dankulp.com (Postfix, from userid 5000) id 7E4D6182B06; Tue, 24 Jan 2012 17:19:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on server.dankulp.com X-Spam-Level: X-Msg-File: /tmp/mailfilter-dev@cxf.apache.org.GBYePLkPZp Received: from dilbert.dankulp.com (c-24-91-72-253.hsd1.ma.comcast.net [24.91.72.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.dankulp.com (Postfix) with ESMTPSA id 5A813182AB5 for ; Tue, 24 Jan 2012 17:19:56 -0500 (EST) From: Daniel Kulp To: dev@cxf.apache.org Subject: split-packages, osgi bundles, etc..... Date: Tue, 24 Jan 2012 17:19:55 -0500 Message-ID: <21766757.50NZkjoglK@dilbert.dankulp.com> User-Agent: KMail/4.7.4 (Linux/3.2.1; KDE/4.7.4; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Old-Spam-Status: No, score=-102.9 required=3.0 tests=ALL_TRUSTED,BAYES_00, SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.2 I just committed some changes that change the features.xml on trunk to use the modularized bundles instead of the big bundle. It's definitely not complete yet, but consider it a starting point to attempt some testing. :-) Right now, I know I have a few issue to resolve: 1) API loading CXFBusFactory - the call to BusFactory.getDefaultBus or createBus or anything requires API to load a class from rt-core. I'm currently using a dynamic import for this, but that sucks. I need to add an activator to API to find the implementations. This really just affects people using pure API applications or JAX-WS API applications (like wsn). Folks using SpringDM or Blueprint aren't affected by this. 2) Applications that use "Require-Bundle" for the old bundle. I create a "compatbilitiy" bundle of the same name that re-exports stuff from core/api/http that works for a couple of Talend's test cases. I definitely need to flush this out more. HOWEVER, applications that import more than just META-INF/cxf/cxf.xml will have issues as that's the only thing we can really export. That said, ALL the other cxf/cxf-extendion-*.xml files have been deprecated for 2 releases and have spit warnings out in the logs. People should have removed them already. 3) In a couple of my tests, I'm getting warnings in logs about schemas not being available. With the big bundle, we have all the schemas in /schemas so we can easily pull them in for resolving things like ws-addressing and such. I need to figure out exactly what the issue is with the missing schemas and figure out the best solutions for them. More investigation needed. 4) Testing - I've really just run 2 of the Talend examples with it so far and started up the wsn service. Very minimal. Definitely a lot more work to do here. 5) Dependency checking - I updated the features.xml with a bunch of new features. However, I haven't gone through all the jars to see if all the imports resolve or not and then decide which we should resolve. For example, I know aegis databinding jar's dependency on jdom doesn't resolve, but I'm not sure if we should by default resolve that or not since it is completely optional. JAXRS has a few of these as well (like abdera). Anyway, it's progressing. :-) -- Daniel Kulp dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com