aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Sierra Andrés <>
Subject Re: [jax-rs-whiteboard] First review
Date Tue, 29 Nov 2016 13:48:35 GMT
Hi Christian,

thanks for looking into this. For me it's fine to use whichever 
conventions are appropiate. I just commited the source with the 
conventions we had in our code.

where is the formatter you mention and how can it be used?

I can adapt the sources to the conventions it enforces.

Regarding the author comment... sure, let's remove it... it is also part 
of the conventions we had in the previous work.

Please let me know if you find any concurrency issues.



El 29/11/16 a las 12:05, Christian Schneider escribió:
> I took some time to look into the jax-rs whiteboard code and noted 
> some findings below.
> Formatting:
>  * The code is formatted with tabs. I propose to use spaces like in the
>    other aries modules
>  * In some java files there is a empty line between each line of code.
>    I think empty lines should only be used for bigger blocks.
>  * Some attribute defs are in the end of the class code. Will move them
>    to the top
>  * The line wrapping for parameters is different from the default.
>    Generally I like the wrapping this way but the formatter is not
>    configured for it so an autoformat would destroy this.
>    So I propose to rather use the default formatting we have.
> I just checked the aries coding conventions. Seems we have the rule of 
> 4 Spaces instead of Tabs but not further rules. I think most of the 
> code uses the eclipse defaults but we might want to provide a 
> formatter to make it easier. Any opinions here?
> Other:
>  * The poms did not have the apache header. I already added it
>  * The classes all have the author tag of Carlos. I propose we remove
>    these as the author of each line is visible from git anyway and the
>    author tag can be misleading if other people also edit the code
>  * I get an error in each pom in eclipse at Manifest.write. Not sure
>    what causes this but we should try to fix that
>  * There is a project for log4j-configuration. I propose we use pax
>    logging or logback instead of a fragment
> Besides these there also might be some issues with concurrency. I will 
> look into these in more detail.
> Christian

View raw message