Andrej Koelewijn

This is in response to a thread on OTN forums:

We’re working with 3 developers on a project, and yes jdeveloper 10.1.2 does have cvs problems, but you can learn to live with it.

Some tips:
1. Devide your work into different projects: Our workspace contains about 9 projects, and mostly we’re working in different projects.
2. Use a code formatter. We run jindent as part of our ant build script. Running the build is mandatory before checking code into cvs, and recommended before doing an cvs update.
3. Update often. I start my day by updating my code from cvs. And i do this at least 4 or 5 times per day.
4. These are the steps i take when commiting: cvs update, build, commit.
5. Commit often. Break up your code changes into pieces of work which can be implemented in one day. Commit when you’ve implemented a change. Don’t collect a weeks worth of changes before commiting.
6. Clean update .jpr/.jpx files containing conflicts. Usually it’s easiest to just take the last revision from cvs and reapply your changes to the project file.
7. Run a continous integration tool. We use cruisecontrol. Whenever someone commits changes to cvs, cruisecontrol will rebuild your complete project. If someone has commited a change which breaks the build he will be emailed, and requested to fix the code in cvs. This will improve the confidence your developers have in quality of the code in cvs, meaning that they’ll probably update more often, and have to deal will smaller updates and less conflicts.

Brian Duff posts about code folding in Jdeveloper. I think i’m in same camp as Brian on code folding: nice, but probably not for me.

Some weeks ago a colleague mentioned that he liked the code folding in visual studio very much, and that he would like to see the same thing in Jdeveloper. My reaction then was: why? What use is code folding. To see the contents of a class without all the coding details? I use the structure view for that. Want to edit a specific method? Just select it in the structure view. My feeling is that once you start using code folding, you needlessly spend a lot of time opening and closing code blocks.

Marathon is a very nice tool to test swing applications. You can write test scripts using python, or you can have Marathon record your actions. The result of this is a python script which looks like this:

useFixture(default)
def test():

    window('My Application')
    click('JTree', '/Someone/Contact Data')
     select('sexComboBox', 'F')
    select('weightFormattedTextField', '90')
    assertText('statusLabel','')
    select('dateOfBirthFormattedTextField', '01.01.1900')
    close() 

You specify which components you’re using by refering to the component name, which you can set using setName() on every component. In jdeveloper you’d expect that if you specify name in the property sheet of a component that jdeveloper would generate a setName call in your code. This is not the case however. Instead it changes the instance name of the component, which isn’t bad either, but not very helpfull if you’re creating marathon scripts. You’re test scripts will be a lot less readable. In the example above, i didn’t manually call setName for the JTree component. If i’d had 3 JTree components they would have referred to as JTree, JTree1, JTree2.

I’ve created a small utility which will set the name of a component and it’s child components by taking the instance name and calling setName on the component. Might be usefull if you’re using Marathon.

package nl.iteye.swingtest;

	
import java.awt.Component;

import java.awt.Container;

import java.lang.reflect.Field;

import javax.swing.JFrame;

import javax.swing.JPanel;

	
/**
 * @author Andrej Koelewijn
 */

public class TestHelper {
  public TestHelper() {
  }

  public static void setComponentNames(Component parent) {
    if (parent instanceof Container) {
     Component[] childs = ((Container) parent).getComponents();

      Field[] fields = parent.getClass().getDeclaredFields();

      for (int i = 0, n = fields.length; i < n; i++) {
        if (Component.class.isAssignableFrom(fields[i].getType())) {
          try {
            fields[i].setAccessible(true);

            Object o = fields[i].get(parent);

            if (o != null) {
              ((Component) o).setName(fields[i].getName());
            }
          } catch (IllegalAccessException e) {
          }
        }
      }
      for (int i = 0, n = childs.length; i < n; i++) {
        if (childs[i] instanceof Container) {
          TestHelper.setComponentNames(childs[i]);
         }
      }
    }
  }

}

The company I work for, IT-eye, is part of Redwood. This week Redwood announced that it has an OEM agreement with SAP. This basically means that the Cronacle batch scheduling system will be part of every SAP Netweaver installation. This is good news for Redwood, but also for all SAP customers, as Cronacle is one of the better batch schedulers available.

Shay Shmeltzer wants to know how you do deploy your j2ee applications.

Multiple ways:

Ant – We want to be able to do a full build without jdeveloper installed. Our continuous integration build runs on a linux server using cruisecontrol. We’ve put all libraries used (including bc4j and adf) into cvs, and using cruisecontrol we tag all sources in cvs, build all ear files and deploy every build. This way we know exactly which version is installed on every application server and what we’re testing, and which version needs to be checked out from cvs when we want to patch a bug.

10g Web console – Cruisecontrol installs the ear files on a test server and copies the ear files to an ftp directory. If we want to deploy an application on another server (say beta, or production) you can download the generated ear through a link on our project wiki. These ear files we install through the web consoles of the servers.

jDeveloper – When developing and testing an application on my development machine, i’ll build the ear file using ant. Then i’ll deploy it to an oc4j instance running on my machine using jdeveloper. (right click on the ear file, deploy to). But i don’t deploy locally build ear files to a general purpose test server, as i want to know exactly which files from cvs the users are testing.

Over on javalobby Sebastian Ferreyra is wondering why the embedded browser hasn’t caught on. He thinks embedding a webbrowser in java Swing applications could be really usefull.

I Agree. On my current project we’ve implemented the reporting part of a swing application using an embedded browser.

My first thought for reporting was to use one of the existing reporting components, e.g., jasperreports. So i downloaded jasperreports and a visual report builder, ireport, to see how it worked. I didn’t like it: another xml language to learn, no separation of content and layout, and a visual designer which was a pain to work with. All in all, not a very productive way to create reports.

Actually, i’ve never liked visual reporting tools. I’ve used Oracle Reports in the past, and i found it rather frustrating: it feels like you’re forever moving your elements to get the layout just right.

Html is so much easier, nice separation of content and layout, with easy to use css style. I thought we’d be much more productive by just creating html reports and showing these using an embedded browser.

So first question is, which browser component? I tried the jdic browser component. It works, next question. How do we print? Jdic allows you to print documents by asking your desktop to print the document. Again, this works sufficiently, on windows that is. Your mileage may vary on other platforms, but this is not an issues for us.

How to generate the Html documents? Our solution is to use velocity. Embedding the velocity templating engine in your swing application is pretty easy. We simply put our javabeans based domain model in the velocity context, and can access all our data in our templates. Designing the html pages is pretty productive using the visual html editor in jdeveloper.

So what are the problems? Css support for printing. Well not really the css support, it’s more that the browser support for css for printing is lacking.

Our biggest problem is controlling the page margins and the page header and footer. Your browser controls the page margins and headers and footers. If you want to change this you have to change the page setup using the browsers options, you cannot do this in your css stylesheet.

Another problem is that current browsers do not support specifying page orientation through css. So if you want some reports printed in landscape and some reports using portrait, you have a problem.

Anyway, we can live with these problems and find that using html to create reports is a lot more productive than using an existing reporting component. And the situation will only improve when browsers will finally start supporting the newer css standards.