I'm sorry I didn't get a chance to review things before this. I guess I didn't realize it was going to be such a big change. The initial review period was also just 2 days, so it was already too late before I even had a chance to look at things.
> When doing this change I have not fixed up the build2 scripts. My ideas was > to remove them in favor of Eclipse configurations to do everything. I'm not sure I understand how this is meant to work in practice. How does one run the regression test suite before committing a source code change since, as far as I know, only one instance of Eclipse may be using a workspace at a time? Are people using JUnit test suites from within Eclipse or picking tests to run by hand or just not running the tests? > Java code style settings: > This was made intentionally since the idea is to rely on the Java code style > settings of the Workspace. On the other hand, since the workspace settings > are not saved, this is perhaps not such a good idea after all. I think the least error-prone method is to have developers automatically get all the proper settings when they check the project out from SVN. Using per-project settings accomplishes this. > This workspace idea is documented in the Cookbook 2.8.2 Basic ideas of > the set up. This text appears to have been added in May 2007. If there was a discussion about the change at that point in time, I don't remember it, but I disagree with much of what's written there. > I really missed your comments on this when I started this work Tom. The > ambitions of the first go at the Eclipse configuration were not really > documented so it was not possible to understand how it was supposed to work. I know the Tigris email archives aren't very easy to use, particularly the feeble search mechanism, but I wrote extensively about what I was doing in February 2006. Look for threads with subjects like "Checking Eclipse files into CVS" and, especially, "New Eclipse setup". > It is now clear that we, for the second attempt (my restructuring attempt), > need to revise: > * What names we should use (path-names, project-names, and plug-in ID)? > * How projects are to be set up, settings for style, compiler, ... > > Could you point me to some document describing some Eclipse best practices > on how to do this? I feel like I am moving in the dark. I don't remember finding any good description of how to set up a collection of dependent Eclipse projects, but I probably didn't look too hard for a "best practices" document since these things tend to assume a clean sheet implementation and we had a bunch of legacy constraints. In particular, I was trying to preserve the existing Ant build environment. If this is no longer a constraint it may allow some different choices to be made. As I mentioned in the my last message, I believe that Eclipse is now more flexible than it was at the time I was doing my work. The two examples that I looked most closely at were AndroMDA and Eclipse itself. Eclipse basically uses a project per plugin and uses the plugin development environment (PDE) . AndroMDA, as I recall, had a top level project called something like andromda-all which could be checked out if you wanted to get everything, but the more typical environment which to check out individual modules underneath the top level. These two styles of checkouts were mutually exclusive. AndroMDA used Maven for its builds and Eclipse uses the command line Eclipse builder, so the two projects deal with this aspect differently. I'm sure there are many more examples of projects available now than there were two years ago. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
