Hi, Ernesto,
The JDT preference files in the .settings/ folder of every project have the formatting and related settings implemented in various large XML blobs and suites of cleanup.* and org.eclipse.jdt.core.formatter.* properties.
It is not the Oomph Setup tooling that maintains synchronization of all of these project settings; it is the entirely separate Oomph Project Configuration tooling.
On 21 June, 2016 at 13:10:48, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
@Christian: Thanks. I don't see anything in the code bundle
that deals with formatting. Would the idea be to change that
bundle's preference file and Oomph could copy it to all other
bundles? Would that be specified in the setup model as a "Resource
Copy"? Does that support 1-to-n copy?
I agree that we should discuss the rules. I'll create a Google
Sheet and send the link.
@Bill: I'm all for using the default Eclipse style. I think at some
point it was decided to use the same style used in Papyrus, but I
do not know how it differs from the Eclipse style.
Change 68572 introduced the preferences in all projects.
What I do not know if there is a way to update the preferences for
all projects at once.
Anyway, If you use the latest version of the Oomph
installation for developers, by default the save actions will
format the code automatically.
In your particular case, you had to work on formatting because
your contributions were to the code generator, which was written in
a very different style (neither Eclipse nor Papyrus). So I'm
reformatting it precisely so that developers won't have to deal
with the same issues that you faced, and that auto-formatting could
take care of it.
Would be nice to
use the default Eclipse styling for Java. Although my
contributions thus far are minuscule, I spent more time on
formatting than coding.
>>> Ernesto Posse < eposse@xxxxxxxxxxxxx> 6/21/2016 11:14 AM
>>>
I'm reformatting the code generator to conform to the
checkstyle rules introduces, but I have found a few problems. In
particular, it looks like there are some inconsistencies between
what the formatting does and what checkstyle approves. For example,
I have an enum with several entries which is formatted in two
lines, but checkstyle complains that the first line is too
long.
There are other problems as well. I consistently run into a
warning saying that only one return statement is allowed per
method. This feels quite stringent.
Or the requirement that every attribute has a javadoc.
I was wondering if we could relax some of these rules.
I see that the the checkstyle rules are in releng/oeprt.oomph/checkstyle. But what if we
wanted to change some of the formatting rules? Would we have to
change every single .settings/org.eclipse.jdt.core.prefs file?
(I'd like to be able to write each enum entry in a separate
line without checkstyle complaining and without the autoformat
putting them in one line.)
--
Ernesto Posse
Zeligsoft
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
