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?
请先登录再写评论。
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:
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.
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.