RE: Re: AW: [jdt-dev] JDT Goes PDE

["SP/Fink Thorsten" <sptf@xxxxxxx>]

Hi Erich,

thank you for pointing me in the direction of OSGI and inviting me to participate. 
It would certainly be a thrill, and if I should feel that my abilities and my time 
allow for such a participation -- not that sure on either point :-) -- I definitely will.
I should also say that we currently consider following the RCP theme for the fat client
we're developping. So for us, this discussion has already been a success. What questions
we have regarding RCP we'll post in the newsgroups.

You should know that most of what I learned in Java / OO (after having learned to "walk") 
I learned from you, Kent Beck and a few like-minded individuals, and the past 3 1/2 years 
have been professional bliss due to world surrounding JUnit, Refactoring, Eclipse, Ant 
and CVS. So, before I continue and (hopefully not) get on your nerves: Thank you very, very
much!! 

But applying these skills I come to certain conclusions when working with Eclipse JDT. 
So, if I haven't tried your patience to much yet, let me allow to switch into the role 
of "customer/user on site", and let me explain a few re-occuring problems I encounter 
when using JDT.

For today, I stick to library classes, Jars and their use in Eclipse JDT (or any other IDE). 
As soon as we download a jar, there is this faint smell (in a Kent-Beckian kind of way). 
Most jars are "dumb containers" (analogeous to "Data Class"): they just convey to us who 
they are -- and that only by the jar name, but they don't tell us which version they are. 
Why don't they, why aren't they required to do so? They could easily do so in their manifest, 
but most don't -- but even if they did, there'S no ide using that information. So, we check 
them into our config management system, they get a version and we have mapping information 
for the versions nearby (or we label them with the official version). 

Now we start using the jar(s) in our Eclipse projects (as a library): junit.jar is in all 
our projects, and there are many more (dom.jar, log4j.jar, jaxb-*.jar, jaxp-*.jar etc.). Currently, 
we got about 20 jars in seven projects -- numbers rising. We use them as libs in the workspace, 
as central libs won't work -- can't require all projects to upgrade at the same time. As long as 
no lib moves, everything is fine. Once, we want to upgrade a jar's version, work starts: we go 
into each project, and upgrade the version, then we start the tests again and verify that all tests run. 
Checking that all projects have been upgraded is a manual process again. Look at the lib in all projects 
where it's used and verify that the version is correct. You forget one, it's a festering bug/surprise 
waiting to jump at you. 

Up until a few weeks ago I thought, there's nothing we can do about this. But on p.96/97 of your book
"Contributing to Eclipse", you describe how you handle the situation (so you must have seen this problem
and you did react) most gracefully in PDE: You wrap the library, and you recommend that everybody does 
in PDE. This is like "Introduce Local Extension" to the smell "Incomplete Library Class": since jars 
are not required to have a unique id and version, you extend them and you give them one. 

So what we would like to do, is: Create an Eclipse Java Project, and wrap the library. But as JDT does not
recognize versions in project and/or lib dependencies, it won't work. If it did, we would save time and 
be safer in our development. So, this is the one extension of JDT we would like to see.

My last point to this is a "thought experiment". Follow, in thoughts, a new version of a jar, let's say the 
dom.jar, as it's being downloaded by an Eclipse user, and upgraded in an Eclipse projects. Now, follow all
jars to all Eclipse users to all projects, and we know how much time could be saved. I think Eclipse JDT 
recognizing project versions (in a minute, few-line manifest) would be an "Ease of Development" theme worth 
its consideration.

I haven't touched yet upon the topic of inter-project dependencies and how much (even more) time could be 
saved. Erich, looking at PDE I see developpers facing a few of the very same problems that we application 
developpers have every day, and I see them successfully resolved. I have seen Eclipse used since the spring 
of 2002 in a pure-server project (Java 2 on an IBM mainframe doing 10k million transactions per day), a J2EE
project and now a fat-client/server-project, and each time we would have saved time and would have gone at a 
smaller risk if there was a recognition of the most basic project dependency (one by version). I was not good 
enough to see the solution, but now that I've seen it, I know that this is what we need.

Thank you for your time and effort.

Cheers
Thorsten

PS. The more I think about these smelly Jar files and look its most successful clients (William C. Wake, "Refactoring
Workbook", p.79 4. Look at each client), PDE library plug-ins, I feel that your plug-in "code", that is the manifest's 
id and version tags should be moved into the jars. Is there a reason why this information a) isn't mandatory (it could 
be used by intelligent IDE's such as Eclipse) in Jars's. Not an Eclipse issue but a Java one. From my little knowloedge 
of jars, I do know there is this packaging version concept (which goes much further), so why are the rudiments not
mandatory?