Currently we’re using what was defined for OPEN-O:  
https://wiki.open-o.org/display/GI/OPEN-O+Java+code+style, namely:

Google Java Style with some modifications:
4.2 Block indentation: +4 spaces
4.4 Column limit: 120

Gildas, any ideas where we should put this in the ONAP wiki?

Thanks,
Gary

From: Alexis de Talhouët [mailto:[email protected]]
Sent: Tuesday, July 11, 2017 2:11 PM
To: Gary Wu <[email protected]>
Cc: LEFEVRE, CATHERINE <[email protected]>; [email protected]
Subject: Re: [onap-discuss] [integration] Refactor CLAMP to inherit from oparent


On Jul 11, 2017, at 2:27 PM, Gary Wu 
<[email protected]<mailto:[email protected]>> wrote:

Hi Catherine,

In today’s Integration meeting, we discussed having CLAMP pilot trials around 
coding styles.  In OPEN-O we centrally defined coding styles in the oparent 
project/repo, and it would be great if we can do likewise for ONAP so we can 
avoid duplicate or conflicting definitions across projects.  Do you think we 
can have CLAMP do a pilot run on inheriting from oparent as well?

Is there an place where the code style rules have been explained? I believe a 
wiki page to explain what are the agreed rules could help, similar to what ODL 
has here: 
https://wiki.opendaylight.org/view/BestPractices/Coding_Guidelines#General_Code_Style

At any rate, thanks for putting this up! It’s going to be a long journey to 
enforce checkstyle considering the amount of LoC in ONAP.

Thanks,
Alexis



To recap the goals of oparent:  centrally define shared parent POM definitions 
such as nexus (distributionManagement) location, coding styles, license checks, 
coding style checks, sonar setup, etc.

To inherit from oparent:  modify the project’s POM to ensure that all POM files 
ultimately inherit from

    <parent>
        <groupId>org.onap.oparent</groupId>
        <artifactId>oparent</artifactId>
        <version>1.0.0-SNAPSHOT</version>
    </parent>

And also remove any local definitions within the project POMs around 
distributionManagement, coding styles, etc., so that those properties are 
derived from oparent instead.

Please let us know if you run into anything that would require changes or 
enhancements to the oparent POMs.

Thanks,
Gary


_______________________________________________
onap-discuss mailing list
[email protected]<mailto:[email protected]>
https://lists.onap.org/mailman/listinfo/onap-discuss

_______________________________________________
onap-discuss mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-discuss

Reply via email to