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