ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <>
Subject Re: suggestion refactor SCM
Date Thu, 29 Sep 2005 01:02:01 GMT

On 29 Sep 2005, at 06:39, Brett Porter wrote:

> I'd also agree with that. We fully intended to make Maven2 plugins
> work as Ant tasks :)
> So with a wrapper,
> these goals would become tasks and their parameters would match up
> what's on the individual pages.
> Thoughts?

Just a worry about dependencies.  If Ant has to rely on other code  
from within maven for a set of maven plugins to run, we end up with a  
horrible interdependency (Maven needs Ant <-> Ant needs some % of  
Maven) just to compile ant.  Could get nasty.  But I agree if the  
work is there and the code can be taken and made common between  
projects, why not?

(When you first replied Brett, I checked out the source in svn web  
thingy and I saw a fair bit of codehaus imports - I personally don't  
have any good experience (as a user) of anything from codehaus so I'm  
wary of that code, but you obviously have a more in depth view)

> - Brett
> On 9/29/05, Trygve Laugstøl <> wrote:
>> On Wed, 2005-09-28 at 16:56 +0100, Jose Alberto Fernandez wrote:
>>>> From: Steve Loughran []
>>>> Jose Alberto Fernandez wrote:
>>>>> But here we seem to be talking about a new family of generic  
>>>>> tasks,
>>>>> If this works well, we could deprecate the old tasks and  
>>>>> eventually
>>> in a
>>>>> couple of versions remove them.

My thoughts were that in the future you'd download a base-ant, and  
then depending on the SCM you use you'd download the scm-provider- 


base-ant1.8.jar + svn-ant.jar

Each antlib is going to be tiny compared to the amount you have to  
download for all SCM functionality that we currently have (I'm still  
on dial-up here so download speed and size of code is important to  
me :) )

>>>> generic is good, provided
>>>>   -we can have a conceptual model that is consistent across all SCM
>>>> systems.
>>>>   -we can deal with extensibility through antlibs. I suppose  you'd
>>> have

The hard part is defining a consistent interface which is applicable  
to all SCM systems, without dropping down to lowest common denominator.

"In vain you tell me that Artificial Government is good, but that I  
fall out with the Abuse. The Thing! The Thing itself is the Abuse!" -  
Edmund Burke

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

View raw message