Eh. Isn't it fairly simple?

public class Widget extends JComponent {
   public static enum Alignment {LEFT, RIGHT, CENTER};
   ...
}

when only one class tree, Widget and descendants, uses the alignment,
and

public enum  WidgetAlignmemt {LEFT, RIGHT, CENTER}

when lots of independent FooWidgets occur that have an alignment of
this sort, and there's no compelling type-safety reason to treat each
type's alignment options as a separate type.

In particular, if FooWidget might add new alignment options in the
future irrelevant to the others it should use its own nested enum, so
we can add TOP_LEFT, TOP, TOP_RIGHT, BOTTOM_LEFT, BOTTOM, and
BOTTOM_RIGHT when it has two degrees of freedom someday without all
the others that are just aligning text needing to now detect bogus
values like TOP_LEFT and throw exceptions, or translate them to use
only the horizontal part.

Of course that might be done by instead having a VAlignment {TOP,
BOTTOM, CENTER} enum and modifying FooWidget to use one of each, too.
But it's not always so orthogonally decomposable...

If you mean more general with nested and inner classes, ordinarily you
nest only when the would-be nested class is only used together with (a
subclass of) the would-be nesting class rather than having independent
use, and you make an inner class only when it's something that it
makes sense to tie to an instance, such as iterators viewing a
particular collection instance.

You might nest them if they are used by only the enclosing class.  I
find though the enums tend to be popular and reused elsewhere, so I
tend to put them in a separate public or default class in their own
file.

Also too, I tend now to put more and more logic in the enums, and less
in the classes that use them.  It makes sense then to give them their
own file to grow in.

But the main reason is I can find them more easily then they are in
their own file.