Here are some issues (present in the latest RC build) that I think should
be candidates to fix before release.
1) New...Spring config (IDEA-15220)
If I don't want to add the new file to any set, I have to select the empty
label "". Surely something like "" could be used instead?
In addition, the default settings of the dialog will add the file to the
first fileset defined for the facet. I think a default of ]]> would be
2) Facet configuration (IDEADEV-20737)
The Spring facet provides a way to define a hierarchical structure for Spring
filesets, by specifying a parent fileset.
However, the feature is labeled "Dependencies". I'm pretty sure that:
-some users will just add other filesets there in an attempt to "link things
together", and end up with unexpected behavior
-others will be confused by the reuse of the term "Dependencies" as used
in "module dependencies"
In addition, the feature allows one to specify multiple parent filesets,
something that Spring itself doesn't support. Using a combo box (instead
of a list of checkboxes) would disallow definition of such impossible relationships.
3) Hard coded string literal inspection (IDEA-14074)
IDEA recognizes the use of propety placeholders. However, uses of literal
string properties in spring config files are marked with a "Hard coded string
In practice it's perfectly normal to have such 'hard-coded' values in the
spring xml. Extracting values to properties files only makes sense for settings
that differ between deployments.
The QuickFix provided by this inspection is very nice, but the feature should
be delivered as an intention instead.
The current implementation will present new users with a lot of 'yellow',
4) Insert..dependency (IDEADEV-21439)
The "insert..dependency" generate actions are available for all Java classes.
When running it for a Java class that is never declared as spring bean, IDEA
inserts a bean declaration in a random(?) spring xml file.
In general, I think it's good to keep "generate" menu as short and context-aware
as possible. So I think it would be better to only show it when the current
class is used as a spring bean.
Of course, determining if the current class is used as a bean can be expensive
in terms of performance.
Perhaps the best solution would be to only show this action inside spring
xml: that would retain 99% of the functionality, while also side-stepping
the confusing scenario of injecting a dependency into a class that is used
as a bean more than once (in different filesets).