[ajug-members] favorite IDE

Saltysiak, Byron Byron.Saltysiak at turner.com
Thu Aug 10 16:02:50 EDT 2006


You could use the same technique as maven (but not maven itself) to
prevent this hardcoding - require team members to setup a Classpath
variable via Eclipse and refer to your custom jars like: <classpathentry
kind="var" path="JUSTINS_REPO/meads.jar" />

Then you'd setup JUSTINS_REPO=d:\usr\jars in eclipse.

Local edits that can't be checked in are ugly and cause merging issues.

-----Original Message-----
From: ajug-members-bounces at ajug.org
[mailto:ajug-members-bounces at ajug.org] On Behalf Of Justin Meads
Sent: Thursday, August 10, 2006 3:26 PM
To: General AJUG membership forum (100-200 messages/month)
Subject: Re: [ajug-members] favorite IDE

>> We add our .project and .classpath files to version control.
> I've got 10 people working on a project, and not everyone has the same
> exact hard drive layout. Tell me how I can treat .dotfiles as common
> version control artifacts w/o including hardcoded paths.
>

The .project doesn't have any directory items in it so it is a non  
issue.  The .classpath for my 12 person team only references two jars  
via hardcoded path.  We default these two jars to d:\usr\jars.  If a  
developer doesn't like this, they can always change their  
local .classpath.  That is pretty simple.  You could also create  
Classpath Variables.  The two jars could be referenced in relation to  
the Classpath Variable that can be set by the developer to whatever  
they wanted.

>
>> You can also export/import all of your Eclipse preferences
>> which is nice.
> Yes.
> But it'd be nicer if I could have stylesheet-esque layered  
> definitions.
> Right now it's all or nothing. 3way diff and sync is a PITA.
> There _are_ better ways to do it. More flexible, less brittle and
> complex mechanisms. The Eclipse team (and virtually every other IDE
> developer) hasn't understood or cared. So far.
>

You could trim any of the exported preferences to a subset and then  
apply these on top of each other.  The current preference system has  
provided no problems for my team.


 > I find (good) IDEs have value more so for projects you're less  
familiar
 > with, for less experienced developers and certain types of
 > projects/languages. IDE value - and usage - tends to decrease if  
you're
 > familiar with a project, a more experienced developer, and/or working
 > with certain types of projects (e.g. Python vs. Java).

I strongly disagree.  I have been on the same project for three years  
and Eclipse is as valuable to me today as it was the day i started.   
Because i am very familiar with the project, i never have to navigate  
to a class i am looking for.  I just pop up ctrl-shift-t type in a  
couple of characters and open the class i am after.  You can't do  
that if you are inexperienced on a project.  Using Eclipse templates  
is another feature that makes life better for new and experienced  
developers.

-Justin
_______________________________________________
ajug-members mailing list
ajug-members at ajug.org
http://www.ajug.org/mailman/listinfo/ajug-members




More information about the ajug-members mailing list