Question

We rely on Eclipse formatter in our project to enforce formatting conventions for us. It works great and we really like it.

We keep the formatter file with our project in source control and ask everybody to import this formatter to Eclipse. The only serious problem is that whenever somebody modifies the formatter and commits the change, then every team member needs to manually "reimport" the formatter. And it's easy to forget about doing it, so we often end up with using different versions of formatter among the team.

Is there any way to make Eclipse automatically use new version of formatter when the formatter file is updated? (I mean, could we just say to Eclipse "here's the path to formatter file, always use the current version of this file as a formatter"?) It would be great!

Any ideas?

Was it helpful?

Solution

Introduction

Formatter, Code Templates, etc. can be stored as project specific settings in the folder .settings/. You don't necessarily need to re-import the Formatter in your workspace.

You can use project specific settings in combination with svn:externals to "inject" the formatter, code templates, etc. in your projects.

svn:externals:

Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether.

Projects

  1. We have a java project named com.xyz.codeconventions where we added a project specific formatter and code templates. This project is under version control.
  2. For all the other projects we define a svn:externals property to "inject" the .settings/ folder from the project com.xyz.codeconventions (This is the folder where the project specific data is stored)
  3. If you now want to change the formatter you can edit the project com.xyz.codeconventions and use svn commit to submit the changes. The team will have to svn update on all projects to get the latest version of the code formatter.

Configuration

For all projects which should use this formatter you have to define a svn:externals property.

Example for com.xyz.project1:

key                   value
----                  ------
svn:externals         http://path/to/com.xyz.codeconventions/.settings .settings

In Eclipse (in my case Subversive) you can add svn specific properties with Team -> Set property....

Repository Layout

The repository structure in our case looks like this:

 <root>
   |
   +-- com.xyz.project1 # (svn:externals -> <root>/codeconventions/.settings .settings)
   |    |
   |    +-- src
   |    +-- <...> 
   +-- com.xyz.project2 # (svn:externals -> <root>/codeconventions/.settings .settings)
   |    |
   |    +-- src
   |    +-- <...> 
   +-- com.xyz.codeconventions
        |
        +-- .settings  # (this folder will get "injected" in project1 and project2)
             |
             +-- org.eclipse.jdt.core.prefs
             +-- org.eclipse.jdt.ui.prefs

Additional comments / Limitations

  • This approach is for svn users only but if you use git there is something similar to svn:externals named Submodules.
  • Make sure that in project1 and project2 are no .settings/-folder because with svn:externals it is not possible to overwrite existing files.
  • If you have java projects which need completely different formatters or different files in the .settings/ folder this approach is probably not what you are looking for. Our projects always have the same .settings files.

Sources

OTHER TIPS

If I understand your question correctly you want:

  1. All team members sharing the same checkstyle configuration
  2. All team members automatically on the latest version of the configuration after any changes

My guess is that each of you is importing the configuration manually into eclipse each time it is modified.

Instead of importing the file directly into eclipse, you can configure eclipse to use a remote configuration file.

eclipse checkstyle preferences

The configuration will apply to all projects under eclipse and will be up to date. The whole process is explained here Using common Checkstyle rules for teams. This requires all team members to setup eclipse once.

If you are using maven on the other hand, you can use the maven-eclipse-plugin to describe which checkstyle file to use. The configuration will be ready just by importing the maven project into eclipse.

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<version>2.8</version>
<configuration>
    <additionalBuildcommands>
        <buildcommand>net.sf.eclipsecs.core.CheckstyleBuilder</buildcommand>
    </additionalBuildcommands>
    <additionalProjectnatures>
        <projectnature>net.sf.eclipsecs.core.CheckstyleNature</projectnature>
    </additionalProjectnatures>
    <additionalConfig>
        <file>
            <name>.checkstyle</name>
            <location>${URL}/eclipse-checkstyle.xml</location>
        </file>
    </additionalConfig>
</configuration>
....

You can see the full details of the maven configuration in the following article Maven Checkstyle and Eclipse

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top