I have added some sidebars to the Cookbook describing some of the
experiences that has surfaced in this discussion.
Shall I continue and attempt at writing the new foundations and rationale
together with a naming policy?
/Linus
2008/3/24, Linus Tolke <[EMAIL PROTECTED]>:
>
> 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]
> >
> >
>
