ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject Re: maven dependence tasks for ant
Date Tue, 26 Apr 2005 09:41:14 GMT
Brett Porter wrote:

>I thought I'd pipe up and make some clarifications here...

>Sorry, but no. We had similar tasks probably a year and a half ago,
>but they got stale so they were removed until we got closer to a real
>maven2 release. We got a bit preoccupied so they've been done after
>that release. It's probably not the only parts of Maven that we will
>release Ant tasks for.
>As Steve pointed out, we've also been discussing some of this stuff at
>, and I'd be interested in anything we can do to
>make it compatible with the libraries work for Ant 1.7
I think that honestly a lot of people were waiting for such a start 
(inconsciously or not), so kudos to you for taking the responsability.

>Following that, the Ivy developers worked with us on the Maven dev
>list for a while. This was of benefit to them, in that we have >8600
>artifacts, and they have ~40 and a lot of work to do :) My motivation
>is obviously to get the combined efforts in building metadata up put
>into one place. While I disagree, Xavier doesn't think that the Maven
>metadata is sufficient for their needs, so it's fine for them to do
>their own thing. I'm sure people will use both quite happily.  

>Yeah, I'm surprised this is getting so much attention - its just a
>regular Maven rant which is quite common. In summary his problem was
>that his tests leaked memory and Maven only has fork every time
>(slow), or don't fork (chews memory, and can give LinkageErrors with
>XML parsers, as explained in the Maven FAQ).
>I guess it should motivate me to release Maven 1.1 which finally
>includes Ant 1.6 and set forkmode=once as the default and be done with
>it... :)
It goes a bit beyond this. Really...

Personally, I don't agree much about the concepts of remote (I mean 
internet here) repositories because it is insufficient for real work use 
and this leads to too many problems IRL due to volatility of 
repositories. The Maven cache is also not helping here because it 
insulates the developpers working on the project from what reality and 
you are just reproducing the 'works for me' and 'build by coincidence' 
thingy that you try to avoid at all cost otherwise. Continuous 
integration here makes sense if you just delete the cache for each build...

Frankly (and this is no fud at all it is real experience...) I have 
rarely been able to checkout a mavenized project from scratch and build 
it simply because of the repo problems that simply were hidd

About the repos, It would make even more sense to have the repo checked 
in in the cvs least you have the jars visible.

The biggest problem in dependency management within a project, is that 
you don't get to code without an API (javadoc) and you cannot debug 
without sources as well (if you have the sources), so you need the 
distribution. And the biggest challenge to me is not to put a binary in 
some place with a standardized name, but a complete distribution package 
with a standardized layout so that you will be able to use for your 
IDE...or for your source control...because you simply need it. It is 
part of a project lifecycle.

Now also, if the metadata could make use of xml attributes where it 
makes sense rather than xml elements only and avoid this weird name 
syntax, that would make it much more readable. Ivy wins hands down here. :)



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message