> If that is a 2 minute thing - okay. If not, I guess it's better to
> wait for the new stuff and figure out how situations like that can
> be handled in a user friendlier way.
In the new stuff, the "user friendlier way" is "rename it. stop doing
that." :)
The reason why I am advocating this new approach is:
1) I don't believe this actually happens all that often
2) When it DOES happen, it's usually the case that you're overriding a
lower framework, anyway.
3) We can ditch the tree and switch to a flat list which makes that UI
a lot easier to use
4) It allows a very easy definition of rules as well as automatic
classpath manipulation -- Project=>Project Framework=>User
Framework=>Local Framework=>System Framework=>Network Framework. If
at any point in that order a framework of the same name appears, I
know exactly what the override rule is. This allows the new system to
do automatic project overrides without introducing even more confusing
rules ("oh but that was in system, i didn't intend that one to
override -- i only want the one in local to override" -- nope, sorry,
the rules are clear).
5) The fix for this being wrong is pretty easy.
ms
This archive was generated by hypermail 2.0.0 : Thu Feb 21 2008 - 12:41:46 EST