qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject Re: Eclipse project files for Java code
Date Sat, 11 Dec 2010 01:21:07 GMT
On 10 Dec 2010, at 22:57, Robbie Gemmell wrote:
>> It looks like many java developers just include absolutely everything
>> they might need on the classpath, but I wanted to know what was  
>> going on
>> and carefully added only what was necessary (to the extent I  
>> understand
>> what's going on!) for the projects I'm building.
>
> I can't speak for anyone else, but that's exactly what I do for a  
> variety of reasons, such as:
>
> a) it takes about 15 seconds to get set up in Eclipse, and you can  
> use the main build files just as if you were using ant from the  
> command line.

Of course this is if you use a single eclipse project for all Qpid  
java files (like I do) wheras if one wanted to create a project per- 
module, you then need to manage the dependencies between modules  
*MUCH* more carefully!

I'm still not sure which of these two mechanisms Andrew is using?

Like you, I include everything in 'qpid/java/lib' in my build path,  
as well as some external files (I think 'ant.jar' for the 'tasks'  
module, maybe something for Velocity, also Cobertura too?) which  
works fine. Of course, I have to exclude some source directories,  
usually the old examples or old tests, from things like 'systests'.  
You also need to run an external build first, to generate the  
'scratch' sources, so they can be included.

Also, I use 'ant build' and 'ant test' et al from the command line,  
rather than trying to set up the environment inside Eclipse to make  
that work. Basically, to run builds and tests from the IDE seems like  
(too much) a lot of work, and even if one was to set this up in the  
project files, there would be the issue of keeping them in sync with  
the files in 'java/test-profiles' I suspect?

> b) I usually have several projects defined tracking different  
> versions/checkouts of the codebase, again having a single one per  
> version is a lot easier than messing around with say 15 module  
> projects for each.

This is really based on your Git workflow, and not an Eclipse thing.  
Eclipse doesn't, even with eGit, support flipping between checkouts/ 
branches inside the IDE (well, I think so, anyway, never tried  
it...?) so it's still something you have to do on the command line  
manually.

> c) The inter-module dependencies are fairly simple to keep track of  
> yourself [admittedly, only once you know them in the first place],  
> the build system enforces them already, and I find it's usually  
> best/easiest to just run things from qpid/java rather than doing a  
> specific sub module given that so many do have dependencies.

See response to a) above.

> d) Eclipse caches the status of files on disk and often needs its  
> projects refreshed to ensure it is actually showing/using the  
> current version and not a cached build, e.g. after you do a rebase;  
> it's quicker just needing to worry about refreshing 1 project.

If you use eGit or subclipse, you can do this in-IDE, though.  
Personally, I do both, as depending on the complexity of the  
operation one or the other methods may be better.

> e) I use Git to pull the rug out from under Eclipse and work on a  
> variety of branches with the same project definition. The above  
> means that having 1 project again makes life easier.

Actually, eGit inside Eclipse is pretty cool, and allows most  
operations in-IDE. Again, this points out there are many different  
workflows using the same IDE...

> f) I tend to keep my Eclipse project data separate from the repo  
> checkouts, with my projects 'using existing source' out of the  
> workspace tree, as I tend to mainly use the build at the cmd line.  
> It also lets you forget about eclipse generated content without  
> having to specifically ignore it, and gives you more freedom to do  
> weirder things like having multiple projects pointing at the same  
> set of source on disk (which you can't do anywhere near as easily  
> if the source is in your Eclipse Workspace, without effort to trick  
> Eclipse anyway).

Hm. My checkouts are inside the Eclipse workspace, but I work on a  
one-to-one mapping between projects and checkouts/branches, so I  
never have this issue.

> I'm sure there are more reasons I switched to doing it this way,  
> but those are the main ones I can think of now.
>
>>>
>>>> Should I register this as an objection to checking in the eclipse
>>>> project files?
>>>
>>> I wouldn't bother personally and won't be using them, but it's  
>>> not an objection as such.
>>
>> Ok, my major reason for wanting to do this is to share the project  
>> files
>> over the several development machines I use, is there some better  
>> way of
>> doing that?
>>
>> Andrew
>
> In the past, when I first set things up and did it like you are  
> trying now, I just emailed them to myself in all honesty :)  
> Following that I used my own Git repos to shuffle things between  
> machines, although that included source changes too as it was  
> before I had commit rights.

Hm. I sort-of do that, mailing patches from 'git format-patch' but  
also full tarballs as well. Not sure that how people manage keeping  
personal changesets is the issue here, though?

> The way I define the projects now, I honestly find it's so easy to  
> get set up that I don't feel the need to share them; it would take  
> as long to reuse the definitions as it does to set them up in the  
> first place, and I actually don't tend to work on the same things  
> on different boxes now so I usually have different setups on them  
> now anyway.

Well, my general feeling is that the difference between workflows in  
Eclipse, based on the many possibilities provided by the range of  
plugins and the mix of command line or IDE options, for various  
things, mitigates checking in the '.project' and '.classpath' files.

Of course, if we used Maven then we could leave it up to individual  
developers to just run 'mvn eclipse:eclipse' or whatever to self- 
generate project files, as well as similar commands for other Java  
IDEs as well. There's also Ivy, which seems to support the same Maven- 
style dependency management, although not automatic setup for IDEs. I  
know that there are '.sln' files for Visual Studio, but that's more  
of a mono-culture, so not as much of a problem. For instance, what  
about compatibility between Eclipse 3.2 and 3.4 or whatever?

Cheerz,
Andrew.
-- 
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;



---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message