Last week I started using Eclipse 3.4 (Ganymede). There are a ton of new subtle enhancements along with the new major features. One of the subtle features I immediately appreciated was not even in the Workbench or Java Development User Guide’s What’s new documentation. It is a minor enhancement to the Classpath Variables which makes working with a local Maven repository so much easier.
Let me start of by explaining what Eclipse Classpath Variables are. As you probably already know, fully qualified paths in code or configurations are a sign of a code smell. It often leads to comments like “It works on my machine”. In Eclipse projects, this commonly happens in adding Libraries to the classpath. Many developers use the Project > Properties > Java Build Path > Libraries and press the Add External Jars button to add jars. This causes a fully qualified path to the jar to be put in the Eclipse .classpath file. If other developers on the team do not have the exact same path, sharing the .classpath file via version control does not work. So I have seen many teams choose to not version control the file to get around the problem. Unfortunately that is not the answer because it takes longer to set up new developers and also leads to “It compiles and runs on my machine” since everybody is using a different library configuration. Another problem that often happens is one developer adds a new library dependency and other team members start getting ClassNotFoundExceptions or code from version control no longer compiles because they didn’t know a new jar dependency was added.
Classpath Variables can solve this by configuring a variable starting point in the classpath and then using the Add Variable button on the Libraries tab of Java Build Properties rather than the Add External Library button, jars can be added in a much more flexible way. As a mater of fact, just two weeks ago when I presented my 10 Eclipse Productivity Tips at COJUG somebody said we had that problem on my last project so we stopped checking in that file because one person didn’t want to conform. After the presentation she realized Classpath Variables could have solved that.
For Maven users a Classpath Variable of M2_REPO is often used and configured to the top of their local Maven repository. Unfortunately, maven repositories can often get very deep and may contain multiple copies of the same or similar jars in different locations. So, navigating the directory structure to add many dependencies can be very time consuming. This is where the new Classpath Variable feature comes in. A new filename filter was added making it easier to see all the jars at once or farther narrowing can be done.
Random thoughts about my interests in Java, consulting, scripting in Java and software development (especially for small and medium size organizations).
Subscribe to:
Post Comments (Atom)
AWS EC2 Hibernate Java SDK v2 Example
I recently wanted to automate the creation of developer VMs in AWS using EC2 instances. To improve the developer experience (DX), I didn'...
-
In May of 2009, I wrote the blog post The Ultimate Enterprise Java Build Solution . Over the past 7 years since I wrote the post I have help...
-
Early in my career I took on the role of setting up and operating the build infrastructure of many of the projects I have consulted on. I st...
-
Class loading issues are a common frustration for many Java developers. The dreaded java.langClassNotFoundException means they can forget a...
No comments:
Post a Comment