Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-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 EBFCE8D56 for ; Wed, 24 Aug 2011 16:17:58 +0000 (UTC) Received: (qmail 72008 invoked by uid 500); 24 Aug 2011 16:17:58 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 71956 invoked by uid 500); 24 Aug 2011 16:17:57 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 71948 invoked by uid 99); 24 Aug 2011 16:17:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 Aug 2011 16:17:57 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.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; Wed, 24 Aug 2011 16:17:51 +0000 Received: from [10.0.0.100] (HSI-KBW-46-223-138-180.hsi.kabel-badenwuerttemberg.de [46.223.138.180]) by mail.liquid-reality.de (Postfix) with ESMTP id 6E79355F031B for ; Wed, 24 Aug 2011 16:17:30 +0000 (UTC) Message-ID: <4E552417.1050002@die-schneider.net> Date: Wed, 24 Aug 2011 18:17:27 +0200 From: Christian Schneider User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: dev@camel.apache.org Subject: Re: Scope of org.apache.camel.spi References: <4E538313.8010002@die-schneider.net> <4E54F6E0.3010202@die-schneider.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Claus, we can do that but then we have to move the impl classes somewhere else. We may not mix impl and api in the same package. This is what leads to cycles. Christian Am 24.08.2011 17:53, schrieb Claus Ibsen: > On Wed, Aug 24, 2011 at 3:04 PM, Christian Schneider > wrote: >> So where do you propose to put them? >> >> 1. org.apache.camel >> 2. org.apache.camel.api.management >> > I propose to put them here, where they where already > 3. org.apache.camel.management > > These annotations are part of the management API in Camel and IMHO > should be in that package. > > > >> I propose to go with 2 and create an api package with subpackages so we can >> structure org.apache.camel better. In the long run I would like to also move >> the whole camel api into an api package to make it clearer but that will >> probably create too much incompatibility. >> >> Christian >> >> >> Am 24.08.2011 14:13, schrieb Claus Ibsen: >>> On Tue, Aug 23, 2011 at 12:38 PM, Christian Schneider >>> wrote: >>>> I wonder what our scope for the org.apache.camel.spi package is vs the >>>> org.apache.camel (API) package. >>>> >>>> I know two valid definitions for API vs SPI: >>>> >>>> 1) API interfaces are called by the user to invoke functionality of the >>>> framework. So API interfaces are implemented by the framework. SPI >>>> interfaces are implemented by the user to change functionality of the >>>> framework or for callbacks >>>> 2) SPI interfaces are for third party modules while API interfaces are >>>> for >>>> users >>>> >>>> So the current case for me is the new JMX annotations. Are they SPI >>>> interfaces or API interfaces? >>>> >>> They are API interfaces. Just like @Consumer, @Produce and any of the >>> other API Camel annotations we have. >>> Its just that these annotations is for management enabling your >>> business logic / custom components or whatnot. >>> >>> >>> >>>> So what is your opinion about the specific and the general case. >>>> >>>> As a side question: The org.apache.camel package has grown quite large. I >>>> think we should create specialized packages for it. As we are talking >>>> about >>>> the camel API org.apache.camel.api.* would be a good name in my opinion. >>>> So >>>> the questions are: Should we create such specialized packages? Should we >>>> move API parts there? Should we only use the new packages for new stuff? >>>> >>>> Christian >>>> >>>> >>>> -- >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> Talend Application Integration Division http://www.talend.com >>>> >>>> >>> >> >> -- >> -- >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> Talend Application Integration Division http://www.talend.com >> >> > > -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com