[ajug-members] favorite IDE
Jason Vinson
vinson.lists at charter.net
Thu Aug 10 15:30:40 EDT 2006
I think that really depends on how big your module is. If you are using a
plethora of maven plugins, then that could be an issue, but the Project
Object Model really manages where source lives, etc.
Jason.
_____
From: ajug-members-bounces at ajug.org [mailto:ajug-members-bounces at ajug.org]
On Behalf Of Ron Cordell
Sent: Thursday, August 10, 2006 3:20 PM
To: General AJUG membership forum (100-200 messages/month)
Subject: Re: [ajug-members] favorite IDE
Unfortunately, not all maven modules adhere to the maven "standards", since
the modules are written by different people. Maven's operation is implicit
as opposed to Ant's (and make's) explicit behavior. Finding and working
around the implicit behaviors can be a real PITA considering that a good
many things remain undocumented. Despite that, maven is a good tool in many
respects.
On 8/10/06, Jason Vinson <vinson.lists at charter.net> wrote:
That's just how maven works. I find it to be a great tool as long you don't
mind adhering to a few maven "standards".
I'd be happy to elaborate more if desired.
Jason
-----Original Message-----
From: ajug-members-bounces at ajug.org [mailto:ajug-members-bounces at ajug.org]
On Behalf Of Howard Kapustein
Sent: Thursday, August 10, 2006 2:44 PM
To: General AJUG membership forum (100-200 messages/month)
Subject: RE: [ajug-members] favorite IDE
That sounds pretty interesting. Is that just how Maven works, or is it
how you happen to use it?
-----Original Message-----
From: ajug-members-bounces at ajug.org
[mailto:ajug-members-bounces at ajug.org] On Behalf Of Jason Vinson
Sent: Thursday, August 10, 2006 2:00 PM
To: 'General AJUG membership forum (100-200 messages/month)'
Subject: RE: [ajug-members] favorite IDE
Not to force tools on anyone, but we use maven here at work for our
projects. While I'm sure people have complaints with maven, it
maintains a
specific directory structure for jars and references them in your
.classpath
via a MAVEN_REPO variable.
Each developer only has to set that MAVEN_REPO variable and run "maven
eclipse" to get the .classpath and .project files correct.
Jason
-----Original Message-----
From: ajug-members-bounces at ajug.org
[mailto: <mailto:ajug-members-bounces at ajug.org>
ajug-members-bounces at ajug.org]
On Behalf Of Howard Kapustein
Sent: Thursday, August 10, 2006 1:44 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.
We've done this with Visual C++ and Visual Studio, via environment
variables. Set blahblahblah_DIR_HIBERNATE=C:\Hibernate or whatever, then
use $(blahblahblah_DIR_HIBERNATE) in project files. "Root" paths are
machine machine, can vary per machine but are commonly referenceable.
Especially useful when you've got a mix of desktops and laptops,
deskjockeys map a drive like Z: and point
blah_DIR_HIBERNATE=Z:\Hibernate whereas laptop folks who snag everything
local to work at work or the road set =C:\...
Can you define how to do this with Eclipse, in a _clean_ way?
Best I've found is you need to write some utility to take your
definitions, find the key JDT file with variable definitions,
add/modify/remove rewrite these entries in the property file for the
current environment and then launch eclipse. That doesn't pass the
3-year-old-test even on a good day, but it's the closest I've been able
to figure out.
>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.
- Howard
P.S. Yes, in this specific case I find Eclipse to be the half-mongloid
cousin of Visual C++. 10 years ago. Sun may have poo-poo'd all over the
environment, but it's one of the few common, effective options to help
make rugged, reliable, simple solutions. Fine. How about a little
Separation-of-Concern refactoring applied to Eclipse's design so we can
easily segregate and manage machine-specific options from
project-specific shared options? What's the keystroke for that again?
Ctrl-1, P, Alt-Shift-X, Space, Space, Space, Meta-Speak-Command-RClick?
-----Original Message-----
From: ajug-members-bounces at ajug.org
[mailto: <mailto:ajug-members-bounces at ajug.org>
ajug-members-bounces at ajug.org] On Behalf Of Justin Meads
Sent: Thursday, August 10, 2006 12:30 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. When we
pull the project from SVN, it just works.
You can also export/import all of your Eclipse preferences which is
nice. In Eclipse choose
FIle -> Export -> General -> Preferences -> Check Export All ->
Click Finish
Reverse the process to import into a new workspace.
Regards, Justin
On Aug 10, 2006, at 10:10 AM, Dan Marchant wrote:
> I have found that in most cases eclipse recognizes the project source
> files with creating a new project and pointing it to an existing root
> folder.
>
> I am a bit annoyed with the project concept since in most cases people
> work on a "product" not a project. Project are usually instances of a
> product.
>
> The other thing that annoys me about eclipse (which has work arounds)
> is when creating a new workspace you have to reset all your source
> control settings. For instance, I use the workspace as a way to have
> multiple branches setup at a time. I usually copy the metadata
> directory and it helps a bit.
>
> In general, IDEs need better support for branches and release on a
> product line.
>
> My 2 cents and vents
>
> - Dan
>
> On 8/10/06, Burr Sutter <burr.sutter at jboss.com> wrote:
>> You might be right.
>>
>> Every development team has a unique project/folder/build structure
>> and
>> pull that into an IDE takes too much effort in some cases.
>>
>> Eclipse's import project from Ant trick has failed me before.
>> What has
>> been the rest of your collective experiences? Perhaps Netbeans
>> performs
>> better this case.
>>
>> Burr
>>
>> -----Original Message-----
>> From: ajug-members-bounces at ajug.org
>> [mailto:ajug-members-bounces at ajug.org] On Behalf Of Kammy
>> Sent: Thursday, August 10, 2006 10:43 AM
>> To: ajug-members at ajug.org
>> Subject: [ajug-members] favorite IDE
>>
>> I guess I am a dinosaur. I use xemacs and vi. I tried
>> using eclipse 1 X, but didn't like the whole project
>> thing, etc, which I can't stand about IDE's anyway.
>>
>> Kammy
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20060810/c06482f7/attachment.html
More information about the ajug-members
mailing list