You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de> on 2013/01/11 17:27:27 UTC
Automatically setting the UIMA code style in Eclipse
Am 11.01.2013 um 14:12 schrieb Thilo Goetz <tw...@gmx.de>:
> I don't, but that still doesn't make it a good idea. Have you tested
> what happens when you check this out on a different machine, with
> different settings, OS, etc?
No, I didn't explicitly test that.
> The .settings stuff is not meant to
> be shared with other people, period. I have seen this cause annoying
> errors too many times.
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.
The alternative would be to implement a Maven and/or Eclipse plugin to
fix that. Some googling revealed that people have done that already, but
there seem to be no publicly available implementations.
It could be considered to implement a Maven plugin which reads the JDT
settings, overrides certain keys and saves it again. Possibly this even
works without a special m2e plugin. If not, the jcasgen m2e plugin from
Steven might serve as a template. If possible, for me a m2e plugin should
be avoided, because those tend to require regular maintenance updates.
Cheers,
-- Richard
--
-------------------------------------------------------------------
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
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: Automatically setting the UIMA code style in Eclipse
Posted by Richard Eckart de Castilho <ec...@ukp.informatik.tu-darmstadt.de>.
Am 11.01.2013 um 15:03 schrieb Jörn Kottmann <ko...@gmail.com>:
> 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
eckart@ukp.informatik.tu-darmstadt.de
www.ukp.tu-darmstadt.de
Web Research at TU Darmstadt (WeRC) www.werc.tu-darmstadt.de
-------------------------------------------------------------------
Re: Automatically setting the UIMA code style in Eclipse
Posted by Jörn Kottmann <ko...@gmail.com>.
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.
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?
Jörn
Re: Automatically setting the UIMA code style in Eclipse
Posted by Thilo Goetz <tw...@gmx.de>.
On 11/01/13 17:27, Richard Eckart de Castilho wrote:
> Am 11.01.2013 um 14:12 schrieb Thilo Goetz <tw...@gmx.de>:
>
>> I don't, but that still doesn't make it a good idea. Have you tested
>> what happens when you check this out on a different machine, with
>> different settings, OS, etc?
>
> No, I didn't explicitly test that.
>
>> The .settings stuff is not meant to
>> be shared with other people, period. I have seen this cause annoying
>> errors too many times.
>
> 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.
>
> The alternative would be to implement a Maven and/or Eclipse plugin to
> fix that. Some googling revealed that people have done that already, but
> there seem to be no publicly available implementations.
>
> It could be considered to implement a Maven plugin which reads the JDT
> settings, overrides certain keys and saves it again. Possibly this even
> works without a special m2e plugin. If not, the jcasgen m2e plugin from
> Steven might serve as a template. If possible, for me a m2e plugin should
> be avoided, because those tend to require regular maintenance updates.
>
> Cheers,
>
> -- Richard
>