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]
