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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- _________________________________________________________________ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
