Am 11.01.2013 um 15:03 schrieb Jörn Kottmann <[email protected]>: > On 01/11/2013 05:37 PM, Thilo Goetz wrote: >>> I have seen issues to, that is why I am very careful in what I check in. >>> >If you don't mind too much, I'll leave it in for now and wait until people >>> >report actual problems. Although, I have to admit that mostly the issue >>> >was a dirty .settings directory upon checkout. >> You do what you think is best. I really don't care, I was >> just trying to be helpful. >> > > There are also other issues with that approach, the idea at Apache about > making > a source build is to just put the entire subversion trunk in there and people > usually > do not like to have IDE settings in the source release.
I didn't get to refactoring the release process of uimaFIT yet. The legacy release process uses the source artifacts produced by Maven, which do not contain the full sources. > Checking in the project settings also doesn't scale well, different people > often use different > IDEs, do we want to check in all these files for all the commonly used IDEs? It could be asked why UIMA offers only a code formatter configuration for Eclipse and not for other IDEs. The UIMA master POM still contains special settings for Eclipse. Several of the UIMA modules are actually Eclipse plugins. So there is a history of special support for the Eclipse environment. I also assume because of this, that the largest part of the UIMA developers use Eclipse, so getting the code base to work for them should be facilitated. Hence, I consider it a valid step to follow up on this behavior and provide special configuration files for Eclipse. Mind, I am the last person to advertise checking in IDE metadata into a project. But I am also practical and if necessary make exceptions to the rule. In the past, I had a look at Checkstyle - great, but it has no code formatter. I had a look at the Eclipse Maven plugin, which is has some support to add custom configuration files to a project [1]. Unfortunately, this is not supported by m2e, I just tried it. First, the Maven Eclipse plugin generates the settings file, then it appears to be overwritten by m2e with the Java compiler settings. The same thing does not happen when the files are checked out from SVN. The two files in SVN now are only the following two, other Eclipse files are svn:ignored. org.eclipse.jdt.core.prefs org.eclipse.jdt.ui.prefs These files contain: - the preference version number: eclipse.preferences.version=1 - the Java compiler settings which are generated by m2e based on the settings in the pom.xml: org.eclipse.jdt.core.compiler.codegen.targetPlatform=1.5 org.eclipse.jdt.core.compiler.compliance=1.5 org.eclipse.jdt.core.compiler.problem.forbiddenReference=warning org.eclipse.jdt.core.compiler.source=1.5 - the code style settings org.eclipse.jdt.core.formatter.* - the name and version of the formatter settings formatter_profile=_Apache UIMA Code Conventions formatter_settings_version=12 These configuration files are project-specific files that Eclipse overlays on the other workspace settings. For example, if you have different JavaDoc or Compiler warnings configured, these are not touched at all. I see little risk in having these files in SVN, because one part (the compiler settings) are basically already in SVN as well, just in the POM. Should we upgrade to Java 1.6 in the POM, it will quickly be noticed the prefs files being dirty upon Maven->Configure. The other part, the formatter settings, are mandated by UIMA. There are no other settings in these files. Risks are: - an Eclipse may not support certain settings because the settings in SVN were generated by a higher version of Eclipse. The likely result is that some settings are ignored. - an Eclipse version may support more settings than are present in the SVN prefs files. The likely results is a dirty file if Eclipse automatically adds some new lines. It is also possible that nothing will happen at all until somebody actually changes any of these project specific settings in Eclipse. - somebody may want to do other project specific settings that are stored in the JDT config files, such as the configuration of compiler warnings or javadoc warnings. The result will be a dirty file. There is some risk that this is checked in. All of these risks do not appear to be critical. I have all my projects in a single Workspace (many many projects) and different projects have different code styles. This is very convenient, because of m2e's feature of resolving artifacts in the workspace. To stick to a style, I consider a code formatter an essential tool, in particular because I don't have to explicitly remember the styles for each project. Eclipse does not support setting a code style on more than one project at a time (I also tried that), so for uimaj-core only, I have to go through ~30 projects and manually change the code style - on every check-out! This is highly inconvenient. I hope I could demonstrate that I didn't "just check in" these files, I did so based on my past experience with with due consideration. Could you give some advice on how you handle such situations? Cheers, -- Richard [1] http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html#additionalConfig -- ------------------------------------------------------------------- Richard Eckart de Castilho Technical Lead Ubiquitous Knowledge Processing Lab (UKP-TUD) FB 20 Computer Science Department Technische Universität Darmstadt Hochschulstr. 10, D-64289 Darmstadt, Germany phone [+49] (0)6151 16-7477, fax -5455, room S2/02/B117 [email protected] www.ukp.tu-darmstadt.de Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de -------------------------------------------------------------------
