commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Diggory <mdigg...@gmail.com>
Subject Re: [httpclient] Jars in the repository
Date Tue, 05 Apr 2005 21:48:59 GMT
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


Mime
View raw message