On Friday 15 August 2003 05:36, Costin Manolache wrote:
> Stefan Bodewig wrote:
> > On Wed, 13 Aug 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> >> All this overriding may create some bad maintaince problems.
> >
> > I agree for overriding in arbitrary namespaces, but we have to keep
> > supporting it for the default namespace.
> >
> > We've added support for task overloading when Ant added a task with
> > the name <manifest> and FOP's build broke as they had a manifest task
> > of their own.  Without overriding, each new task in Ant could
> > potentially break build files.
>
> Namespaces are supposed to be a better/different solution for this problem.
>
> I agree we should keep overriding for the default namespace, for backward
> compat. But I don't think it is a good idea to support overriding in any
> other case, and the default namespace should have a strong warning that
> namespaces should be used instead of overriding.

The current code has a bug in this area:
I was porting from:
                int logLevel = Project.MSG_WARN;
                if (old.getName().equals(taskClass.getName())) {
                    ClassLoader oldLoader = old.getClassLoader();
                    ClassLoader newLoader = taskClass.getClassLoader();
                    // system classloader on older JDKs can be null
                    if (oldLoader != null
                            && newLoader != null
                            && oldLoader instanceof AntClassLoader
                            && newLoader instanceof AntClassLoader
                            && ((AntClassLoader) oldLoader).getClasspath()
                            .equals(((AntClassLoader) 
newLoader).getClasspath())
                    ) {
                        // same classname loaded from the same
                        // classpath components
                        logLevel = Project.MSG_VERBOSE;
                    }
                }

                project.log("Trying to override old definition of task " + 
taskName,
                        logLevel);

to:
                    int logLevel = Project.MSG_WARN;
                    if (def.getClassName().equals(old.getClassName())
                        && def.getClassLoader() == old.getClassLoader()) {
                        logLevel = Project.MSG_VERBOSE;
                    }
                    project.log(
                        "Trying to override old definition of task "
                        + name, logLevel);

This does not work for the new types of definitions (macrodef, presetdef, and
scriptdef), so I am thinking
of changing this to always do the warning (unless they are the same
definition as reported by the AntTypeDefinition).

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to