Am 10.11.2007 um 15:33 schrieb Harald Niesche:
> 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!
You're still a contributor.
>
>
>> 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.
Currently the container ui has no support for it. The container is
able to store it in it's path.
>
>
>>> * 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 : Mon Nov 12 2007 - 03:47:38 EST