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:adetalhoue...@gmail.com]
Sent: Tuesday, July 11, 2017 2:11 PM
To: Gary Wu <gary.i...@huawei.com>
Cc: LEFEVRE, CATHERINE <cl6...@intl.att.com>; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] [integration] Refactor CLAMP to inherit from oparent


On Jul 11, 2017, at 2:27 PM, Gary Wu 
<gary.i...@huawei.com<mailto:gary.i...@huawei.com>> 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
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
https://lists.onap.org/mailman/listinfo/onap-discuss

_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Reply via email to