Hey Harald ... My comments are not an attack of the original design.
It has obviously served everyone very well for many years. What we're
finding is that under more modern uses (with crazy things that Project
Wonder does, for instance), we need more fine-grained control over the
frameworks, and I'd also like to be able to take advantage of as many
core Eclipse features as we can without rewriting things (like order
management, for instance).
> Having a single UI for multiple containers sounds like
> working around the Eclipse framework's assumptions (IBM's Eclipse
> based
> products are a good demonstration of how that can hurt the usability
> of
> the final product).
Not sure I follow here ... It seems to me that frameworks should be
managed just like other elements of the build path. A single
framework (bundle) is a classpath container of several jars/source.
This more closely matches both NSBundle's runtime characteristics as
well as the standard modeling of this sort of packaging within Eclipse
(the VM is a good example -- it appears as its own container).
"WebObjects" is not the container, the individual frameworks are.
> Some other assumptions:
> * ordering the frameworks should not be necessary, since there
> should be
> no overlap between classes (but you are probably concerned about
> startup
> order, right?)
Ordering does matter, actually, because in the general case you can't
know that classes don't overlap, and in fact it turns out that they do
(very commonly). Both from the standpoint of overriding classes in
the normal Java classpath as well as defining the resolution order of
components by name, the ordering makes a diff.
> * if you want source with your framework, you'll probably also want to
> be able to change it -- and add it as another eclipse project (we only
> had a handful frameworks in our projects, so this was never a problem)
Only sometimes ... What you describe is how I run, but an example is
Eclipse plugins. In the PDE development install, all src jars are
included, so you get source reference as well as javadoc, but I can't
make changes to it (and usually don't need to). When I do need to
change, I check them out individually and usually only for short
periods (to make a patch for instance). Otherwise I would have to lug
around hundreds of Eclipse plugin projects all the time, which would
make it fall over on itself.
> * in a wo project, there should be no dependencies not managed as a
> bundle
I think what you're saying is that any jar file that you depend on
should come from a bundle. This is MOSTLY true, except for things in /
Lib/WO/Ext and /Lib/Java/Ext, but those have a specified classpath
order that you can't control (easily) anyway, so it's effectively the
case that user-contributed jars are always from within a bundle.
ms
This archive was generated by hypermail 2.0.0 : Fri Nov 09 2007 - 18:26:01 EST