Re: [Ginp-developers] Project Quality

[Brian B. <br...@Pi...>]

Doug Culnane wrote:
> Brian Burch wrote:
>> Q: would you add it to the maven pom.xml so it is run at every build, or 
>> just a one-time process?
> Yes it goes in the "<build>" section of the POM.  I would bind this in
> so it runs on every install phase.
>> Q: what style would you impose on the project? (I tend to use the Rogue 
>> Wave Java Style book as my base reference, then modify my code style 
>> where necessary to fit that of the project I'm working on.)
>>   
> Not sure.  Jalopy is very configurable but it "ships with sensible
> default settings (mimicking the Sun Java coding convention)."  I would
> use these. 
> 
> I could set up Jalopy and you can try it with the command. 
> mvn install
> This will format all code.  I will check in Jalopy in the POM and all
> the formatted code.  This will be a big change in the subversion
> repository, so please tell me when you have everything checked in and
> then I will do this.  After that if "mvn install" is run regularly then
> the formatting will be stable and only new stuff will get altered. 
> However you need to be aware that you and your formatter are changing
> code and this can get confusing and create SVN conflicts.
> 
> The problem with setting up an IDE is that a project uses multiple
> IDEs.  JUnit, Eclipse and Netbeans have now all be used for the GINP. 
> Getting these set up the same is not easy.
> 
> An alternative is to run Jalopy once from the command line, but this
> need to be done regularly.

Thanks for explaining. I think it is not worth the extra complexity to 
setup and run Jalopy on every build. I can't imagine us suddenly 
attracting a large number of active and anarchic developers...

I think the best approach is for you to run Jalopy against your own 
sandbox with the Sun style (if that suits you best). You can then take a 
look at the reports and source code it produces - and whether the build 
still works successfully. Assuming you don't have any big problems and 
you like the results, then just commit the cleaned-up modules. (It might 
be worth tagging before and after - or is that just "cvs thinking"?)

Let me have a reference to whatever style you adopt. I'll run an update 
against my sandbox to collect your changes and simply(?) follow the new 
coding style for any future changes I make.

> Another alternative is not to do any formatting but this also has problems.

No, I think it is probably worth the one-time effort to tidy the code. 
If you do the Jalopy stuff, I'll reciprocate (when you have finished!) 
by fixing some of the more embarrassing problems from the code quality 
reports.

I didn't plan to make any more changes for a week or so. If you want to 
do the Jalopy run further away than that, just let me know so I can 
commit any pending changes before you start. Once you start running 
Jalopy, I'll consider the repository frozen until you tell me you have 
finished with it.

Regards,

Brian