Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 70236 invoked from network); 14 Sep 2010 11:25:12 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Sep 2010 11:25:12 -0000 Received: (qmail 72781 invoked by uid 500); 14 Sep 2010 11:25:11 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 72584 invoked by uid 500); 14 Sep 2010 11:25:09 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 72576 invoked by uid 99); 14 Sep 2010 11:25:08 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 11:25:08 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 14 Sep 2010 11:25:08 +0000 Received: (qmail 70117 invoked by uid 99); 14 Sep 2010 11:24:47 -0000 Received: from localhost.apache.org (HELO emmanuel-lecharnys-MacBook-Pro.local) (127.0.0.1) (smtp-auth username elecharny, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 11:24:47 +0000 Message-ID: <4C8F5C72.6070001@apache.org> Date: Tue, 14 Sep 2010 13:28:50 +0200 From: =?ISO-8859-1?Q?Emmanuel_L=E9charny?= Reply-To: elecharny@apache.org Organization: The Apache Software Foundation User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: API / shared merge References: <4C88F910.7010005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 9/14/10 12:39 PM, Alex Karasulu wrote: > Hi Emmanuel, Comments inline... >> Hi guys, >> >> it seems that when I did the big modification (merging all the Messages) >> last month, I forgot to uncomment the dsml-parser which is part of shared. >> >> I had it working by pointing to the ldap-api project, as it now depends on >> it, but that was not enough to be able to build it when uncommented in the >> shared/pom.xml file, as shared does not depend on ldap-api. >> >> However, in my mind, the next step was to integrate the ldap-api project >> into shared (well, imo, shared<==> ldap API up to a point). >> >> > For history sake, note that the shared project started first as a Maven > Module instead of a full on project at the same level as ApacheDS and > Studio. Then we converted it into a full project as we realized we wanted to > factor out more common code that can be reused. However originally shared > appeared to solve some issues we were having with Maven Module dependency > cycles. That was back when we were using Maven 1. Right now, those cyclic dependencies are gone. > >> Here is what I suggest we do : >> - move ldap-client into shared >> > Makes sense sine ldap-client will be reused (hence shared) by other projects > like Studio and ApacheDS. It's already done. >> - rename shared to ldap-api >> > Is everything that is in shared part of the ldap-api? Most of it. > Also note that we > might want a simple API jar/bundle with the public interfaces and perhaps > without connection providers so the implementation can be swapped in and out > as needed sort of like the JNDI provider architecture. Absolutely. I moved out any references to MINA in shared-ldap yesterday, but we still have some coupling in shared-asn1-codec. We might want to get rid of this coupling before releasing. At some point, we may want to use something else than MINA, or our users might want to do so. This was one part of the contract we wanted to establish with the Sun/OpenDS guys when we started working o the API, and I think it's still relevant. -- Regards, Cordialement, Emmanuel L�charny www.iktek.com