Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Code formatting and checkstyle rules
Hi, Céline, Philip,

For what it’s worth, the size of the project doesn’t matter if you use the Oomph Project Configuration Management tooling to maintain settings like these in the project .settings/.  That is what we do in the Papyrus project:  the settings in the org.eclipse.papyrus.infra.core project are the “master” source of settings and are propagated automatically to all other projects in the same repository.

Cheers,

Christian


On 16 March, 2016 at 09:22:32, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote:

Hello Philip,

I completely agree with you, it must be done soon, as the project is not so big yet.

For your information, I'm working on this already. I  modified the pom file on the Papyrus RT project to manage a Sonar Job, which is running every day but still have some dependancies issues due to profile setting.
I asked Benoit to have a look, but he is quite busy until the end of the week.

In addition, Papyrus already has a formatter, a cleanup and a Code Template file.
Which is the one I use in Papyrus RT. You can find those templates here:



All4Tec is used to work with checkstyle. Which is quite efficient. I will adapt the one we use for Papyrus RT and once in place we could discuss about its content. And disable or enable rules accordingly.

The Checkstyle file is based on the Sonar standard rules.

A discussion has been started about the Development best practices here:
https://wiki.eclipse.org/Papyrus/Neon_Work_Description/Discussions/Development_rules

It could be a good starting point to our checkstyle.

Best regards
Céline





Le 16/03/2016 14:01, Philip Langer a écrit :
Hi Papyrus-RT-dev team,

we noticed that there don't seem to exist any central code formatting settings and checkstyle rules. Before the project gets too large, it may pay off to introduce and consistently use such settings and rules. Otherwise it may soon get too cumbersome to introduce them once the code base gets too large.

We think that they'd help to keep the project maintainable on the long run and avoid tedious git conflicts due to inconsistent formatting, etc.

What do you think? We'd volunteer to propose them in a new gerrit patch.

Thanks and best wishes,

Philip

--
Dr. Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH


_______________________________________________
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

--

 
  Céline JANSSENS
 Software Engineer
+33 (0)2 44 47 23 23
  Mail : cej@xxxxxxxxxxx
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net
_______________________________________________
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

Back to the top