Hello Tom!
build2 scripts:
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 might
not have been very efficient in removing them.
ANTLR:
I thought I hade it working correctly. It works in my Eclipse setup. I guess
this problem was introduced when I cleaned out the build.xml file. I hadn't
noticed since the files were already there in my checked out copy. The best
solution is probably to let every project that uses ANTLR have its own copy
to compile against.
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. This
workspace idea is documented in the Cookbook 2.8.2 Basic ideas of the set
up.
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. 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.
/Linus
2008/3/24, Tom Morris <[EMAIL PROTECTED]>:
>
> OK, I've gone back through this whole thread and I still don't think I
> understand where we are today.
>
> - command line tests - It appears that the build2 script doesn't work.
> How does one run the JUnit tests from the command line (using the
> Eclipse project directory structure)?
>
> - ANTLR for plugins - Plugins which depend on ANTLR (e.g. cc, idl)
> aren't building. Where are they supposed to be finding ANTLR?
>
> - Java coding style settings didn't get carried over to the new
> projects (That's why there was a recent complaint about tab settings
> in contributed patch). I have a patch for this.
>
> The JUnit issue is the most critical for me. As a short term
> workaround I'd be willing to have a way that I could run all the JUnit
> tests in Eclipse, but having the command line option is much more
> useful because a) it can be automated and b) it allows me to run the
> tests at a lower priority in a separate process while I continue to do
> work in the foreground.
>
> Earlier in the thread there was a question about why the Eclipse
> project names have "argouml" prepended. This is so that all ArgoUML
> projects collate together. Most projects use the Eclipse plugin name
> for this type of thing, so rather than "argouml-core-model," it would
> be "org.argouml.core.model" or "org.argouml.model". I don't have a
> strong preference for one or the other, but I do think it's important
> to have something argouml related prepended so that a) there's no risk
> of name clashes in the workspace and b) all the ArgoUML projects are
> grouped together.
>
> Speaking of workspaces, I've seen a couple of references to an
> assumption that a dedicated Eclipse workspace will be used for
> ArgoUML. I feel strongly that we shouldn't be dictating how people
> organize their work unless it's absolutely mandatory. I don't believe
> it is in this case. Each separate workspace requires extra work to
> set up preferences (non-Argo related), etc, so I only use them when
> necessary. Instead I use Mylyn to manage task specific contexts
> within a single workspace. Anyone who's not already using Mylyn
> should check it out (I'll write a separate note on it later).
>
> I think Dave T.'s work to harmonize the Eclipse project directory
> structure with the command line checkout directory structure is great,
> but I really need to understand what the state of play is before
> having anything useful to say about it. I will mention however that
> the original reason that we couldn't use the same structure for both
> was that our existing, at the time, CVS directory tree was
> incompatible with Eclipse's requirement that projects have
> non-overlapping directory trees. I think that requirement has since
> been dropped/softened (although it's probably still a good idea to
> have non-overlapping trees just from a user confusion point of view).
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
