No. Not the preference recorder. It’s the Project Configuration tool:
This has the org.eclipse.papyrusrt.umlrt.core project set as the “master” from which certain project-level preferences (in our case, formatting/compiler/clean-up/templates and such JDT experience) are pushed out to all other source projects. So the procedure to change these settings is: - Tweak the project-specific preferences of the org.eclipse.papyrusrt.umlrt.core project as needed.
- Let Oomph prompt you to push the settings to all of the other projects.
- Tell Oomph yes.
If the settings that you want to modify aren’t yet included in the set that are synchronized with the other Papyrus-RT source projects, then you need to do a bit more work on the synchronization model: hit the Edit… button in the preference page (it’s shown in the screenshot above) and do for those preferences as for the various JDT preferences that are already configured.
HTH,
Christian
On 21 June, 2016 at 16:39:45, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Is that the "Preference Synchronizer" and/or the
"Preference Recorder" that appears under
"Preferences->Oomph->Setup Tasks"?
Anyway, it's not clear to me then how could the formatting
preferences be modified for the whole project if we need to do
that.
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
_______________________________________________
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
|