Last Friday is a bad day for me. I spent three hours in deploying an Eclipse plugin. The plugin was written by another developer. I copied it into my Eclipse plugin directory, everything is fine. Then I made some source code changes and recompiled the package using "javac" and "ant jar" commands. Copied the new jar to plugin directory. It just did not work. Giving me "class not found" exception when Eclipse tried to load the plugin.
AfterI read some online guides about writing Eclipse plugins, I figured out how. Seems I have to create an eclipse plugin project, write the source file, test the plugin using Eclipse runtime test environment, then export the plugin. The magical thing is in the export phase, some meta data is generated for the plugin and saved in a property file, which will be used in plugin deployment. Also I noticed potentially there are two ways of organization of eclipse plugin file, possibly depending on the Eclipse version. I still haven't figured out why my original way of compiling and packaging failed. Because I manually inserted some meta data too.
One lesson, when you are new to something, better stick with a tutorial first. Don't think you know how things work and waste time.
Monday, March 27, 2006
Perforce vs CVS
In my current job, I am required to use Perforce to do version controlling. Perforce is a better versioning tool than CVS, more advanced, complicated and stable. Since I always use Eclipse as my Java IDE, I tried to find a good Perforce plugin for Eclipse. The result is not so good.
I didn't find a tool that can have "Team Synchronization" view like the CVS plugin. So when somebody else editted and checked in (submitted) a file which I didn't open for edit in my client space. I will not know such changes in Perforce. Whereas such change is very easy to view when I do a "Team Synchronization" using default CVS plugin with Eclipse. So now I can only blindly update the files I didn't open for edit in Perforce. I really don't like this idea.
Another thing I don't like is that you have to manually mark a file "Open for add" (Or delete) before you can check in(submit) the change into the depot in Perforce. When you create a file using CVS plugin, a nice commit sign will be posted on the file you just created in the Team Synchronization view, which reminds you this is a new file that should be checked into CVS.
I guess the CVS plugin is so proactive which makes me like CVS, even though I know it's not perforce's fault. I just can't find a tool equivalently powerful as the CVS plugin for Perforce. I have to live with how things work and hopefully I will like it after a while.
I didn't find a tool that can have "Team Synchronization" view like the CVS plugin. So when somebody else editted and checked in (submitted) a file which I didn't open for edit in my client space. I will not know such changes in Perforce. Whereas such change is very easy to view when I do a "Team Synchronization" using default CVS plugin with Eclipse. So now I can only blindly update the files I didn't open for edit in Perforce. I really don't like this idea.
Another thing I don't like is that you have to manually mark a file "Open for add" (Or delete) before you can check in(submit) the change into the depot in Perforce. When you create a file using CVS plugin, a nice commit sign will be posted on the file you just created in the Team Synchronization view, which reminds you this is a new file that should be checked into CVS.
I guess the CVS plugin is so proactive which makes me like CVS, even though I know it's not perforce's fault. I just can't find a tool equivalently powerful as the CVS plugin for Perforce. I have to live with how things work and hopefully I will like it after a while.
Hibernat hates Spring
Hibernate is a cool object-database mapping tool. Spring a J2EE framework. They work together greatly in my previous job. Today I saw an interesting article.
http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/
I think the reason is Hibernate don't want Spring to limit its usage. Since it is a product supported by JBoss now, hibernate wants more freedeom. Not only to change its interface easier, but also upgrade itself into a framework tool, which is what Spring has been doing.
Enterprise tools just seem to be growing more and more complex and difficult to use. I hope I can still stick with EJB2 with the help of a nice eclipse plugin named Lomboz. It has some limitations, but very nice after played for a while.
Today, sounds like EJB3(Hibernate3) is the only solution. I have read some tutorial to able to discuss with people about J2EE.
http://houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/
I think the reason is Hibernate don't want Spring to limit its usage. Since it is a product supported by JBoss now, hibernate wants more freedeom. Not only to change its interface easier, but also upgrade itself into a framework tool, which is what Spring has been doing.
Enterprise tools just seem to be growing more and more complex and difficult to use. I hope I can still stick with EJB2 with the help of a nice eclipse plugin named Lomboz. It has some limitations, but very nice after played for a while.
Today, sounds like EJB3(Hibernate3) is the only solution. I have read some tutorial to able to discuss with people about J2EE.
Subscribe to:
Posts (Atom)