From dev-return-29104-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Tue Sep 11 02:06:05 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 61355 invoked from network); 11 Sep 2007 02:06:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Sep 2007 02:06:05 -0000 Received: (qmail 47379 invoked by uid 500); 11 Sep 2007 02:05:57 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 47353 invoked by uid 500); 11 Sep 2007 02:05:57 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 47344 invoked by uid 99); 11 Sep 2007 02:05:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Sep 2007 19:05:57 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of xu.regis@gmail.com designates 72.14.204.226 as permitted sender) Received: from [72.14.204.226] (HELO qb-out-0506.google.com) (72.14.204.226) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Sep 2007 02:05:53 +0000 Received: by qb-out-0506.google.com with SMTP id e6so1166116qbe for ; Mon, 10 Sep 2007 19:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=jkJICumjZLQVzYF1wozTyoOW6KGIJKaVwkm5oqrKnUM=; b=Xj96okcEgRBhSKleRjMjoVZECgnj6kgWop8ZHIKECphdrzjg9vy7+stTurQ2q1BxsGuL48pu6Nprk6LFTrB/JOjjzvwjLi7V0B2LfbgnQ9qIm/v+t57Oc/5du29VC+hwhgEtQmHnqqwtuXCp6a4kShIJlA2cs+G9vNU7yLU2b2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=C9JBxHfhqIkmbTThwGjd8RYSYZnTHMgZCm8RzGR79s2Z9ZRUP8eYKURgCsy0sQHq3yyQwqO+8cCuRyNHanR4TqUBgyE85n820YVt7rADK60Tca+yW7IZfOmESW7kL1a3MK6FTsL/W2G1nLCQsPifvJYT7qPasv+ai58stSFrq30= Received: by 10.141.180.5 with SMTP id h5mr2119745rvp.1189476332155; Mon, 10 Sep 2007 19:05:32 -0700 (PDT) Received: from ?9.181.107.81? ( [220.248.0.145]) by mx.google.com with ESMTPS id c20sm8995934rvf.2007.09.10.19.05.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Sep 2007 19:05:31 -0700 (PDT) Message-ID: <46E5F7E7.8060307@gmail.com> Date: Tue, 11 Sep 2007 10:05:27 +0800 From: Regis User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: Re: [classlib][ldap] Several development concerns about Ldap service provider References: <473c46620709061913q46454242lda362e7eb5f4c312@mail.gmail.com> <46E0E117.5020002@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Yang Paulex wrote: > does ApacheDS provides a separated binaries jars for these features > harmony needs? Or we need to build them oursleves? If it's latter Yes, there are separated binaries jars in maven repository at [1], it's up to date. we just need shared-ldap and shared-asn1 modules, which depends on antlr, commons-collections and slf4j, they also can be found in maven repository. [1] http://repo1.maven.org/maven2/org/apache/directory/shared/ Best Regards, Regis. > case, is it possible to separate these codes from other parts of > ApacheDS? > > On 9/7/07, Regis wrote: >> Spark Shen wrote: >>> We had some discussions[1] with developers in Apache DS community. And >> find >>> they have existing sharable classes. >>> >> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/ >>> These classes constitute 3 major features. >>> 1. codec - encode/decode ldap message >>> 2. filter - parsing search filters such as 'cn=*' >>> 3. schema - parsing schema >>> >>> I prefer to include them into our project instead of re-implement. >>> >>> We do have problems. So far, I can see at least 2 problems: >>> >>> 1. Dependency: How should we include those code from Apache DS. Using >> binary >>> jars as Yoko, or SVN external link as our concurrent module. >>> Both of the methods will have its pro & con. Binary form will involve more >>> manual efforts, while external link may potentially pollute our code base. >> I prefer to use binary jars, because the interface and methods we used >> should be stable, use SVN external link may make our code in unstable >> position. >> >> ApacheDS also depends on some jars, such as common-lang, antlr, if they >> can provide the whole package is the best. >>> 2. Code duplication: Apache DS have classes which will duplicate our code. >> A >>> simple example is LdapDN. Shall we adapt our implementation to their code? >>> Any comments? >> seems ApackeDS' implementation can't avoid, so we should use theirs as >> more as possible, if there is no way to avoid using both implementations >> simultaneous, adaptor would be helpful. >>> [1]http://www.nabble.com/-OT--Is-studio-using-Sun' >>> s-ldap-service-provider--t4376387.html > >