views:

36

answers:

1

I am using Hudson to build my projects periodically. I want Hudson to format my code (using Jalopy) and then check-in the changes to github.com.

I already have Jalopy configured the way I like, I just need to configure the scm plugin to check-in the changes.

A: 

In my humble opinion, this is a strange workflow and you should fix the root cause of a problem, not fix it after the facts.

Let's make toast American style: you burn, I'll scrape. --W. Edwards Deming.

I would thus format the code before committing either using:

  • the IDE on save (Eclipse can do this automatically with Save Actions)
  • a pre-commit hook (on your local repo?)
  • using jalopy:format during process-sources
Pascal Thivent
I am from America, so my workflow is ideal then :)
I'd like Hudson to format the code if it is not properly formatted, if it isn't there will be differences, in which case it can check those in automatically. I'd prefer it to be automated.
@Walter LOL! Deming was American so no offense :) Regarding your request, note that all the solutions I suggested are automated. Anyway, I'm not using Hudson right now so I can't build a solution relying on it and will let others answers. Still, I think you should *prevent* non formated code to be committed.
Pascal Thivent
I already have Jalopy attached to the process-sources phase. It isn't hudson dependent, what I can do is also attach an SCM command on the mvn install/deploy phases?
Then every single time I do an install / deploy, the formatted code will be checked-in? The problem with automating the check-in at this point is that it is no longer just a code format, but actual code changed. I'd like to keep it 2 operations so that the diffs are easier to view.
I can only agree with Pascal on this one. Have Eclipse format the code for you or use the jalopy:format when you run your build. You could also run Checkstyle either in Eclipse as a plug-in or through maven as a plug-in. That way you can make the build fail if the code isn't properly formatted. Having automated check-ins for anything seems to me like a dangerous idea. Rather make it impossible to check in bad code. That way the developer needs to take care of writing properly formatted code.Reference:http://checkstyle.sourceforge.net/
AGrunewald
I wasn't asking for your opinion. I was asking how to achieve this. I will have a background job that will make sure the code checked-in is formatted.
I agree, I'd like code to be formatted before it is checked in, but that is another task that be handled automatically.
@Walter very often, people are asking for [a wrong specific solution instead of explaining their general problem](http://meta.stackoverflow.com/questions/56366/can-we-get-people-to-directly-ask-about-their-problems-instead-of-topics-they-thi), exactly like you here. I thought that giving some advices about the right way to handle your problem would be valuable (if not for you, for other readers). I'm free to post my opinion on your problem, you're free to just ignore my opinion and go your way. Good luck.
Pascal Thivent
Like I said, what I would like to do is periodically format the source code in the repository as it is. My reasoning being that sometimes I check code in to fix a very specific problem without running maven. So, I am guilty of not 'testing it', in that case, I usually add comments, or fix imports. What I am looking for is a system that corrects all of my stupid programming mistakes, ie. does the grunt work. Since I have been publishing my code online, I haven't been running maven locally, I let my local hudson instance do what I want.