Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 74170 invoked from network); 26 Mar 2006 08:42:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Mar 2006 08:42:38 -0000 Received: (qmail 33187 invoked by uid 500); 26 Mar 2006 08:42:27 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 33171 invoked by uid 500); 26 Mar 2006 08:42:26 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 33159 invoked by uid 99); 26 Mar 2006 08:42:26 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Mar 2006 00:42:26 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [206.123.75.163] (HELO sosnoski.com) (206.123.75.163) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 26 Mar 2006 00:42:26 -0800 Received: from [192.168.0.2] (222-152-88-104.jetstream.xtra.co.nz [222.152.88.104]) (authenticated bits=0) by sosnoski.com (8.12.10/8.12.10) with ESMTP id k2Q8g28C018617 for ; Sun, 26 Mar 2006 03:42:04 -0500 Message-ID: <442653D9.6020705@sosnoski.com> Date: Sun, 26 Mar 2006 20:42:01 +1200 From: Dennis Sosnoski User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: axis-dev@ws.apache.org Subject: Re: [Axis2] Databinding structuring proposal References: <44264C6C.4090707@sosnoski.com> In-Reply-To: <44264C6C.4090707@sosnoski.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N One correction - you don't get an error on code generation if the jars for a framework you're not using are missing from the classpath. I thought I'd seen that on an earlier version, but I've verified it doesn't happen now. I do still think a module approach per data binding framework would be cleaner, though. - Dennis Dennis Sosnoski wrote: > I've got the initial JiBX data binding support ready to drop into > Axis2. I'd like to propose a somewhat different structure for this, > though, with the intent that the other data binding approaches > supported also implement the same sort of structure. > > Right now the codegen module knows about all the possible data binding > extensions and loads them all as part of the initial setup. It calls > each one in turn, allowing each extension to decide for itself whether > it needs to do anything. In and of itself I think this is good. What > becomes a problem is that each extension typically includes code that > links into the individual data binding framework, which means all of > these frameworks need to be present in order for the codegen to > execute. For example, if you delete the xbean-2.1.0.jar from the lib > you'll get an error trying to do code generation even if you're not > using XMLBeans. As more and more data binding frameworks are supported > this is going to create increasing problems (including the licensing > issues for JAXB 2.0, as mentioned in some separate recent threads). > > What I'd like to do for JiBX is add a separate module containing the > code that's tied to JiBX, then load that code dynamically from the > JiBX data binding extension - but only if JiBX is actually chosen as > the data binding framework to be used. That way the JiBX jars are only > needed when JiBX is actually being used, which seems like the way we > want things to work. If this approach is adopted for all the data > binding frameworks we can make all the framework code optional > components for the code generation rather than requiring more and more > of these framework jars to be included in the distribution. So a user > could download a minimal distribution which only included Axiom code > generation support (since Axiom is embedded throughout the whole Axis2 > framework anyway), or distributions for each individual data binding > framework. Alternatively, the data binding framework support could be > just a separate zip that users would then unzip into their minimal > distribution - that way JAXB 2.0 could be handled with a separate > download that's not part of the Apache project, for instance. > > Discussion, anyone? > > - Dennis >