Mike Schrag wrote:
> 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
I never thought it was undue criticism -- I think it's very appropriate
to question the original design decisions.
Also, I am no longer working on WOLips and I still feel a bit guilty
about abandoning the project, so feel free to ignore my rambling!
> 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).
Actually, I think the suggestion is quite good, and I wanted to admit to
my reasons for the old design -- sometimes when I want to change some
code I ask about the reasons for the current state of affairs so that I
can avoid overlooking important things that drove the design.
>> 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.
Yes, I find your reasoning very convincing. Although I think that
frameworks and applications (or, as they are sometimes collectively
called, "bundles") are a very close match to what OSGi bundles are --
and the Eclipse PDT puts all those into a single classpath container,
too, because it uses the OSGi Metadata files for management of the
classpath and reflects that using the classpath container.
My rant about IBM's Eclipse based products refers to the problem that
the IBM Web-App support adds all the .jar Files that are in the
WEB-INF/lib folder of my project to the .classpath file and this really
doesn't work well with our attempts to reduce the amount of duplicate
.jars in our subversion repository -- it would work far better, if they
had used a single classpath container.
>> 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.
I understand the problem and the solution, but I think that providing
the ability to order entries on the classpath is a quick hack around a
problem that goes far deeper -- properly solving the problem means that
you need to handle dependencies like OSGi does, or maybe the upcoming
Java module system (although I am not sure how that works in detail).
>> * 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.
I agree, absolutely -- support for the source-attachment feature is
definitely missing.
>> * 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.
Exactly. The danger I see with multiple classpath containers is that you
could run into problems that can be solved using classpath reordering in
the IDE when that level of control does not exist at runtime.
Harald
> ms
>
This archive was generated by hypermail 2.0.0 : Sat Nov 10 2007 - 09:35:10 EST