Classpath management, why bother?
In a recent post, Wayne pointed out several benefits brought to you by PDE and WTP tooling. In particular, if you are developing bundles or web apps, these tools take care of the horrendous classpath management task for you. Thanks! His post reminded me of something that I’ve been talking about for sometime and been meaning to blog about.
I’ve been writing plug-ins/bundles for so long now I have a hard time relating to folks living in barren world that is plain old Java programming (POJP?). Not a modular runtime in sight? No classpath management in the tooling! Alone. Just me and a linear, static classpath. Eerily scary.
One day I was cast upon the rocks as it were and asked to look at an application that came as 5 JARs/projects. After some fiddling I managed to get the various build paths setup. Having done that, I needed to reorganize some things. Well, didn’t that just suck. I ended up spending alot of time playing with build paths trying to resolve circularities and …
To be honest, most of the issues I had were actually user-error. Nonetheless the frustration was real enough. After all, I am just a user. The fact that there are so many opportunities for error in classpath management means it is just begging for tooling.
Then I had an epiphany. Why not make everything into Plug-in projects?! Plug-in projects have classpath management. Why not just define a plug-in for each JAR? Heck, there is even PDE wizardry that will take care of generating the required manifests and then build and manage the build paths. Bliss!
So I did just that and even got a little trickier and used some of the visibility statements like x-friends and x-internal in the manifests to make sure I wasn’t doing bad things in the code I was refactoring. Life was good. I didn’t have to look at the build properties again. I was told when I accessed something I wasn’t supposed to. I could reason about the JARs and what was where. I was even able to build the JARs using PDE’s export operation.
You may get a bit bummed however when you go to run. When you launch an Eclipse application or OSGi framework there is no need for PDE to compute a classpath. The framework does that for you at runtime. When you launch a Java application however, someone needs to compute a static, linear classpath to give to java.exe. [Correction pointed out by Ed] If all your plug-ins are in the workspace then the Java launcher will use the project dependencies (also managed by PDE) to create a classpath. If you are using something from the Target Platform however JDT doesn’t know about it. Here it would be great to have a way of sorting the plug-in dependencies and generating the required classpath automatically. We’ll have to see if someone implements this (hint hint)
Anyway, that’s it. Next time you find yourself doing “New > Java Project” consider doing “New Plug-in Project” and using PDEs classpath management technology to free yourself from the hassles of build paths. You will be in good company. The EMF folks do this on a regular basis. As do the Harmony folks.
Posted July 25th, 2007 by Jeff McAffer in category: Uncategorized
You can skip to the end and leave a response. Pinging is currently not allowed.
9 Responses to “Classpath management, why bother?”
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
Eugene Kuleshov Says:
July 25th, 2007 at 11:26 pm
Jeff, I think you are getting it backwards. What if your project depend on other 50 modules, it isn’t really great idea to add each of them as a project.
I think the only relevant part of the PDE plugin project is the classpath container it manages based on some internal metadata. So, why don’t extract that metadata, publish it somewhere and create classpath container that would be capable to fetch this stuff. Oh wait! There are tool that already do that. Unfortunately they won’t work with PDE as it is. To my surprise, even WTP is now more flexible and extendable then PDE.
Chris Aniszczyk Says:
July 26th, 2007 at 8:58 am
Eugene, in the beginning PDE wasn’t designed to be a “Platform”
The P in WTP stands for Platform. However, the PDE team is trying to slowly change that and add more extensions for people to plug into.
Give us time
Jeff McAffer Says:
July 26th, 2007 at 9:51 am
Eugene, the metadata has to go somewhere. Yes there are several options for this and adding everything as a project is not a good idea. It is also not required. I completely agree that having more flexibility around how/where the metadata is managed is a good idea. As I’m sure you were implying (but were too shy to say :-), Maven has an approach to this. That certainly is one approach and it has its benefits and drawbacks. I’m not going to argue the point by point merits because anything that improves modularity and makes developer’s lives easier is a good thing. What I will say is that plugin developers have been living the dream for some time now and having generic modularity support as part of JDT/Eclipse would be really cool.
Aaron Digulla Says:
July 26th, 2007 at 11:08 am
That’s why many people use maven: maven provides any JAR put there (well, almost) as a “plugin” and you only say “I want hibernate 3.2.1 in my project” and it puts the classpath together for you. It even downloads the JAR if you don’t have it (with source if it’s available).
If you use the “Maven Extension for Eclipse”, you get a new classpath container in your Eclipse projects with all the maven dependencies.
Ian Bull Says:
July 26th, 2007 at 11:21 am
Another thing I thought would be cool, would be an “export as java application”. I work like you do Jeff (everything is a plug-in, well occasionally I have a few jars here and there). But when it comes time to export all this to give to someone (when I am not using an OSGi runtime) it becomes a bit of a nightmare. I usually export all my jars and then write a small shell script (plus a bat file, something they use in Windows) that includes java -jar blah; blah; blah myfile, etc…
it seems this could all be automated.
I mentioned this to Wassim, but it seems it is a bit of a chicken / egg problem. The JDT needs to know about the stuff you specified as Plug-in projects, but the JDT doesn’t know about the PDE. The PDE could support this, but the PDE is not really in the business of exporting java applications.
Kevin McGuire Says:
July 26th, 2007 at 12:24 pm
Jeff, I seem to recall sitting in your office lamenting the same issue. I wasn’t sure you “felt the pain” but now its clear you do (as I wipe a tear from my eye).
The development environment does such a wonderful job of shielding you from classpath issues but that illusion completely breaks down as soon as you try to run the stuff as an RCP application. It is then that you stare in the chasm of classpath horrors, alone and afraid. One reason for the gap I think is that up that point you’ve been able to remain blithely unaware of classpath issues, but now you’re getting these obscure bundle errors and left scratching your head.
One solution is to make the developer more aware of classpath reality all the way along but that’d be a regression. So the solution is to complete the picture at the JDT level (whatever that means though isn’t clear to me).
Wassim Melhem Says:
July 26th, 2007 at 1:21 pm
Eugene, I don’t recall seeing a bug report from you or anyone else asking for the PDE classpath container to be extensible in any way.
We are awesome developers, but we are not mind readers.
Eugene Kuleshov Says:
July 28th, 2007 at 10:55 am
@Wassim, you even commented on that bug - https://bugs.eclipse.org/bugs/show_bug.cgi?id=124542
@Chris, there is no “P” in JDT either, and yet it is has brilliant build patch management facility. Kudos to whoever designed it. WTP just started using these features, though I wish they’ve done it less WTP-centric.
@Jeff, I wasn’t actually thinking of Maven when was writing it. My concern is that PDE can’t really fetch missing dependencies. It doesn’t really matter which mechanism is used, Maven or Ivy, or Buckminster, or mysterious OSGi bundle repository service. There is already metadata in OSGi and PDE, though it isn’t sufficient for the task, but perhaps it could be extended to specify where to look for the dependencies.
Jeff McAffer Says:
July 28th, 2007 at 3:21 pm
yes. we’d like to do some prereq component discovery and acquisition with the new provisioning story