[clue-tech] Eclipse: What are people using it for

Sean LeBlanc seanleblanc at comcast.net
Fri Jun 9 08:34:26 MDT 2006


On 06-08 17:57, David L. Anselmi wrote:
> Sean LeBlanc wrote:
> [...]
> >We did "standardize" about a year ago on IntelliJ for our IDE, and it 
> >seemed
> >to highlight just how much Eclipse can sometimes be sluggish. However,
> >IntelliJ does not have the autobuild feature that Eclipse now has turned on
> >by default, and so I never really moved over to IntelliJ.
> 
> I'm curious about autobuilding.  Does it give you a different 
> environment than production and hide some issues until testing or 
> integration that could be found earlier?  Do things build differently 
> for the developers than for the build master due to environmental 
> differences?
> 
> When I was a developer I also did all the CM, build management, and 
> release management.  We had a process for managing the software leading 
> up to a release including building and packaging it for installation on 
> the production system.
> 
> It was possible for the developers to run their code on their own 
> environment that matched production, and to build, install, and 
> configure using the same process I used.  They could also update 
> individual files without rebuilding everything but that was somewhat manual.
> 
> But we sometimes had problems if the developers did things differently, 
> like running on their laptops in an environment they created themselves. 
>  Because some developers didn't understand the production environment 
> and I didn't understand their custom environments (and couldn't take 
> their laptop away to troubleshoot) it could be hard to debug these things.

I should actually use a more correct term - although the option in Eclipse
is called "build automatically" and checked off by default, it really just
compiles.

For trying to solve the issues you describe, I like continuous integration
using CruiseControl, Ant, Junit, & DBUnit (if a db is involved), and PMD and
CheckStyle and FindBugs. Doing this is great because developers cannot claim
"it works here" - that's irrelevant, it needs to work from CC's point of
view, and that comes from what is in the source repository, freshly grabbed
with each build. With this approach, nightly builds can become an
anachronism - you know right away when the build is broken and what changes
were in that broken build and who did them.

Of course, technology alone can't solve all problems, but at a bare minimum
I think it makes sense that teams have to at least agree that Ant can be the
common ground if they don't agree on the rest of the environment. That's
actually the position the majority of the developers, including a few of the
senior members (by title, anyway) were advocating when we "standardized" on
IntelliJ, since across the team, some were using JDE w/Emacs, Vim, Notepad,
NetBeans, IntelliJ, and Eclipse. It really made no difference other than
buying licenses, as most developers continued to use their tool(s) of choice
and no one noticed. I'd consider that a success in the use of Ant. I'm sure
C/C++ developers took/take the same attitude with Make. Of course, you also
need to agree on style issues, which tools like Jalopy & CheckStyle can
really help out with... 


-- 
Sean LeBlanc:seanleblanc at comcast.net  
http://sean-leblanc.blogspot.com/
Insofar as the laws of mathematics are certain, they do not refer to reality; 
and insofar as they refer to reality, they are not certain. 
-Albert Einstein 



More information about the clue-tech mailing list