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 22:14:05 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