Hi all,
I've been a long time user of Saros for Eclipse and am currently helping
Holger with feedback for the IntelliJ plugin. I am looking for feedback on
a feature suggestion.
One issue that we've come across in providing a minimally-usable Saros-I
plugin is which files to exclude from projects. For example, participants
in a session should not share .class files, the .classpath file, or version
control files (e.g. .git, .svn directories). To ignore files between
Eclipse participants, we've used a combination of "Resource Filters" and
marking files/folders as "Derived". These are both Eclipse-specific
features which result in Saros ignoring these files when negotiating a
session, or when edits occur within them. We initially thought we could
achieve the same effect by finding the equivalent feature in IntelliJ.
However, that approach has certain downsides:
- marking files as "Derived" is workspace-specific in Eclipse. Every
participant has to manually mark files as Derived in their own instance of
Eclipse, since the Derived flag can't be shared in a version-controlled
file. This becomes tedious and error prone.
- using "Resource Filters" has the advantage that you can save and store
the definition of filters, since they reside in the .project file. If you
use a build tool that generates the Eclipse config (Maven, Gradle, sbt) you
have to hook into the build process to populate this file (I have only seen
this work in sbt, I can't say how difficult it is in other build tools).
- there is inconsistency, because some files cannot be managed with
"Resource Filters", mainly, .classpath.
The best approach we've came across is to use Filtered Resources as much as
possible, and reminding ourselves to mark .classpath as Derived. We often
forget or the Derived flag is lost, which slows down getting a session
started.
For IntelliJ, I expect we could find the equivalent features, and manually
maintain excluded files outside of Saros. However, I think there's a better
approach, which is to read the "ignore" settings of local version control,
if available. I believe the semantics of ignore files match the semantics
of which files you would want to work together on with Saros. That is, the
overlap between the two definitions is meaningful, and not a coincidence.
This approach would have the following benefits:
- the ignore list for Saros is shared, reducing repeated effort as
participants don't each have their own steps to perform
- there's no incompatibility between a VCS ignore list, and build tools
which generate IDE configuration, so there's no need to hook into a build
tool and maintain that code
- there's no repetition of the files to exclude (many of our rules in
.gitignore are repeated in our Filtered Resources definition)
- it's IDE/editor independent, for example, a hypothetical NetBeans plugin
would share this definition and implementation.
- it makes it consistent when using heterogeneous editors, i.e. there's
less chance an Eclipse-using-participant will have an incompatible
configuration from an IntelliJ-using-participant.
There's also the following drawbacks:
- there would have to be an implementation within Saros for each version
control system supported, e.g. reading a .gitignore file is very different
from reading SVN's "svn:ignore" property.
- there are issues around the encoding of these files[0]. I don't yet see
why that would be an insurmountable problem. At the worst we could make a
best guess and fail-fast were we could detect inconsistency. The ignore
list could even be negotiated between participants after being read with
different encodings.
We have personally been happy (enough) to use the tedious, Eclipse-specific
way so far, but I think as Saros becomes available for more editors, this
would be a really nice feature to have.
Sorry for the wall of text. What do you think?
Kind regards,
Graham Allan
[0] http://sourceforge.net/p/dpp/bugs/790/
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
DPP-Devel mailing list
DPP-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
