Grumble. So the foundations for the last restructuring was all wrong (i.e.
guessed by me more than a year after the original work was done).
Could you write a new and better version of the chapter 2.8.2 of the
Cookbook so that we can finally start pulling in the same direction with
this?
/Linus
2008/3/24, Tom Morris <[EMAIL PROTECTED]>:
>
> 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]
>
>
