Eclipse

As I discussed Subversion a year ago, dated back to July, 2006, it’s of great functionalities compared with the old versioning system, CVS. Currently, finally I have a chance and time to try it out.

The learning curve of SVN is comparatively easy, perhaps it’s due to the similar structure and interface to CVS. I just used two days to catch it up and switching a project from CVS to SVN successfully.

The major idea of SVN is the fact that it controls versions for a bunch of files, instead of one version for one file. In real case, we developers add a feature to software by manipulating bunch of files. Using CVS, we need to set up clear policy on making commit logs in order to let other developers know what you did for that feature. In case someone doesn’t follow the policy, everything will be messed up. For SVN, you commit a few files by saying these changes are for the same feature. Then, other developers are clear that why did you modify those files.

Moreover, one thing that is good for SVN is the better API I think. I am not sure about the actual infrastructure, but the fact is that there are many web applications, particularly issue trackers, that can query the SVN repository to display many different kinds of reports. For instance, I used one open-source software namely “Trac” which helps me relates the issue tracking progress to the changes on SVN. Trac can also query the SVN repository for revision comparison.

I can see switching to SVN is a trend in version control system development. At least many open source project has already switched to the SVN repository. It is easy to install, easier to control, and most importantly it is similar to using CVS as a client.

Install Instructions of Subclipse (SVN support on Eclipse): http://subclipse.tigris.org/install.html

Subversion Book: http://svnbook.red-bean.com/

Trac Project: http://trac.edgewall.org/

I’m just starting the development of applications using Java Persistence API (JPA). In fact, the most challenging thing comes up to me at my start, the compatibility of IDE.

JPA is co-developed by the team of JavaEE 5 Specification Group, as a replacement to the heavy-weighted Entity bean. Until now, there are limited IDE that supports the development of JavaEE, especially EJB 3.0. Two of them are Sun Netbeans and Oracle JDeveloper. Both of them are free, but not open-sourced IDEs.

I personally use Eclipse as my primary development tool, thus quite familiar with the functionalities within. However, Eclipse for now just provides a plugin project named “Dali” for the development of Java Persistence. However, Dali have lots of bugs and seems suspended from Aug, 2006. That’s why it’s not a good choice to use.

Instead, in order to develop JPA easily and still use Eclipse as my major platform, I have the following methods.

1. Develop JPA related things in Netbeans, including the Entity itself and the configuration of persistence.xml file
2. Export those Entities and required settings to JAR file using Ant Script
3. Import the JAR file and other required libraries into Eclipse
4. In Eclipse, just like developing usual applications, and for the persistence part, call the methods of Entity.

This is not a very good method, since there are so many troubles in between. But at least, it helps me to do more with JPA easily

Is there a good method to analyze a large amount of code, by providing a flatten, simple and clear diagram, telling you the relationship of classes and the call stack, also the ad-hoc status of each particular object? Eclipse Profiler may be one of the tools.

There is recently an article on TheServerSide introducing this free plugin of Eclipse. Go and take a look:

Code Analysis with the Eclipse Profiler by Peter Dawson

Following the tutorial will cause two main errors, which waste me much time searching the solution over the web.

1. When you run XDoclet, which ask the xDoclet to create relevant xml or classes for you, it will prompt you the xDoclet cannot be run. Even if you use another version of JBoss-IDE, or add a plugin of xdoclet-1.2.3, it still cannot.

Actually, the easy solution is to use JDK 5.0 when running xDoclet, that means even the development should be based on JDK 1.4.2, when you run xDoclet, you should switch to JDK 5.0 temporarily. But ensure that switching back to JDK 1.4.2 afterwards, or otherwise the development may use the “new” stuff on JDK 5.0.

2. The other thing is when deploying the *.ear file to JBoss AppServer 4.0.2, it causes an exception saying the web.xml misses ejb-link, I don’t know what it is. But the solution is when making the servlet class, which will be included in the *.war file, the @web.ejb-ref should contain link=”Fibo” as well. So when it is generating the web.xml, the tag will be included.

Currently, there is a new Version Management technology that comes up with attention. It is named Subversion (SVN). It’s new to me and I just know people start using it because they doubt the function of CVS being commit the files one by one.

The following article talks about how to use SVN with Eclipse. Let’s start with it and look at the “power” of SVN.

Quoted from RootPrompt.org:

From the beginning, Eclipse included tight integration with the Concurrent Versions System (CVS) in order to provide access to change-management capabilities. Now, many projects — notably those run by the Apache Software Foundation — are using a different change-management system: Subversion. This article demonstrates how to add Subversion support to Eclipse and how to perform basic version-control activities from the IDE.