If anyone has any additional requirements for this reorganization, please add them to issue 4625 and I'll work on putting together a proposal for people to review. I'd like to get this done while the source tree is still in a relatively quiet post-release phase.
Tom > -----Original Message----- > From: Linus Tolke [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 19, 2006 2:21 AM > To: [email protected] > Subject: RE: [argouml-dev] Reorganizing the source tree > > > Hello Tom! > > I am sorry I am so eager that I skip the process discussion > and immediately start looking for place to do #2. > > We can use the list if you prefer. I just thought an issue > was a good place to collect these thoughts (i.e. the #2 thoughts). > > > Well, then we have the same on the ArgoUML plug-ins. Only, > this comes as a surprise for us every time and I have had to > fix things for internationalization. Isn't this done by Java > classloader design? > > /Linus > > > > -----Original Message----- > > From: Tom Morris [mailto:[EMAIL PROTECTED] > > Sent: den 18 december 2006 22:51 > > To: [email protected] > > Subject: RE: [argouml-dev] Reorganizing the source tree > > > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
