Everything that is not part of the final application
For years I was a proponent of bug/issue management systems and worked with open systems like Jira or Bugzilla and also with a lot of proprietary systems. Iâ€™ve used these systems during the development and production/ support phase of the products. Every time I use these systems I spend too much time registering, evaluating and sorting issues. At the end of the project I always get stuck with a dozen of unspecified issues with a vague status. Why is this? Bug tracking systems are not bad. The entire process of registering and tracking bugs is wrong.
What the most effective thing to do when you discover a bug? Registered the bug in a system and track it? Does this solve the bug? It doesnâ€™t. Â You should be busy resolving the bug, not administrating and tacking it!
It is a very early morning in Redwood City. I am currently in a hotel with a great view on the imposing towers of Oracle’s Head Quarters (although it is dark and only a vague outline of the towers can actally be discerned). The largest Oracle show on the planet, the yearly Oracle Open World conference, is about to commence. This year, the largest Java show on Earth – JavaOne – has been incorporated, so that is about to get going too.
Oracle CEO Larry Ellison and top development executive Thomas Kurian are scheduled to discuss “Oracle’s vision for strengthened investment and innovation in Java and describe how Java will continue to grow as the most powerful, scalable, secure, and open platform for the global developer community,” according to an official description of their planned talk.
Today, I will be in the Oracle ACE Director product briefing. This is a gathering of the ACE Directors – a fairly select group of experts and community representatives in various areas of Oracle’s product portfolio, including Database, Fusion Middleware, Oracle Applications and various development tools. Product managers and other Oracle staff – including Thomas Kurian, Executive Vice President More >
The installer of version 1.6.10 (and 1.6.8) of TortoiseSVN has a bug that leads to an incomplete update. You must run the installer a second time and choose the second time the ‘Repair’ option for a proper upgrade. One of the symptoms of an incomplete installation is an exception when trying to compare office files due to missing Diff scripts in the Diff-Scripts directory.
De system directory is where JDeveloper stores the user specific settings, configurations and also (for 11g) the default domain of the embedded weblogic server. It uses the JDEV_USER_HOME environment variable to dettermine the location. If it’s not set is uses a default directory, for 11g on windows XP that’s <user dir>\Application Data\JDeveloper\systemXXX (XXX stands for the exact IDE version, e.g. system188.8.131.52.37.56.60 for 11gPS2, 184.108.40.206.0) and for 10g that’s <JDev install dir>\jdev\system (no version included). Note that the Application Data directory contains a space. And although this doesn’t prevent JDeveloper and the embedded weblogic from proper functioning, it may sometimes leads to an issue, e.g. that diagnostics (adrs) cannot create an image.
To change this directory, just add the JDEV_USER_HOME environment variable and set it to the required directory, that must not contain a space in the name and when you restart JDeveloper it will use that directory. However, you’ll notice that JDeveloper will now consider itself an almost new installation, without your custom configuration and no default weblogic domain but with installed extensions. It should be able to copy More >
Source control is off course an essential part of the development process and Subversion is an excellent system for that purpose. In the past, installation of subversion was a bit complicated because it involved several steps, an Apache webserver and not-so-accessible user management and repository configuration. However, nowadays installation and management can’t be easier, on whatever platform you are either with Collabnet Subversion Edge or with VisualSVN Server.
Although JDeveloper provides loads of libraries out-of-the-box, you often need other libraries in your application. You can easily add these libraries via the project properties. This provides two options: ‘Add Library’ and ‘Add Jar / Directory’. We normally us the Add Library option because it allows to include the JavaDoc and the source code. However make sure that you check the ‘Deployed by Default’ checkbox or else the library will not be included on the classpath and the application will fail with a java.lang.ClassNotFoundException. By the way, we never use Tools -> Manage Libraries because we only use project libraries and never the user or system libraries, because they introduce local dependencies that need to be maintained at every workstation seperately.