Good move in my opinion. There's been talk about this for a long time without anyone actually doing anything.
Bob. On 18/12/06, Tom Morris <[EMAIL PROTECTED]> wrote:
> Are there issues for these reorganizations? I can't find them. I don't know, but, to be honest, I didn't look to see if there were. The past couple of reorganizations that I've been exposed to we've done based on discussions on this list. Are we using a different process now? > There are a lot of considerations before doing this work and > we need a plan for how to do it and where different things > are to end up after the change. Is this more complicated than: 1) draft proposal for new structure 2) have developers review proposal 3) modify proposal based on review 4) implement As always, since I'm proposing this, I'm implicitly volunteering to do #1 & #4, unless you're saying upfront that you don't want this work done. > This is the first time I learn about these special > Eclipse-plugin requirements. Where shall we document them? There's really nothing special about the requirements. They're just what you'd expect from good software engineering practices (no cyclic dependencies, no uplevel references). The difference is that Eclipse actually enforces the good practices by using a private class loader for each plugin which has a private classpath that only contains its own classes plus the classes that it depends on. As you'll recall, our current Eclipse project structure is a compromise to accommodate our existing directory structure. For example, the only reason with have a core-lib project is as a workaround for directory hierarchy issues. Normally you'd have each project's library jars included in the project itself (ie GEF with argouml, MDR with model-mdr). Since I'm a strong believer in simple intuitive structures, I'd like to regularize our project structure. I'd also like to fix untuitive naming practices like having two separate src directories with src_new being older than src. Unless people are violently opposed to this, I'll work on putting together a proposal for the new directory/project structure. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
