Return-Path: Delivered-To: apmail-cxf-users-archive@www.apache.org Received: (qmail 25110 invoked from network); 4 Dec 2008 07:44:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Dec 2008 07:44:49 -0000 Received: (qmail 91214 invoked by uid 500); 4 Dec 2008 07:44:59 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 91165 invoked by uid 500); 4 Dec 2008 07:44:59 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 91154 invoked by uid 99); 4 Dec 2008 07:44:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Dec 2008 23:44:59 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [62.75.158.78] (HELO mail.liquid-reality.de) (62.75.158.78) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Dec 2008 07:43:29 +0000 Received: from [10.0.0.10] (HSI-KBW-085-216-027-031.hsi.kabelbw.de [85.216.27.31]) by mail.liquid-reality.de (Postfix) with ESMTP id 5480EB6800E; Thu, 4 Dec 2008 07:43:46 +0000 (UTC) Message-ID: <49378A58.4060401@die-schneider.net> Date: Thu, 04 Dec 2008 08:44:24 +0100 From: Christian Schneider User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Daniel Kulp CC: users@cxf.apache.org Subject: Re: Grr. Maven. References: <492AFA41.9090200@comcast.net> <200812011616.09221.dkulp@apache.org> <4934E8B6.1090903@die-schneider.net> <200812031721.48682.dkulp@apache.org> In-Reply-To: <200812031721.48682.dkulp@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Dan, I think this really makes sense. Is there already an issue for this task? I would combine the following modules: cxf-api cxf-common-schemas cxf-common-utilities cxf-rt-core:jar That would at least make the set of dependencies cxf produces by itself smaller. The set above depends on: [INFO] [dependency:list] [INFO] [INFO] The following files have been resolved: [INFO] aopalliance:aopalliance:jar:1.0:compile [INFO] com.sun.xml.bind:jaxb-impl:jar:2.1.7:compile [INFO] com.sun.xml.fastinfoset:FastInfoset:jar:1.2.2:compile [INFO] commons-lang:commons-lang:jar:2.4:compile [INFO] commons-logging:commons-logging:jar:1.1.1:compile [INFO] javax.xml.bind:jaxb-api:jar:2.1:compile [INFO] javax.xml.stream:stax-api:jar:1.0-2:compile [INFO] org.apache.cxf:cxf-api:jar:2.2-SNAPSHOT:compile [INFO] org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile [INFO] org.apache.cxf:cxf-common-utilities:jar:2.2-SNAPSHOT:compile [INFO] org.apache.cxf:cxf-rt-core:jar:2.2-SNAPSHOT:compile [INFO] org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:compile [INFO] org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile [INFO] org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5:compile [INFO] org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile [INFO] org.apache.neethi:neethi:jar:2.0.4:compile [INFO] org.apache.ws.commons.schema:XmlSchema:jar:1.4.2:compile [INFO] org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile [INFO] org.springframework:spring-beans:jar:2.5.5:compile [INFO] org.springframework:spring-context:jar:2.5.5:compile [INFO] org.springframework:spring-core:jar:2.5.5:compile [INFO] wsdl4j:wsdl4j:jar:1.6.2:compile [INFO] xml-resolver:xml-resolver:jar:1.2:compile Btw. I have found the dependency:analyze goal. This looks like it could help us. For cxf-rt-core it reported that jaxb-impl is declared but not used. Interestingly it says the following about cxf-api: [INFO] [dependency:analyze] [WARNING] Used undeclared dependencies found: [WARNING] org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile [WARNING] commons-lang:commons-lang:jar:2.4:compile [WARNING] javax.xml.bind:jaxb-api:jar:2.1:compile [WARNING] org.easymock:easymock:jar:2.4:test [WARNING] wsdl4j:wsdl4j:jar:1.6.2:compile [WARNING] Unused declared dependencies found: [WARNING] org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1.1:compile [WARNING] com.sun.xml.bind:jaxb-xjc:jar:2.1.9:test [WARNING] org.apache.cxf:cxf-common-schemas:jar:2.2-SNAPSHOT:compile [WARNING] org.codehaus.woodstox:wstx-asl:jar:3.2.6:compile [WARNING] com.sun.xml.bind:jaxb-impl:jar:2.1.9:test [WARNING] org.apache.cxf:cxf-xjc-dv:jar:2.2-SNAPSHOT:test and for cxf-common-utilities: [INFO] [dependency:analyze] [WARNING] Used undeclared dependencies found: [WARNING] org.easymock:easymock:jar:2.4:test [WARNING] cglib:cglib-nodep:jar:2.1_3:test [WARNING] Unused declared dependencies found: [WARNING] org.codehaus.woodstox:wstx-asl:jar:3.2.6:test [WARNING] org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0.2:test [WARNING] com.sun.xml.messaging.saaj:saaj-impl:jar:1.3.2:test [WARNING] xml-resolver:xml-resolver:jar:1.2:compile Greetings Christian Daniel Kulp schrieb: > Honestly, one of the things I keep thinking about for 3.0 is combining > common-utilities, api, and rt/core into a single "cxf-kernel" or something. > common-utilities and api seperation is pretty much useless. The utilities > are as much a part of the api as the stuff in the api module is. The reason > they were separated goes WAY WAY back to M1 days when the tools didn't depend > on core. That reason is now long gone and having them separate is almost > pointless. > > But to this discussion, making the API module depend on less things really > won't solve the problem at all. You cannot really do anything without > depending on cxf-rt-core. Thus, if you move a dependency from API to core, > it doesn't change the fact that it would get pulled in for any cxf > application. > > Dan > > > -- Christian Schneider --- http://www.liquid-reality.de