Modeling a Triangle, with a utility method to classify it

You need to pick a model, and stick with it. You have duplicated much of your logic at the static level and the instance level. Specific cases are the classify() instance method, and the classify(int,int,int) static method. There is no need for both.

Additionally, the logic split between the two validation methods isSaneArguments and isTriangle should all be in one method (I recommend isTriangle). There is no place you call them separately, so there is no reason to split them. isSaneArguments is a poor name anyway.... Finally, it's not exactly 'yoda conditions', but I prefer to do calculations on the left-side of a comparison operator like < or >. Bracing them makes it more readable in a chain of arguments...:

isTriangle(final int a, final int b, final int c) {
    // positive lengths, and sides that can meet
    return a > 0 && b > 0 && c > 0  && (a + b) > c && (a + c) > b && (b + c) > a;
}

The way your class is laid out lends itself to having static calls to get the properties of the triangles. It appears that the class is designed to regularly encounter invalid triangles, (hence Type.INVALID), so having a constructor throw an exception is unpleasant. I would make the constructor private, and do the validation outside the constructor, and would keep the methods static...

Note, classifyValidTriangle is public, but does no validation, (like the name says), this is odd.... to trust the caller that much. I would still expect validation of arguments, and an IllegalArgumentException if they are not met.

The classify method would also be better if written as an early-return mechanism, instead of holding the type variable....

Note that the actual Triangle instance does not do much, and there is no apparent purpose for it.

Neither your class, nor the embedded enum are public, this seems odd.

Finally, I rearranged the code to put the enum at the top, the static methods next, then the fields, and constructor:

public class Triangle {

    public enum Type {
        EQUILATERAL, INVALID, ISOSCELES, SCALENE
    }

    public static Triangle buildTriangle(int a, int b, int c) {
        if (isTriangle(a, b, c)) {
            return new Triangle(a, b, c);
        }
        throw new IllegalArgumentException("input values are not able to make a triangle");
    }

    public static Type classify(int a, int b, int c) {
        if (!isTriangle(a, b, c)) {
            return Type.INVALID;
        }
        if (a == b && b == c) {
            return Type.EQUILATERAL;
        }
        if (b == c || a == b || c == a) {
            return Type.ISOSCELES;
        }
        return Type.SCALENE;
    }

    private static boolean isTriangle(int a, int b, int c) {
        // positive lengths, and sides that can meet
        return a > 0 && b > 0 && c > 0  && (a + b) > c && (a + c) > b && (b + c) > a;
    }

    private final int a;
    private final int b;
    private final int c;

    private Triangle(int a, int b, int c) {
        this.a = a;
        this.b = b;
        this.c = c;
    }

}

I would restructure the Triangle class as follows

public class Triangle {

    public Triangle(int a, int b, int c) {
        // validation and instantiation
    }

    public static enum Type {
        EQUILATERAL {
            @Override
            boolean matches(Triangle t) {
                // check if the given triangle matches this type
            }
        },
        ISOSCELES {
            @Override
            boolean matches(Triangle t) {
                // check if the given triangle matches this type
            }
        },
        SCALENE {
            @Override
            boolean matches(Triangle t) {
                // check if the given triangle matches this type
            }
        };

        private static Type classify(Triangle t) {
            for (Type type : values()) {
                if (type.matches(t)) {
                    return type;
                }
            }
            throw new IllegalArgumentException();
        }

        abstract boolean matches(Triangle t);
    }

    public Type getType() {
        try {
            return Type.classify(this);
        } catch (IllegalArgumentException e) {
            throw new IllegalStateException(e);
        }
    }
}

Some points to note

1. The constructor should carry out all the validations so that once you get a Triangle object you have a valid triangle to work with
2. If you have a valid triangle there is no reason to keep the Type.INVALID type
3. The triangle classification logic is put into the Type enum itself for a better encapsulation
4. When uncertain I tend to make the access modifiers as private as possible

public static Type classify(int a, int b, int c) {
    if (!isSaneArguments(a, b, c) || !isTriangle(a, b, c)) {
        return Type.INVALID;
    }
    return classifyValidTriangle(a, b, c);
}

It's a classify function that takes a set of integers and if they're not all positive or they don't make a triangle then it's regarded as an invalid triangle.

Then you have an implicit else that works with a "valid" triangle.

It's basically begging for this addition:

public static boolean isValidTriangle(int a, int b, int c){
    return isSaneArguments(a, b, c) && isTriangle(a, b, c);
}

public static Type classify(int a, int b, int c) {
    if (!isValidTriangle(a, b, c)) {
        return Type.INVALID;
    }
    return classifyValidTriangle(a, b, c);
}

Additionally, for any three integers a b c, if a = 0 then a + b > c && a + c > b is false. Because that would imply that b > c and c > b. Thus I'd rename isTriangle to isValidTriangle, opposed to the function I described above.

Just a quick detail I haven't seen in the other answers:

if (!isSaneArguments(a, b, c)) {
    throw new IllegalArgumentException("All sides of a Triangle must be > 0");
}

First off, I don't really like the name isSaneArguments. But really, my point is that you shouldn't separate the validation logic from the message.

The information that failure of the validation means that either parameter was <= 0 is information that belongs inside the validation method because the caller should actually not know what exactly happened in that method.

A common approach would be

public void doSomething( int a, int b ) {
    checkArgumentsArePositive( a, b );

    // Do awesome stuff
}

public void checkArgumentsArePositive( int... arguments ) {
    for( int argument : arguments ) {
        if( argument <= 0 ) {
            throw new IllegalArgumentException( "Argument must be positive, but found " + argument );
        }
    }

}

Of course, there are many other ways to do this as well.

Others have already covered the major points, but here's an observation that make things a bit simpler. Within the constructor, you could sort the sides from smallest to largest. Your constructor could contain this:

int[] side = new int[3];
side[0] = a;
side[1] = b;
side[2] = c;
Arrays.sort(side);

Now checking for 0 (or negative length) sides is done like so:

if (side[0] <= 0) {
    throw new IllegalArgumentException("All sides of a Triangle must be > 0");
}

Checking for validity:

if (side[0]+side[1] <= side[2]) {
    throw new IllegalArgumentException("These sides cannot form a Triangle.");
}