Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Contributing a build output console parser



On 24 May 2011 19:15, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
On Tue, May 24, 2011 at 4:36 AM, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
I hope IErrorParserNamed interface is allowed to be extended and implemented by clients. It mandates subclasses to implement clone() method, but to my amazement that clone() will never be invoked for me because of the following piece of code in ErrorParserExtensionManager.

public static IErrorParserNamed getErrorParserCopy(String id, boolean isExtension) {
        IErrorParserNamed errorParser = isExtension ? fExtensionErrorParsers.get(id) : fAvailableErrorParsers.get(id);

      try {
            if (errorParser instanceof RegexErrorParser) {
                return (RegexErrorParser) ((RegexErrorParser)errorParser).clone();
            } else if (errorParser instanceof ErrorParserNamedWrapper) {
                return (ErrorParserNamedWrapper) ((ErrorParserNamedWrapper)errorParser).clone();
            }
        } catch (CloneNotSupportedException e) {
            CCorePlugin.log(e);
        }
        return errorParser;
    }

Instead of hardcoded type checks shouldn't it rather be

   try {
            if (errorParser instanceof IErrorParserNamed) {
                return (IErrorParserNamed) errorParser.clone();
            }
        } catch (CloneNotSupportedException e) {
            CCorePlugin.log(e);
        }
Did you try to compile your suggestion? It won't. Cloneable interface is different from normal ones, it actually does not define clone() method.

I don't know which Cloneable is normal to you, the one I am talking about is java.lang.Cloneable and yes it does not contain clone() method because it is present in Object class. Cloneble only indicates that the instance of the sub class can be cloned.

Priyadarshan


Andrew
 
Regards,
Priyadarshan

On 24 May 2011 01:35, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:
On 23 May 2011 17:28, Priyadarshan Gupta <priyadarshan.eclipse@xxxxxxxxx> wrote:
In our product every build is actually represented by a set/combination of [Project - Hardware config. - Build property]. The problem is we do not know when the build combination has switched and when to initialize our classes because all we get inside an error parser is the current line and ErrorParserManager (instantiated per build but contains only project information).

This is precisely the job of platform Build Configurations.  As it stands I think it's too late to make non-bugfix changes here for Indigo...

Cheers,
James

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev



Back to the top