Much as I hate to raise the subject - isn't this primarily a debate about dependency management ?
I have the same problems using IntelliJ. It was pretty much the onlt thing I liked about the maven build -> generated project files ! How about using the ant-eclipse generator, has anyone been using it ? http://ant-eclipse.sourceforge.net/ Thanks, Marnie On Sat, Dec 11, 2010 at 2:39 AM, Robbie Gemmell <[email protected]>wrote: > > > > -----Original Message----- > > From: Andrew Kennedy [mailto:[email protected]] > > Sent: 11 December 2010 01:21 > > > > <snip> > > > > 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! > > My point was that's one of the reasons *why* I do it that (single project) > way :) > > > > > 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? > > > > You can use the existing build.xml files to run the build etc within > Eclipse, I don't think there is anything specific needing done there. > Running individual tests etc using the built in JUnit plugin is another > matter, and needs quite a lot of configuration. Again though, I tend to use > the cmd line for all these tasks. > > > > 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. > > > > That's based on both my Eclipse workflow and my Git workflow: I have > different Eclipse projects for different versions Qpid, and I *also* have > different Eclipse projects for different checkouts of the same versions of > Qpid :) > > > > 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. > > Again, a reason that I do what I do :) > > > > > > 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. > > > > I have consistently preferred the cmd line tools (more so for Git than svn > though) so I run into that one all the time. As per your response to b) > though, it doesn't seem like eGit can often do what I'm using the cmd line > tools for anyway (and even if it could, the cmd line is normally faster and > more powerful). File-specific history is about the only thing I've found > eGit useful for that I can think of just now, but even that's not hard to > grab with gitk. > > > > 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... > > > > Agreed. > > > > 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 tend to have a mixture of 1-1 and 1-M. Historically I always had the > checkouts inside the workspace, but over time have run into several little > niggles with doing so relating to various plugins etc, and so started > having > them outside the workspace; just another personal preference, doesn't make > a > huge difference, but still a difference :) > > > > 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? > > > > It isn't, it was just related to how I shared my project files at the time. > Had I not being sharing the change sets that way I probably wouldn't have > been sharing the project files either 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? > > > > I'm not sure compatibility would be a problem, the files are pretty simple > and don't seem to have changed for as long as I've ever looked inside them. > Differences between developer preference is what will cause issues most I > think. > > Example project files could always be checked in to a directory in the > tree, > rather than into a location Eclipse would actually pick them up directly > and > use them. Of course, then they will simply become out date if no one kept > them fresh, defeating the point. > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
