From dev-return-18807-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed May 23 15:40:57 2007 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 32915 invoked from network); 23 May 2007 15:40:56 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 May 2007 15:40:56 -0000 Received: (qmail 3672 invoked by uid 500); 23 May 2007 15:41:01 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 3633 invoked by uid 500); 23 May 2007 15:41:01 -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 3622 invoked by uid 99); 23 May 2007 15:41:01 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2007 08:41:01 -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.172 as permitted sender) Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2007 08:40:54 -0700 Received: by ug-out-1314.google.com with SMTP id o4so105887uge for ; Wed, 23 May 2007 08:40:32 -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=USiXmhdRI4BZP1HozUEc2JwIO26JrYEcdhX+tmpoovk2WeRKIxs36oqPkD9chvEsQ5xtH4wVj9iVJ+9P6ZKJNGb/iE5VnyaK7NrO/NNMjVEKgJdy/hcCPXptqE61MgJLwAfS20SyigW6rHWJ1o93w9uONzqlIK6wS/qr29xD+Ms= 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=JSE0ua2Vcp2RRxo0YQtBf3a5R373nSZHzbR1DuyhylOxZDc6v/O2nvPJHaFsx4U30s5uJIaujzNRHHjq3M7dY9JagvT2YotutSswDM/uGByXMf0M13ybTf/lLeXOrBQ1p5ZuBbNx5K+Wmu5mc3bvRv1enaPLDh0uLnauW8BULGY= Received: by 10.142.109.16 with SMTP id h16mr12306wfc.1179934830058; Wed, 23 May 2007 08:40:30 -0700 (PDT) Received: by 10.142.77.21 with HTTP; Wed, 23 May 2007 08:40:30 -0700 (PDT) Message-ID: Date: Wed, 23 May 2007 11:40:30 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" , elecharny@iktek.com Subject: Re: [VOTE] Policy for Managing TLP POM In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7353_28143057.1179934830023" References: X-Google-Sender-Auth: 6fffb78fba5824b2 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_7353_28143057.1179934830023 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think with this mess it is critical to take issues one step at a time instead of mixing everything together. I started with the root pom because this is the first step in a top down approach which IMO is the best way to procede because it effects the levels below it. The scope of this is so large that we cannot afford to jumble up all the problems together. Let's start at the top and work ourselves down. Perhaps several passes are required to figure out the ultimate configuration for both SVN and Mave= n but it must be done in peices. Either this or I can take the lead and just clean it all then document it. However I'm trying to involve others to make this a collaborative process. However to make the collaborative process work we need some focus on each issue first in isolation then within the big picture. Otherwise this is not going to succeed or result in an even more convoluted mess. Alex On 5/23/07, Emmanuel Lecharny wrote: > > I forgot to add two points : > - we need to bring back to the root data like resources/format.xml, so > that committers can use it > when writing code ( I hated having to browse dozens of directories to > find it last night ...) > - we also have to figure what could happen to next release (2.0, 3.0) > regarding this common POM > > What about creating a new project which allow users to compile the > whole project (apacheds + kerberos + daemon + shared) ? Note that > kerberos is *not* a project right now, as it is embedded into ads, but > it might be a good idea to separate it from ADS (not sure this is > possible though ...) > > Thanks ! > > Emmanuel > > On 5/23/07, Emmanuel Lecharny wrote: > > I will abstain right now, (make it -0), not that I find your proposal > > insane, but I have some suggestion and concerns that should be > > addressed : > > > > - let's document the actual hierarchy of the project in confluence. We > > have done that once upon a time, it's now time to do it again, would > > it be for Chris only ... > > - we should document the content of this pom on confluence, > > - keep this pom as simplest as possible > > - remove the branch and trunk section of > > http://svn.apache.org/viewvc/directory/tlp-common, just keeping the > > release (this is a proposal, I'm not 100% sure this is the perfect > > idea) > > - I don't really understand the "3. Do not copy the TLP POM in SVN". > > If it means we will just push the TLP pom to maven repo, then it can > > become a pb. I would rather prefer respect my previous point > > - applying this policy to the project means we will need some script > > to build ADS as a whole. It will be a versy simple script, building > > shared, daemon, kerberos and then apacheds. Otherwise, it will be > > painfull for users ... > > - I also have a little concern about Eclipse generated files. If we > > don't have the possibility to generate them with a common pom, then > > fdebugging will start to become a big issue, if we have to grab the > > sources from jars instead of projects : you will be asked for those > > sources when entering in shared for instance. This is not something I > > would like to do, as I'm quite involved in shared ... > > > > Ok, this points may not be valid, but at least we should discard them > > before going farther ! > > > > Thanks Alex for having created this page, and for having endorsed the > > task. It's obviously someting we should have done before, but there is > > no better time to do it than as fast as possible ... > > > > btw, this page exists because yesturday we tried to cut the 1.0.2 > > release, and it went into a quagmare, as I lacked some background to > > understand the way release are to be generated. See this effort as a > > clarification usefull for any committers who will be in charge of > > cutting a release in the near future :) > > > > -- > > Regards, > > Cordialement, > > Emmanuel L=E9charny > > www.iktek.com > > > > > -- > Regards, > Cordialement, > Emmanuel L=E9charny > www.iktek.com > ------=_Part_7353_28143057.1179934830023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I think with this mess it is critical to take issues one step at a time ins= tead
of mixing everything together.  I started with the root pom be= cause this is the
first step in a top down approach which IMO is the bes= t way to procede because
it effects the levels below it.

The scope of this is so large th= at we cannot afford to jumble up all the problems
together.  Let&#= 39;s start at the top and work ourselves down.  Perhaps several passes=
are required to figure out the ultimate configuration for both SVN and = Maven but=20
it must be done in peices.  Either this or I can take the lead and= just clean it all
then document it.  However I'm trying to inv= olve others to make this a collaborative
process.  However to make= the collaborative process work we need some focus on
each issue first in isolation then within the big picture.  Otherw= ise this is not going to
succeed or result in an even more convoluted me= ss.

Alex
On 5/23/07, Emmanuel Lecharny <elecharny@= gmail.com> wrote:
I forgot to add two points :
- we need to bring back to the root data li= ke resources/format.xml, so
that committers can use it
when writing c= ode ( I hated having to browse dozens of directories to
find it last nig= ht ...)
- we also have to figure what could happen to next release (2.0, 3.0)regarding this common POM

What about creating a new project which = allow users to compile the
whole project (apacheds + kerberos + daemon += shared) ? Note that
kerberos is *not* a project right now, as it is embedded into ads, but<= br>it might be a good idea to separate it from ADS (not sure this is
pos= sible though ...)

Thanks !

Emmanuel

On 5/23/07, Emmanu= el Lecharny < elecharny@gmail.com> wrote:> I will abstain right now, (make it -0), not that I find your proposa= l
> insane, but I have some suggestion and concerns that should be > addressed :
>
> - let's document the actual hierarchy = of the project in confluence. We
> have done that once upon a time, i= t's now time to do it again, would
> it be for Chris only ...
> - we should document the content of this pom on confluence,
>= ; - keep this pom as simplest as possible
> - remove the branch and t= runk section of
> http://svn.apache.org/viewvc/directory/tlp-common, just keeping the
= > release (this is a proposal, I'm not 100% sure this is the perfect=
> idea)
> - I don't really understand the "3. Do not = copy the TLP POM in SVN".
> If it means we will just push the TLP pom to maven repo, then it c= an
> become a pb. I would rather prefer respect my previous point
= > - applying this policy to the project means we will need some script
> to build ADS as a whole. It will be a versy simple script, buildin= g
> shared, daemon, kerberos and then apacheds. Otherwise, it will be=
> painfull for users ...
> - I also have a little concern abou= t Eclipse generated files. If we
> don't have the possibility to generate them with a common pom,= then
> fdebugging will start to become a big issue, if we have to gr= ab the
> sources from jars instead of projects : you will be asked fo= r those
> sources when entering in shared for instance. This is not somethin= g I
> would like to do, as I'm quite involved in shared ...
&g= t;
> Ok, this points may not be valid, but at least we should discard= them
> before going farther !
>
> Thanks Alex for having crea= ted this page, and for having endorsed the
> task. It's obviously= someting we should have done before, but there is
> no better time t= o do it than as fast as possible ...
>
> btw, this page exists because yesturday we tried to cut th= e 1.0.2
> release, and it went into a quagmare, as I lacked some back= ground to
> understand the way release are to be generated. See this = effort as a
> clarification usefull for any committers who will be in charge of<= br>> cutting a release in the near future :)
>
> --
> = Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com
>


--
Regards,
Cordialement,
Emm= anuel L=E9charny
www.iktek.com
<= /blockquote>

------=_Part_7353_28143057.1179934830023--