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:[email protected]
