ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: Ant 2 et al.
Date Tue, 09 Jul 2002 23:43:18 GMT
costinm@covalent.net wrote:
> On Wed, 10 Jul 2002, Conor MacNeill wrote:
> 
> 
> Is there any project in jakarta, built by gump, that uses this construct ?
> It seems most agree that 'build all that gump does' is acceptable
> backward compat.

Wow - is that your definition of backward compatability? Mutant is 
pretty much there already. We could probably even scrap the <script> 
task. We could probably even safely merge the property and reference 
namespaces.

It seems people talk up backward compatability until it gets in their way.

> 
> But even if some project uses this, it is trivial to use a command
> line option to use ProjectHelper instead of ProjectHelper2. 

<ant:import="test.xml"/>

We could also have the -mutant command line option. Splintering things 
up this way isn't the answer, IMHO.

> 
> If we want to support namespaces in a future version of ant - I would
> argue that any implementation ( including mutant/myrmidon ) would
> brake this. 
> 

Sure - Mutant is a backward compatability break point. It is known. Ant2 
has always been considered a backward compatability break point. Mutant 
aims for a practical level of backward compatability (i.e. Gumpable). 
This is what a major version number change is about.

>>Encapsulation is fundamental and Ant1 does not have it, severely 
>>complicating evolution. Nevertheless I do not hope to change your mind.
> 
> 
> Not sure what you mean by 'encapsulation'.

Current problems include: lack of private variables. No separation of 
facilities from core use and task use. No defined interfaces between 
tasks and the core facilities. Excessive coupling, low cohesion.

> 
> If it is indeed something usefull, and we agree on that - is there 
> anything to prevent adding it to ant1 ?
> 

backward compatability :-)

>>
>>So, some revolutions are necessary and liberate people from the yoke of 
>>tyranny :-) (Not thinking of Ant1, of course)
> 
> 
> I lived almost 20 years 'liberated' by a red revolution.  
> 
> 

And now? Another revolution perhaps?

Anyway, let's stick to code.

> 
> I already use ant tasks outside ant, and is not that difficult. 
> It can be simplified - and I hope this will happen in ant1.6, but it
> works fine. 

Let's look at trying to reuse <copy>. Using the classfileset to build a jar

<project name="test" default="test">
   <target name="test">
     <classfileset id="class.set" dir="build/classes">
       <root classname="org.apache.tools.ant.taskdefs.Copy"/>
     </classfileset>
     <jar jarfile="temp.jar">
       <fileset refid="class.set"/>
     </jar>
   </target>
</project>

Have a look at the jar - you need to provide 130 Ant classes. Javac 
requires 168 classes. Many of those classes require some initialization 
to be used.


> 
> 
>>For me the question has become whether it is worthwhile continuing to 
>>develop Mutant at all. If the broad consensus of the committers is to 
>>continue along the Ant1 evolutionary path then lets just say so. There 
>>is a lot of committers from whom nothing has been heard on these threads.
> 
> 
> I think it is worthwhile continuing to develop Mutant as long as 
> you want to try new ideas. 

Actually I want to stop supporting cruft.

Conor



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message