Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <42539EED.8050807@nose.ch>
Date: Wed, 06 Apr 2005 10:33:49 +0200
From: =?ISO-8859-1?Q?Ortwin_Gl=FCck?= <ortwin.glueck@nose.ch>
Organization: NOSE Applied Intelligence
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [httpclient] Jars in the repository
References: <08c601c539df$5a479ca0$6602a8c0@auburn>
 <42528D6E.1030600@nose.ch>	 <0a7b01c539f6$ae779de0$6602a8c0@auburn>
	 <20050405162053.GA25189@xbox.localdomain>
 <4252BC06.1080703@nose.ch>	 <20050405163349.GA25214@xbox.localdomain>
 <4252C386.7010507@nose.ch> <16d6c6200504051304a96b17@mail.gmail.com>
 <425307CB.8060909@gmail.com>
In-Reply-To: <425307CB.8060909@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Mark,

You are making some interesting points.
First, I hear that ibiblio is supposed to be *stable*. That is good to 
hear (any guarantees about this, btw?). So this eliminates my reasoning 
and I am happy to remove the deps from SVN.

Second, I understand that using Ant or Maven is a matter of personal 
preference. While Maven may be difficult to use in some projects it does 
a perfect job for HttpClient. People like Oleg seem to find Maven more 
difficult than Ant, which I can understand given the sheer zoo of 
plugins available for it. Personally I have gotten very familiar with 
Maven and have used and liked it since.

You mentioned the "maven ant" goal. I had never tried it before and I 
just gave it a spin. The result is not really usable though. The 
build.xml starts off with all kind of properties that contain local path 
names and there is no property file tag before those definitions! 
Checking in such a build.xml would not help anybody. Dennis mentioned a 
patch for the ant plugin. As long as it is not in the standard Maven 
distribution this is no option either.

Oleg, for the moment I take the freedom to veto against including 
dependency management into the build.xml, because it can not be done 
automatically. I am happy to provide more xdocs on how to deal with 
Maven if necessary (just referring to the right places in the Maven 
docs) and try my best to be a good replacement for Dion. I am convinced 
though, that it is right to remove the deps from SVN. And, yes I also 
think time is better spent on the new architecture. I will Mavenize the 
new code base as well, of course.

I hope this serves everybody.

Ortwin Gl�ck

Mark Diggory wrote:
> Martin Cooper wrote:
> 
>> On Apr 5, 2005 9:57 AM, Ortwin Gl�ck <ortwin.glueck@nose.ch> wrote:
>>  
>>
>>> Oleg Kalnichevski wrote:
>>>   
>>> 1. The libs are in the repo for a *reason*: availability and
>>> convenience. If you remove them we loose this availability and
>>> convenience. Replacing them with a stupid download script makes thinks
>>> worse, not better.
>>>
>>>   
> 
> First, its important to point out that the ASF and Maven jar 
> repositories (http://www.ibiblio.org/maven and 
> http://<apache_mirror>/dist/java-repository) represent a stable tool for 
> the development community to resolve dependencies against, ibiblio and 
> ASF mirror servers are certainly stable enough to maintain this. If your 
> a project developer you have to be more intelligent than your users, its 
> important that you know how to manage your dependencies appropriately. 
> The SRC/BIN distributions of your project are the appropriate places to 
> include these dependencies, not the CMS. Those who make points on the 
> list about replication of dependencies in the repo are correct in their 
> argument, this is why we don't recommend it. I think you'll find the ant 
> scripts generated by maven are reliable and not "stupid" at all in 
> resolving this issue.
> 
>>> 2. We don't need an additional Ant target to download deps. It
>>> duplicates knowledge from the project.xml.
>>>   
> 
> Its there to provide the same functionality for developers who prefer to 
> work directly with Ant and not Maven. Yes, its a duplication of the 
> maven project xml. But you can regenerate it at any time using the 
> 'maven ant' goal. Thus, you do not have to maintain both an ant 
> build.xml and a project.xml. The ant build.xml is a derivative product 
> of Maven that you store in your svn project (instead of megabytes of 
> dependency jars).
> 
>>> I don't want to maintain
>>> knowledge twice. This is error prone. Remember we had out-of-date docs
>>> regarding deps recently? Maven can download the deps that are listed in
>>> project.xml. Nobody needs Ant when there is Maven. Ant is legacy. You
>>> could write a Maven goal to generate the Ant script from the
>>> project.xml. But this is stupid as can be, isn't it? As I said, all we
>>> need is Maven, not Ant.
>>>   
> 
> 
> As I said above, this is already is available in Maven, you don't need 
> to write anything. Just call "maven ant" anytime you've altered the 
> project.xml and commit the two together. Any error in our group have 
> been minimal. Ant may be legacy, but Ant and Maven have a good 
> relationship and incredibly, much of what Maven does is actually based 
> on Ant Tasks. Ant is by no means past is prime.  The entire rest of 
> jakarta commons (among many other apache projects) have relied on this 
> dualistic model without complaint.
> 
>>> 3. If anybody of ASF has a problem with the libs being in the repo, we
>>> can remove them today. Fine with me. There is no absolute need they are
>>> there. (If you though they need to be there because your IDE requires
>>> them in the project directory, you are wrong: Just look at Maven's
>>> eclipse goal.)
>>>
>>>   
> 
> I think it totally defeats the general policy of external dependency 
> resolution to allow jars into svn just because you want them to show up 
> in your lib dir.
> 
> -My $0.02
> Mark Diggory
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-- 
  _________________________________________________________________
  NOSE applied intelligence ag

  ortwin gl�ck                      [www]      http://www.nose.ch
  software engineer
  hardturmstrasse 171               [pgp id]           0x81CF3416
  8005 z�rich                       [office]      +41-1-277 57 35
  switzerland                       [fax]         +41-1-277 57 12

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org