From dev-return-17506-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Apr 15 14:50:23 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 45568 invoked from network); 15 Apr 2007 14:50:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Apr 2007 14:50:21 -0000 Received: (qmail 16012 invoked by uid 500); 15 Apr 2007 14:50:21 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 15980 invoked by uid 500); 15 Apr 2007 14:50:21 -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 15931 invoked by uid 99); 15 Apr 2007 14:50:21 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 15 Apr 2007 07:50:21 -0700 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates 66.249.92.170 as permitted sender) Received: from [66.249.92.170] (HELO ug-out-1314.google.com) (66.249.92.170) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 15 Apr 2007 07:50:14 -0700 Received: by ug-out-1314.google.com with SMTP id 71so765803ugh for ; Sun, 15 Apr 2007 07:49:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=VA1tsrTLEDPZgNLohIATvBhfZiIkBC48K0QGLC0q2Bo9612XV26ekib5rHtke4LHhShS8zbsThhLf+EPaaPL6nwQ5rkPdqTPjCY2jEBt3EvqPTWpcGJ8GdizWRBamc6kSFU22QJLxjImiyDElzF7FBm5prbICxBd5QYS+g9WFaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=W068yYQkyxshrebj75FghSs6yDic6uovb+LPTqJaQLG1un4xo3QY8lyaGIOXMr0gy9MJs5qwuLERDcic8I6H6/7+1Fo2kWYaBuohQOh4LO27dQSv4xFf+60XLWOs4CNzxmf0YzSoP/HBdFu/TAS9zUMiOS0HnGD1MJV+3Ye150I= Received: by 10.67.32.19 with SMTP id k19mr3591012ugj.1176648592870; Sun, 15 Apr 2007 07:49:52 -0700 (PDT) Received: by 10.67.35.16 with HTTP; Sun, 15 Apr 2007 07:49:52 -0700 (PDT) Message-ID: Date: Sun, 15 Apr 2007 10:49:52 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: Re: [jira] Created: (DIRSERVER-900) Reduce the number of jars In-Reply-To: <461FF842.2000201@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30301_10889317.1176648592803" References: <7729883.1176492675448.JavaMail.jira@brutus> <461FF842.2000201@gmail.com> X-Google-Sender-Auth: 0bfd953232d3d867 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_30301_10889317.1176648592803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yeah I agree that we have two apposing things to engineer around. OSGi pushes to more jars and most users will want one for the whole project. I think we can achieve both goals with a little maven magic. We just need this before we start moving in the path of breaking up jars into more jars. It will be nice to just have a single assembly for ApacheD= S distributed with maven. I think the server-main was supposed to do this bu= t we're not uploading the assembly to the m2 repo but the compiled empty artifact. We definitely need to fix this project so users can just us it with one jar. Perhaps we might change it's name to best indicate this fact= ? WDYT about calling it something like apacheds-all or apacheds-complete? Alex On 4/13/07, Emmanuel Lecharny wrote: > > Alex Karasulu a =E9crit : > > > We're actually going to be going in the opposite direction with OSGi > > when we > > break things down into fine grained services. We may reach 100 jars > > if we > > do it right. > > I don't think that this direction is incompatible with another target, > which is a packaged version (and this is the target I was talking about > in this JIRA) > > > > > We can use an assembly to create one jar if that makes people > happy. But > > this JIRA is a waste considering our direction. > > Make people happy seems important to me :) > Just consider that micro-decision (like create an hundred of jars for > internal reasons) should not be opposed to macro-decision (packaging the > server in a couple of jars for people hapiness), but it's obviously > another task for us (vreating the pckages, managing them, ect...). > > I personnaly think that delivering a server composed of an hundred of > jars for technical reasons like OSGI, and to impose this choice to user > to be just a wrong move. Not that OSGI is the bad direction, but users > should not be aware of that if they don't want to be. > > Of course, I just express my very own opinion here, not the project > opinion. We will have to discuss this point, for sure ! > > Emmanuel > > ------=_Part_30301_10889317.1176648592803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Yeah I agree that we have two apposing things to engineer around.  OSG= i pushes to more jars and most users will want one for the whole project.&n= bsp; I think we can achieve both goals with a little maven magic.

We= just need this before we start moving in the path of breaking up jars into= more jars.  It will be nice to just have a single assembly for Apache= DS distributed with maven.  I think the server-main was supposed to do= this but we're not uploading the assembly to the m2 repo but the compi= led empty artifact.  We definitely need to fix this project so users c= an just us it with one jar.  Perhaps we might change it's name to = best indicate this fact?

WDYT about calling it something like apacheds-all or apacheds-compl= ete?

Alex

On 4/13/07, Emmanuel Lecharny < elecharny@gmail.com> wrote:
Alex Karasulu a =E9crit :

> We're act= ually going to be going in the opposite direction with OSGi
> when we
> break things down into fine grained services. = ; We may reach 100 jars
> if we
> do it right.

I do= n't think that this direction is incompatible with another target,
w= hich is a packaged version (and this is the target I was talking about
in this JIRA)

>
> We can use an assembly to create one = jar if that makes people happy.  But
> this JIRA is a waste= considering our direction.

Make people happy seems important to me = :)
Just consider that micro-decision (like create an hundred of jars for
in= ternal reasons) should not be opposed to macro-decision (packaging the
s= erver in a couple of jars for people hapiness), but it's obviously
another task for us (vreating the pckages, managing them, ect...).

I= personnaly think that delivering a server composed of an hundred of
jar= s for technical reasons like OSGI, and to impose this choice to user
to be just a wrong move. Not that OSGI is the bad direction, but users
s= hould not be aware of that if they don't want to be.

Of course, = I just express my very own opinion here, not the project
opinion. We wil= l have to discuss this point, for sure !

Emmanuel


------=_Part_30301_10889317.1176648592803--