Additional UnitTest and KSSQL plugin feature request

Hello Jacques, hello Stefan,

we are working on a mid-size application with a team of
10 developers. Most of them are using IntelliJ.
We do store the project and module files (*.ipr, *.iws)
in the CVS. The workspace files (*.iws) however are not
shared via CVS, because they generally contain personal
setting like window positions, the edit history and so
on. Additionally, the workspace file can contain absolute
paths which may or may not exist on the machine where the
checkout is done.

Sadly, both the UnitTest plugin and the KS-SQL plugin do
store some settings in the workspace file which we actually
want to survive check-in / clean / check-out cycles.

UnitTest for example stores the patterns that determine
the class name / testcase name mapping in the iws file.
Isn't this information conceptually part of the project
and should thus be stored in the ipr file?
More or less the same applies to UnitTest's template settings
and options. This stuff should either be part of the project
settings (because they should be consistent among all developers)
or eventually be some kind of global configuration (like the
file templates itsself are).

With KS-SQL we are unable to share database definitions
and driver settings among the team. Both are lost each time
the developer fetches a fresh copy from the cvs. Storing
the database definition in the project settings is obviously
for security reasons not a good idea but there should be the
possibility to define "global" database configurations, similar
to the concept of global libraries. That would make the sql
plugin even more usable in scenarios with many small sub-projects
(because the developer could quickly choose a global database
definition instead of reconfiguring the same settings again and
again).

Last, but not least, a big Thank You! for both plugins. They
help us quite a lot with our daily development tasks.

Matthias

3 comments
Comment actions Permalink

Hi,

I've already thought about moving at least a part of the configuration into
the application settings and will probably do this in one of the next releases.
But I don't know if this will completely solve your problem as the settings whould
be saved together with other configurations into config\options\other.xml.

Stefan.

8859_1 wrote:

Hello Jacques, hello Stefan,

we are working on a mid-size application with a team of
10 developers. Most of them are using IntelliJ.
We do store the project and module files (*.ipr, *.iws)
in the CVS. The workspace files (*.iws) however are not
shared via CVS, because they generally contain personal
setting like window positions, the edit history and so
on. Additionally, the workspace file can contain absolute
paths which may or may not exist on the machine where the
checkout is done.

Sadly, both the UnitTest plugin and the KS-SQL plugin do
store some settings in the workspace file which we actually
want to survive check-in / clean / check-out cycles.

UnitTest for example stores the patterns that determine
the class name / testcase name mapping in the iws file.
Isn't this information conceptually part of the project
and should thus be stored in the ipr file?
More or less the same applies to UnitTest's template settings
and options. This stuff should either be part of the project
settings (because they should be consistent among all developers)
or eventually be some kind of global configuration (like the
file templates itsself are).

With KS-SQL we are unable to share database definitions
and driver settings among the team. Both are lost each time
the developer fetches a fresh copy from the cvs. Storing
the database definition in the project settings is obviously
for security reasons not a good idea but there should be the
possibility to define "global" database configurations, similar
to the concept of global libraries. That would make the sql
plugin even more usable in scenarios with many small sub-projects
(because the developer could quickly choose a global database
definition instead of reconfiguring the same settings again and
again).

Last, but not least, a big Thank You! for both plugins. They
help us quite a lot with our daily development tasks.

Matthias

0
Comment actions Permalink

Storing settings in config/options.xml would be quite ok.

The important difference to the current implementation
is that the "global" configuration is a one-time job that
could even be automated with non-IntelliJ-Tools (or maybe
with import/export settings feature, which I haven't tried yet).

The actual solution forces the developer(s) to re-enter
the settings for each project. With our setup (we
don't store iws files) it's even worse: the settings
are lost whenever a fresh copy of the project tree is
fetched from CVS.

Matthias

0
Comment actions Permalink

I will put that in my todo list.
However the solution for the unittest plugin is not as simple as the great sql plugin. test patterns are usually very tied to the project they apply to. Originally they were stored in the project file. The problem with storing any config in the project file is the constant thrashing of the ipr unless everybody on one team is using the exact same version of every plugins (IDEA will replace the old version or just remove it if the plugin is not present!). If you check in the project file under this condition it is hell!
So now it is in the workspace file so it won't get checked in but still allows a per project config. This is critical because not every project that one might work on follow the same patterns. I for example do my own personal projects (obviously my plugins and other os projects) in addition to my work. work projects and os projects have different patterns. Even between os projects it might different. So this is the reason they can't be stored globally either.
I believe a reasonable solution was implemented by Dave Kriewall in his great Rearranger plugin: config are stored in the workspace file but you can save them to and load them from an external file that you can then check in.

Would that work for you?

Jacques

0

Please sign in to leave a comment.