[ajug-members] favorite IDE

[James Mitchell]

With a Maven-ized build you can generate the IDE config files for  
Eclipse, IDEA, JBuilder, etc, etc. so you really don't have to check  
in the .project and .classpath.  People can just generate a new one  
any time they check out code.


--
James Mitchell
678.910.8017




On Aug 10, 2006, at 4:02 PM, Saltysiak, Byron wrote:

> 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
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members