How about separate, specific Seam inspections?

IMHO a single inspection "Seam Components Model Inspection" isn't a good idea.

I propose to have separate, specific inspections like "Undefined context variable"
or "Seam magic on illegal class" (e.g. trying to use bijection in entity beans), ...

First when browsing the inspections that gives Seam newbies (and not so newbies) a
good overview about the rules that Seam applies.

Then if an inspection triggers you can see a much more useful inspection description
because it describes exactly the single mistake that you made.

Also, you can disable just specific inspections (e.g. "Use of Seam extended EL") if
your code guidelines call for that.

Finally it's also cleaner to have any needed options placed at the appropriate
inspection, e.g. for inspection "Explicit new on Seam component class" there could be
an option "ignore for test sources".

What do you think?

3 comments
Comment actions Permalink

Oh well, I just found out that there are in fact several other Seam related inspections.
However I think they should all be in a single "Seam" category, not partially mixed into "Java EE issues".

Still the "Seam Components Model Inspection" should probably be split into multiple inspections.

BTW: What I have played with so far looks very, very nice - even EL validation, completion
etc. is enabled inside EL expressions in @In. Way cool.

Stephen Friedrich wrote:

IMHO a single inspection "Seam Components Model Inspection" isn't a good
idea.

I propose to have separate, specific inspections like "Undefined context
variable"
or "Seam magic on illegal class" (e.g. trying to use bijection in entity
beans), ...

First when browsing the inspections that gives Seam newbies (and not so
newbies) a
good overview about the rules that Seam applies.

Then if an inspection triggers you can see a much more useful inspection
description
because it describes exactly the single mistake that you made.

Also, you can disable just specific inspections (e.g. "Use of Seam
extended EL") if
your code guidelines call for that.

Finally it's also cleaner to have any needed options placed at the
appropriate
inspection, e.g. for inspection "Explicit new on Seam component class"
there could be
an option "ignore for test sources".

What do you think?

0
Comment actions Permalink

Hi Stephen,

thank you for feedback.

You're right. Seam inspections have to be splitted as minimum it was made
in your plugin :)
The fact that the first seam eap was concentrated to support main idea's
refactorings, completions and etc.
Writing and refactorings of seam inspections are planned.
Could I use descriptions and inspections of your plugin to bundle them in
Idea's seam support?


Serega.


IMHO a single inspection "Seam Components Model Inspection" isn't a
good idea.

I propose to have separate, specific inspections like "Undefined
context variable" or "Seam magic on illegal class" (e.g. trying to use
bijection in entity beans), ...

First when browsing the inspections that gives Seam newbies (and not
so newbies) a good overview about the rules that Seam applies.

Then if an inspection triggers you can see a much more useful
inspection description because it describes exactly the single mistake
that you made.

Also, you can disable just specific inspections (e.g. "Use of Seam
extended EL") if your code guidelines call for that.

Finally it's also cleaner to have any needed options placed at the
appropriate inspection, e.g. for inspection "Explicit new on Seam
component class" there could be an option "ignore for test sources".

What do you think?



0
Comment actions Permalink

Sure, you are absolutely free to use whatever makes sense - just don't blame me for any bugs that may exist ;)

The main issue with my plugin was that it only considered annotations and did not parse component definitions from xml. Apart from that the inspections should be quite usable.
And as far as I can see you already have the model part covered very nicely for both annotations and xml.

0

Please sign in to leave a comment.