More JCAPS Impressions

I haven't had much chance to post since starting my new position. Getting up to speed in my new role has kept me busy. I have been using JCAPS though and thought I'd post a quick update on my impressions.

Basically the good is still the good, but my team and I are experiencing more pain points, mostly due to the poor repository integrated into the tool. Here's a quick list of things I'd like to see improved.
  • I've gotten in the habit of diff'ing my changes against the repository version to ensure I'm only checking in changes I've intended. JCAPS does not allow you to do this. There's also no easy way to diff changes between different repository versions. You need to be creative, and go outside to tool for this functionality.
  • There's no easy way to find all the files you have checked out of the repository. You need to manually keep track of the files you've touched. I've become accustomed to relying on my development tools to keep track of this for me, so this is a pain.
  • We're having a hard time coming up with a good maintenance plan. The repository does offer tagging and branching, but these terms in a JCAPS repository seem to mean different things than they do in CVS. When you tag a set of files for a JCAPS release, there does not seem to be way to grab all these files as a single unit. In JCAPS, a tag is more of an informational item, like a comment. Branching seems to be more like CVS tagging and branching combined (versioning a set of files together and setting up an alternative development path). Missing is the ability to merge into the trunk.
  • Aside from the repository, we've been having problems with things as simple as generating javadocs from the the JCAPS Designer. Again, we're forced to go outside the tool to get this functionality.

The more I use JCAPS, the more my wish list for new features grows. I'm hoping the next version of JCAPS will address these problems, but I've been unable to find much information about the upcoming enhancements or a release date. At this point I'm finding JCAPS helpful for quickly laying the interface plumbing (connections to a DB, web service, queue, etc) between applications (or application components), but painful for almost everyhting else.

Comments

Unknown said…
Agreed, JCaps leaves much to be improved on. Very Kludgy product.
December 27, 2007 at 12:45 PM
Vinnie said…
Another JCAPS gripe....
No automated build script
January 2, 2008 at 1:01 PM
Post a Comment

Popular posts from this blog

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more