Notes and other thoughts

PerforceNB 1.0.5.1 build for 6.9 - Call for help!

2010-07-27T15:58:00.001-07:00

I am aware that in this new modern world, one of the main problems is time. That happens to me, also. I don't write here to complain about that. I write this call only for two things.
First is to thank everybody who have enough patience to try and use this plugin. I write this plugin only to give something back to NetBeans and to NetBeans great community. That thing is enough.
The second thing is that I ask for some help from you, the guys who spent time and nerves using this plugin. If you want to contribute to this plugin, you are welcomed. Just ask for proper rights. If you can't afford time for that, please fill bugs and suggestions. As many as possible. I can't cover everything and I am sure you have many brilliant and useful ideas to make your and mine life easier using this plugin.
Finally, thanks to all of you. NetBeans rocks!

http://kenai.com/projects/perforcenb/pages/Home

2010-04-21T06:21:00.000-07:00

PerforceNB 1.0.4 is available.

New features

Make actions work with ignored files
Ignore management of file based on mask and absolute paths (now there is only for relative to project paths)
Opened files viewer (all opened files with all changelists)
Refresh, Revert and Revert Unchanged actions for opened files viewer

Solved important issues

Ignore management does not work properly
Fix connection selection dialog box

Known problems

Projects located outside perforce root directory are not properly managed
Refactory and some actions are not working properly

You can download and read about on PerforceNB Home page.

PerforceNB 1.0.3 beta release

2010-03-12T05:27:00.000-08:00

PerforceNB is a Perforce version control client for NetBeans IDE.

Today I released the version 1.0.3 which I consider is a beta quality release.

The features available for 1.0.3 are:

Connection configuration, multiple connection, each project can have its own connection
Colored labels and version information in Project View, File View (local and depot revision)
Implemented actions:
- Manage / Unmanage by perforce (on projects)
- Add
- Edit
- Delete
- Revert
- Revert unchanged
- Refresh (don't sync, just refresh the cache below and redraw the interface)
- Diff against have revision
- Submit (works only with default change list)
- Manage connections (creates, edits multiple connections)
- Sync action (on selected file/files/folders/project). You can sync from the latest version or from a specific changelist.
Out of sync decoration for updated files with different revisions
Cache is now persisted on local storage when NetBeans is closed, and is reloaded from local storage when NetBeans open projects. Now there is no need to query Perforce server when NB starts for every project. This is a big improvement when we have many projects, loading is very fast.
Ignored files management (rules for all projects). (In the next version will be added support for ignored files based on mask and on absolute paths.)
Automated actions (add, edit, delete, move)
Option to enable/disable the automated actions
Icon marking projects managed by perforce system (enable/disabled depending if there are pending actions or not).
a lot of bug fixes

You can download and read about on PerforceNB Home page.

Five things I like most at NetBeans Platform 6.8

2010-03-08T03:19:00.000-08:00

NetBeans 6.8 is there since December 2009. It did not look like a very important upgrade at first. At least not very important for Platform developers. But using the new version of platform, some things which may appear small at first, has been visibly improved. The most important improvements are listed here (according to my personal feelings). For a complete overview of changes in platform API you can take a look here.

Wrapped libraries
That was one of the major headaches source. Developing modules for NetBeans (as for other platforms) requires sometimes links to other libraries. Third-party libraries, other than the modules provided by the platform, needs to be linked and wrapped in your custom pluggins or platform-based applications.

Wrapping libraries was done in the past in two ways. By creating a module library wrapper plugin for every library which need to be imported. But when you have to link a bigger library, which have a lot of jars, that was a pain. Because a module library wrapper could be created only for one jar. You can end up with easy to have twenty-thirty libraries only to link to something like apache logging libraries or Seam or similar.

The second approach was to create a big jar with all jars from library. For this operation, NetBeans is helpfull, but you have other two problem to solve. First is that the new jar will have it's own manifest. That means that if there is information in manifest files of every jar, that information is lost or not complete. If that information is important, you have a nice problem to solve. The second is that you can loose control over which libraries you have, which versions. Become very difficult in time to maintain the upgrades.

Solution is the new wrapped libraries feature. Now each plugin module in NetBeans can have it's own dependencies on external libraries. For configuration, you have a new tab panel to add as much as needed libraries. The cool thing is that you can specify also the source code and javadocs for every wrapped jar. That was not possible in the old versions.

ActionListeners are everywhere

That could not look as important as it is. In the old versions you could use ActionListeners only for always enabled type of actions. Not you can use the same interface also for context aware and callback action types. That is really cool, even it does not sounds like that at first. A main aspect here is that it is used a "well known" interface.

The first consequence is that if you want to migrate a swing-based app on NetBeans platform, is easier because you just have to pipe your actions. The second consequence is that you don't have to use specific platform interfaces like cookies. I don't say that cookies were bad, but they are old and there is better and much usable alternative.

Declarative Asynchronous actions

That's small, but makes code cleaner and flexible. Also throws away the need to manage yourself the asynchronous behavior of your actions. Nice done.

Enhanced IO API

We already had colors and links. And it was very useful. But now is even more flexible.

You can color the output as you like because you can output with IOColorPrint.print. So you can made your output lines from peaces colored independently. You can also put more hypelinks on the same line. You can, again, add an importance marker, which improves readability on verbose outputs. Finally, you can specify the parent of an IOTab and set its icon and tooltip message. All of them are small things, but used together can be very helpful on creating really effective and friendly output for your application. I appreciate very much an application which let you know what is going on.

Annotations

That's not a specific point. There are some very useful annotations added. The point is, thought, not the specific annotations added. But the trend to use as much as possible annotations. I hope that this trend will continue. I already used @OptionsPanelController.SubRegistration and @ConvertAsJavaBean. But there are more, take a look.

PerforceNB 0.2.alpha release

2010-02-22T23:29:00.000-08:00

In the latest time, for some reasons, I could not work on the developing of PerforceNB plugin. The situation is not the same. New releases will come frequently, I expect it very often (2/3 weeks per release) until the plugin has enough features.
In the meantime I release the next version 0.2. This version is different in the sense that almost everything was rewritten from scratch. I think now I understood well enough the p4api provided by perforce and it was time for new ideas.
If you think you need a Perforce plugin for NetBeans please try that. And if you want a better tool please give some time and fill an entry on Issue tracking or on Discussion board.
The source and other information is available on PerforceNB Home

Common misconceptions about EJB

2009-12-23T01:55:00.000-08:00

Java Enterprise is often a topic for many programmers in the free world (non m$ like one, I suppose ..). I don't think it was always a first option. There were and still there are pros and cons discussions. Still, Java Enterprise is an available solution. Thought, with a lot of books and good articles around, I often hear simply "amazing" thoughts about Java Enterprise. What is worst is that many of these are believed by so called Java Enterprise developers.
A lot of people still have some misconceptions about Java Enterprise. How this could happen? Perhaps due to the degree of configuration complexity of the firsts variants of the standard. Maybe because of the rigidity of the Sun guys, who kept in iron hands the previous releases (previous than 3.0). Perhaps because in the past the standard was not under JCP. Maybe none of this. I really don't know. But I will present some thoughts that I heard, and give some opinions on that.
EJB is for web applications
Simply wrong. Java Enterprise has nothing to do with web applications. To be more exact, Java Enterprise has the same link to web applications, as it has with other type of client applications. EJB is about business, about business distributed components and about integration. The consumers of these components can be any type of application that understands JNDI and IIOP, nothing more. Even if we see around a lot of web frameworks that are well integrated with EJB, that does not mean EJB is only for web.
With JPA you don't have to work with databases
I always considered that a good programmer is a lazy person. But a lazy programmer is a programmer which chooses to work less but smart instead of easy but with repeated tasks. If you choose EJB with persistence, than you choose to work with an abstract layer, which models your business. You choose to separate these layers. That does not exclude to improve the performance of database. There are often situations when a proper index can solve a big bottleneck. Don't be extreme on that. Persistence layer let you concentrate more on your functionality, don't exclude tuning database process.
EJB applications are always lazy
That is not true. I agree that Java Enterprise comes with a penalty performance. There is a cost for the ease of design and for generality. My idea is that every design tries to solve some classes of problems in trade of others. The art in application design (if there is one) is to make a good trade on that. It’s like in chess. If you want a benefit you have to leave something. The choices are core of the process. If your choices are good, the penalties are not relevant for your business. Going back to EJB, the initial performance penalties are traded for other benefits. As a sample, putting in place a cluster or a cache is not an easy job in state-of-art systems, in EJB this task is very easy. By choosing what components to be cached, the caching levels, by choosing a proper clustering structure you can benefit a lot. A common thing that is missed is the usage of entity managers. A almost always saw that the entity managers used are the default ones provided by wizards. That’s a bad choice. You must reconsider every opportunity. There are a lot of services for EJB components which can be configured with ease, that's the point. Don't put on work the wizards and consider you work done. You work begun after the wizards. Remember well, the choices are very important, and EJB container makes that job very easy.
Use EJB everywhere, is the best
Nothing is the best for everything. EJB has its place in software fauna. But it’s not best for anything you can think of. Sometimes you must consider using light web frameworks, sometimes is better to use light web scripting languages with fast databases. I can give clear receipts. If I put my two cents in, the rigid thinking does not do you any favors.
EJB is only about components and services for these components
I don’t agree. It’s true that components and container services for these components worth a lot. But there is something more, which I consider at least as important as the previous. This valuable thing is integration with external systems. I lot of people forgot that. But one of the main goals of EJB is the integration of external systems. The integration potential is, sometimes, the main reason to choose EJB in place of others technologies. We can review the times when EJB was put on place. A lot of big software consumers had a lot of big systems provided by different software vendors. It is a usual. Every system produces a part of the big picture. A lot of effort and money and knowledge are buried in those systems. The next step is to obtain the big picture. You can’t rewrite everything from scratch. You have to integrate the existent system. You have to put all the pieces together. EJB is good at that. Did you hear about resource adapters? Did you saw a detailed sample of a CORBA component written in C working with EJB? I bet you don’t. Unfortunately I never saw books with covers well this topic. Three pages from five hundred are not enough, but that is the sad average. I am still waiting for a good book to cover this, to exploit this potential.

NetBeans Platform: Output windows in simple words

2009-11-25T02:30:00.000-08:00

I/O APIs is among the most used modules from NetBeans Platform. This is one of the most common way to show information about your activity. The name can be misleading, but is much simpler that it seems. This module manages the output windows which you already have or you can create, where text information can be put.
There are a a lot of scenarios where you need output windows. You need them to show logs for bootstrapping tasks, to show log information, to receive feedback from a compiler or builder or other type of tool.

The story about output windows in NetBeans can be simple or complicated. The hard way is to implement yourself everything and control everything. That could be feasible if you plan to implement a rich output windows with a lot of controls on it. But for simple scenarios, what you have from the platform is simple enough.

Setup

From your NetBeans Platform module, all you have to do is to add "I/O APIs" as a module dependency. That's all.

"Hello world!" from output window

IOProvider is a factory for output window components. These output windows are represented by InputOutput class and hosted into a container, represented by IOContainer. It's easy and enough to proceed. First, we ask for the default provider to get an InputOutput with a specific title. We can create a new one or get an existing one. After that we activate the output and write to it. Here's the code.

InputOutput io = IOProvider.getDefault().getIO("TestIO", true);
io.select();
io.getOut().print("Hello world!");

Put some colors and behavior on lines

We can easily color the line from output. Also we can put some action on the line. If we create a line with an listener (our listener), the line from output would behave as a hyperlink in a browser. When the listened line will be selected, clicked or deleted, we can do something through listener. Let's see some more code.

try {
    InputOutput io = IOProvider.getDefault().getIO("My title", false);
    IOColorLines.println(io, "This is a yellow line", Color.yellow);
    IOColorLines.println(io, "This is e red important line",
                    null, true, Color.red);
    IOColorLines.println(io, "one dynamic line with event",
        new LineListener(), true, Color.green);
} catch (IOException ex) {
    Logger.getLogger(SameIOAction.class.getName()).log(
        Level.SEVERE, null, ex);
}

[...]
class Listener implements OutputListener {
    public void outputLineSelected(OutputEvent ev) {
        JOptionPane.showMessageDialog(null, "line with content " +
                ev.getLine() + " was selected");
    }
    public void outputLineAction(OutputEvent ev) {
        JOptionPane.showMessageDialog(null, "line with content " +
                ev.getLine() + " was actioned");
    }
    public void outputLineCleared(OutputEvent ev) {
        JOptionPane.showMessageDialog(null, "line with content " +
                ev.getLine() + " was cleared");
    }
}

Put some decorations on output windows

Using another class from the package, IOTab, you can easily add a tooltip text and a small icon on an output window. As a sample:

InputOutput io = IOProvider.getDefault().getIO("My title", false);
IOTab.setToolTipText(io, "My tooltip text for Hello world!");
[..]

And you can do more..

There is also a simple way to add some Swing actions on output window. The output window has a small toolbar on the left side of it. If you pass an array of Swing Actions on the moment of creation, these actions will be available for use on your output window. Just to name a very often scenario: you have a long process to run, you want to give full text feedback, but you want to be able to stop the process when you think is appropriate. Just create a Swing Action to fire the canceling job and add it to the InputOutput.

Action[] actionList = new Action[5];
[..] // add actions here
InputOutput io = IOProvider.getDefault().getIO("My title", actionList);

Thought there are some limitations: you can't put here more than 5 actions and each action should have the property Action.SMALL_ICON defined.

Have fun with InputOutput windows!

PerforceNB 0.1.alpha release

2009-11-05T02:51:00.000-08:00

In the last period of time I worked on a NetBeans plugin for Perforce version system client. This the first release. It has a lot of missing features, still I use it on a daily basis. So it's usable.
If you need a Perforce client for NetBeans like me, give it a chance.
And give feedback. I can promise I will take into consideration.

The home page for plugin is http://kenai.com/projects/perforcenb/pages/Home.
To download it you can use either http://kenai.com/projects/perforcenb/downloads or http://plugins.netbeans.org/PluginPortal.

Implemented features on 0.1.alpha

Connection configuration (basic form, one connection for all opened projects)
Colored labels and version information in Project View and Explorer
Basic operations like add, delete, checkout, revert
Get latest revision (one operation for all projects)
File differences
Submit selection dialog and action (works only with default chagelist)
Automatic integration in Perforce of IDE file operations like create, delete, edit, move, rename
Automatic integration in Perforce of file operations outside IDE

NetBeans Platform: Implement Perforce client - part IV

2009-11-02T17:11:00.000-08:00

Automatically add, checkout, delete or move files
This is the last article about the Perforce client. That does not mean that is fully implemented, niether I will abandon the project. The NetBeans Perforce client will continue to be developed. By me, and hopefully by others. The point with this string of articles it to illustrate in which way it can be implemented a versioning client in NetBeans.

Since last article, the Perforce client was enriched with many functionalities. Thought, only the last one is relevant for our purpose. The topic is how to integrate into Perforce the IDE file manipulation operations like add, delete, rename, move or edit. You can add here also, how to handle the same situations, when files were modified outside IDE.

The key to this functionality is a class called VCSInterceptor. This class is used by NetBeans to announce the eventually versioning system about some change over files. Either if the change was operated form inside or outside of IDE.

I will split the methods from VCSInterceptor into five categories: queries, delete, move, create and change. You can find the source (comments are very intereting to read) here. Take a close look there.

queries
This category contain only one method isMutable(File file). This method is used to ovveride the default behavior proposed by the versioning systems which uses read-only files. When a file is read only, the IDE will see the file in this state, so it will not edit it. But when this method returns true, you let the IDE know that you actually can edit the file, even if is marked as read-only from the file system.

delete
beforeDelete and doDelete work together. The first let the IDE know if you want to implement the delete action for the specified file, in the second method you actually write the delete operation. There is another one method, afterDelete. This method is called after the file was deleted from the files system. Besides the moment of the notification, there is another very important difference. All methods are called when a delete operation was realized from IDE, but only the later (afterDelete) is fired when a file was deleted outside IDE. Take this into consideration when you implement the delete handling.

move
beforeMove, doMove, afterMove. Follows the same pattern as for delete operation. beforeMove is used to tell to the IDE that is want or don't want to handle the file move. doMove implements the real move action and afterMove is called (hard to believe, but ) .. after the mov operation. The only difference from delete is that all operations are called only for IDE file rename/move opertions. For this kind of operations outside IDE, NetBeans will fire two events: afterDelete for the source and afterCreate for the target.

create
Following the same pattern, for create we have beforeCreate, doCreate and afterCreate. Adding new files from outside IDE will fire only the last event (like on delete operations). I will go on, I hate to repeat.

change
This breaks the pattern. There is an beforeEdit method called when a file is about to be opened in edit mode. The is a perfect moment to do a checkout if you are in IDE. After that we have two events, beforeChange and afterChange. These events are related to content. beforeChange is called before the file content are about to be changed. afterChange end the cycle. One thing to mention here is that only afterChange is called if the file is updated outside IDE (javadoc does not mention that, but you can trust me on that). The later is a perfect place to put a checkout for outside IDE file modifications.

Just before presenting the source code for that, I have to mention that you don't need to implement all methods. These methods tries to catch all the possible events for all the possible versioning system scenarios. In my case i found to be enough to implement only 7 from 13. And I hope I covered all.

Here is the interceptor code:

public class PerforceInterceptor extends VCSInterceptor {

    @Override
    public boolean isMutable(File file) {
        return true; // really, for all? we will see that
    }

    /**
     * Automatically add to perforce the new added file.
     * The code is here to handle also the files added from outside IDE.
     *
     * @param file file in question
     */
    @Override
    public void afterCreate(File file) {
        if (PerforceModuleConfig.getInstance().isPerforceExcluded(file)) {
            return;
        }
        FileStatus status = getUpdatedFileStatus(file);
        if (status == null || FileStatus.STATUS_UNKNOWN.equals(status)) {
            try {
                // this is what we really care
                P4Client p4client = PerforceSystem.getP4Client();
                p4client.actionAdd(file);
            } catch (PerforceActionException ex) {
                Exceptions.printStackTrace(ex);
            }
        }
    }

    /**
     * Called when a file is uptodate and is about to be modified.
     * The file is automatically checked out.
     *
     * @param file file in question
     */
    @Override
    public void beforeEdit(final File file) {
        if (PerforceModuleConfig.getInstance().isPerforceExcluded(file)) {
            return;
        }
        FileStatus status = getUpdatedFileStatus(file);
        if (!FileStatus.STATUS_VERSIONED_UPTODATE.equals(status)) {
            return;
        }
        try {
            P4Client p4client = PerforceSystem.getP4Client();
            p4client.actionEdit(file);
        } catch (PerforceActionException ex) {
            Exceptions.printStackTrace(ex);
        }
    }

    /**
     * Check out the uptodate file. The method is called when the file was
     * modified outside IDE.
     * Same logic as {@link #beforeEdit(java.io.File) }.
     *
     * @param file file in question
     */
    @Override
    public void afterChange(File file) {
        beforeEdit(file);
    }

    /**
     * Mark for delete files which are delete from outside/inside IDE.
     * Handle different scenarios depending on the status of the file.
     *
     * @param file file in question
     */
    @Override
    public void afterDelete(File file) {
        try {
            P4Client p4client = PerforceSystem.getP4Client();

            FileStatus status = getUpdatedFileStatus(file);
            if (status == null) {
                return;
            }
            switch (status) {
                case STATUS_VERSIONED_ADD:
                    p4client.actionRevert(file);
                    if (file.exists()) {
                        file.delete();
                    }
                    break;
                case STATUS_VERSIONED_UPTODATE:
                    p4client.actionDelete(file);
                    break;
                case STATUS_VERSIONED_EDIT:
                    p4client.actionRevert(file);
                    if (file.exists()) {
                        p4client.actionDelete(file);
                    }
                    break;
            }
        } catch (PerforceActionException ex) {
            Exceptions.printStackTrace(ex);
        }
    }

    @Override
    public boolean beforeMove(File file, File file1) {
        if (PerforceModuleConfig.getInstance().isPerforceExcluded(file)) {
            return false;
        }
        return true;
    }

    @Override
    @SuppressWarnings("fallthrough")
    public void doMove(File source, File target) throws IOException {
        try {
            P4Client p4client = PerforceSystem.getP4Client();

            FileStatus status = getUpdatedFileStatus(source);
            if (status == null) {
                return;
            }
            switch (status) {
                case STATUS_VERSIONED_UPTODATE:
                    p4client.actionEdit(source);
                case STATUS_VERSIONED_ADD:
                case STATUS_VERSIONED_EDIT:
                    p4client.actionMove(source, target);
            }
        } catch (Exception ex) {
            Exceptions.printStackTrace(ex);
        }
    }

    /**
     * Retrieves the file status. If the cache is not hit, we do it the hard
     * way, we push in cache the value from perforce system.
     *
     * @param file file in question
     * @return the status of the file or null if the file is not handled at all.
     */
    private FileStatus getUpdatedFileStatus(File file) {
        FileStatusCache cache = PerforceSystem.getCache();
        FileInformation fileInfo = cache.getFileInfo(file);
        if (fileInfo == null) {
            cache.refreshFiles(new String[]{file.getAbsolutePath()});
            fileInfo = cache.getFileInfo(file);
        }
        return (fileInfo == null) ? null : fileInfo.getStatus();
    }
}

As I said, foolow the source code and the project PerforceNB on kenai site at http://kenai.com/projects/perforcenb/. See you.

Dynamic libraries in NetBeans

2009-10-13T06:57:00.000-07:00

I hear often that NetBeans is not as configurable as Eclipse (as a sample). Don't want to start a religious blind war, you'll find nothing like that here.

Regarding this problem my answer is that NetBeans is configurable, but not in a ways as you would expect at the first glance. NetBeans for some things offers a limited GUI to manage things. As a sample, when you create a library. You have a GUI which gives you the possibility to create one. You can build that library only in one way: by selecting individual jars and folders for classes, sources and javadocs (I talk about Java SE libraries). If you want to create a customized library, there's no other GUI possibility.

But you have programming. By offering a friendly and stable API you can extend the platform and IDE as you like. If you know Emacs and Lisp you know what I mean. Is the same philosophy as in Unix/Linux world. No need of GUIs with thousands of screens full of usually unused information. A text file well commented is more than enough. In NetBeans is translated: "You have a very well documented API, stable, samples, why do you need a GUI?".

I will give a 10 minute way to create dynamic libraries in NetBeans. In 10 minutes spent you can do much more than with the best GUI ever.

First, what do I mean by dynamic library. I library which can change in time by your own rules. As a sample, you could want to upgrade the jar files without selecting the new jar files according to the new versions. Or, you would like to have your libraries in different folders (one for development, other for testing machine). Or simply, you know somehow where are your libraries, you have some piece of code to get this information, but you don't want to spent you vacation selecting dozens of jars. You imagination is your limit. With this very simple method you can achieve that in minutes.

First you need to create a NetBeans module project. Call it how do you like, is not important. You do that by File -> New Project -> NetBeans Modules -> Module. After Next, you give a name to your module and can choose Standalone Module. After another next you give the base package, a code name and you have it.
First we will create a class which extends ModuleInstall. This class will be called when the module is started up. In order to do this, we have to add an manifest entry like:

OpenIDE-Module-Install: com/my/package/MyModuleInstall.class

This class has a method called restored(). This method is called when the module is restored during startup. Here we will put our code:

public class ModuleHook extends ModuleInstall {

    public void restored() {
        Map<String, List<URL>> map = new HashMap<String, List<URL>>();
        List<URL> classpath = new ArrayList<URL>();
        map.put("classpath", classpath);
        List<URL> javadoc = new ArrayList<URL>();
        map.put("javadoc", javadoc);

        // fill the URL map as you like, with jars, sources and javadocs
        // .....
        // by the way, you can use FileUtil.urlForArchiveOrDir(File file)
        // to easy get an URL from a File
        
        Library library = libraryManager.getDefault().getLibrary(
               "MyLibrary");
        if (library != null) {
            // remove it if is an old version there
            LibraryManager.getDefault().removeLibrary(library);
        }
        
        LibraryManager.getDefault().createLibrary("j2se", "MyLibrary", map);
    }
}

And that is all. One thing though. You need to add dependencies to some Platform Libraries. In the contextual menu of the project action Properties -> Libraries -> Add. If you don't know what dependency you need simply put the class name in filter field and you will find what you search for.

I consider that NetBeans is a tool for programmers. And programmers don't fear coding. That is why this the best tool to configure your environment. Much flexible and better that a GUI.

Hope you like it.

NetBeans Platform: Implement Perforce client - part III

2009-09-29T14:52:00.000-07:00

Switch to P4JAPI, annotate and basic actions

All the Netbeans Plugins which tried to implement the Perforce client uses p4 command line tool. This is somehow difficult, because you have to manage the input and output of a command line. A lot of effort with no benefit. Because the perforce team put on place what is called P4Java, the Perforce Java API. You can find the release notes here (last version) http://www.perforce.com/perforce/doc.091/user/p4javanotes.txt. Download it from here. The main benefits are the fact that you work with objects, don't have to parse things, and to manage external processes. Thought, also, it is faster than its command line brother. Since this is not an NetBeans Platform thing, I will not insist on that too much.

As mentioned in a previous article, the presentation of versioning information is implemented in a class based on VCSAnnotator. In our case, this class is called PerforceAnnotator. There are some aspects which need to be explained. First is the fact that this class is a listener on some specific property change. That is done using the following code:

public class PerforceAnnotator extends VCSAnnotator {
    /**
     * Fired when textual annotations and badges have changed. 
     * The NEW value is Set<File> of files that changed or NULL
     * if all annotaions changed.
     */
    public static final String PROP_ANNOTATIONS_CHANGED = "annotationsChanged";
    private final PropertyChangeSupport support = new PropertyChangeSupport(this);
     public void addPropertyChangeListener(PropertyChangeListener listener) {
        support.addPropertyChangeListener(listener);
    }

    public void removePropertyChangeListener(PropertyChangeListener listener) {
        support.removePropertyChangeListener(listener);
    }

The PerforceAnnotator has two methods related to property change events: addPropertyChangeListener and removePropertyChangeListener. How it works? We define a logical property, named "annotationChanged". Any listener added will be notified if this property have been changed. This code works together with another piece from PerforceVS and another one from FileStatusCache. Practically, through this logical properties and wire of listeners we send messages from a component to another. They remain loosely coupled. As a sample, when the status of a file has been changed (from perforce point of view), the instance of FileStatusCache (which manages these statuses) notify PerforceVS that something on a file has been changed. PerforceVS than will notify the PerforceAnnotator about that change and the annotator will change also the status in UI (labels, colors, versioning info). The property change method is a very important concept. It is used very ofted to put UI things together, so take a closer lok on that, whenever you have some time.

PerforceAnnotator show some UI information about the status of files. The icon from explorer view is modified and the name and color of the file element is modified. These is done with the following code.

    @Override
    public Image annotateIcon(Image oldImage, VCSContext context) {
        FileStatusCache cache = PerforceSystem.getCache();
        int x = 12;
        int y = 0;
        if (cache.containsStatus(context, FileStatus.STATUS_VERSIONED_EDIT)) {
            return ImageUtilities.mergeImages(oldImage, ImageRoot.DECORATION_EDIT, x, y);
        }
        if(cache.containsStatus(context, FileStatus.STATUS_VERSIONED_ADD)) {
            return ImageUtilities.mergeImages(oldImage, ImageRoot.DECORATION_ADD, x, y);
        }
        if(cache.containsStatus(context, FileStatus.STATUS_VERSIONED_UPTODATE)) {
            return super.annotateIcon(oldImage, context);
        }
        return super.annotateIcon(oldImage, context);
    }

    @Override
    public String annotateName(String name, VCSContext ctx) {
        FileStatusCache cache = PerforceSystem.getCache();
        int version;
        List<FileInformation> files;
        files = cache.listFiles(ctx, FileStatus.STATUS_VERSIONED_EDIT);
        if (files.size() > 0) {
            version = files.get(0).getVersion();
            return markName(name, "#0B610B", "#" + version + " [edit]");
        }
        files = cache.listFiles(ctx, FileStatus.STATUS_VERSIONED_ADD);
        if (files.size() > 0) {
            version = files.get(0).getVersion();
            return markName(name, "#084B8A", "#" + version + " [add]");
        }
        files = cache.listFiles(ctx, FileStatus.STATUS_VERSIONED_UPTODATE);
        if (files.size() > 0) {
            version = files.get(0).getVersion();
            return markName(name, null, "#" + version);
        }
        files = cache.listFiles(ctx, FileStatus.STATUS_UNKNOWN);
        if (files.size() > 0) {
            return super.annotateName(name, ctx);
        }
        if (name.equalsIgnoreCase("<default package>")) {
            return "&lt;default package&gt;";
        }
        return super.annotateName(name, ctx);
    }

    private String markName(String name, String color, String label) {
        boolean extra = VersioningSupport.getPreferences().getBoolean(
                VersioningSupport.PREF_BOOLEAN_TEXT_ANNOTATIONS_VISIBLE, false);

        if (color == null) {
            return name + (extra ? label : "");
        }
        return "<font color=\"" + color + "\">" + name + "</font>" +
                (extra ? "  <font color=\"" + color + "\">" + label + "</font>" : "");
    }

How it works? Depending on the status of the file, we modify the actual icon or label of the file from explorer view. To find the status of the file we ask the FileStatusCache, this class manages the FileInformation related to every managed file. The VCSContext represents the selection of files on which we should show information. Note that is possible to have multiple files in a context. In order to keep things simple, I considered that context have only one file and if there are many, I take into consideration only the first one. In time this should be changed. The same scenario happens for labels. On labels we use HTML tags because the view allow that to modify the aspect of a label.

One small tip to know. ImageUtilities class offers some very useful methods in managing images. We can use that class to merge two images, as is the case with PerforceAnnotator (we put a small Perforce icon over the original NetBeans file icon). We can load an image giving only a location in class path and we can transform with easy from an image into an icon and viceversa.

Let's take a look on the results of our work until now.

Another thing which PerfoceAnnotator do is to wire up some actions. It does this by implementing the method getActions. This method receives two parameters as input. The first one is the VCSContext. As noted before, the context gives information about the selected files for which the user wants to show actions. I repeat that is important to be aware that the context can represent more than one file, so behave accordingly. The second parameter is ActionDestination. This is an enum which tells us if the IDE wants the actions to be inserted on the main menu or on the contextual menu. In the sample code below the complexity of building available actions is wrapped into another class, called FileStatusManager. An action is a standard swing action. My actions usually calls the perforce client and do something with that. Since this is not a NetBeans Platform I will not talk about that, as usual, I invite you to take a look on the sources and give at least a feedback (you are welcomed anytime to submit).

    @Override
    public Action[] getActions(VCSContext ctx, ActionDestination destination) {
        List<Action> actions = new ArrayList<Action>();
        FileStatusManager manager = FileStatusManager.getInstance();
        switch (destination) {
            case MainMenu:
                actions.addAll(manager.getAvailableActionsOnMainMenu(ctx));
                break;
            case PopupMenu:
                actions.addAll(manager.getAvailableActionsOnPopup(ctx));
                break;
        }
        return actions.toArray(new Action[actions.size()]);
    }

One more cookie, thought. To create a progress notification which will be displayed on status bar in a dedicated section, you can use ProgressHandle. Like in the sample below taken form FileStatusCache.reloadCacheOnThread.

        final ProgressHandle progress =


                ProgressHandleFactory.createHandle("Perforce refresh..");


        progress.start();


        .....


        progress.finish();

I mention this simple thing because a lot of things in NetBeans are very simple and straightforward to implement or use. That is the meaning of strong API. The simplest form possible, intuitive and elegant. I think NetBeans Platform has a lot of those.

Untill the next time, see changes on http://kenai.com/projects/perforcenb.

NetBeans Platform: Implement Perforce client - part II

2009-09-08T04:23:00.000-07:00

Module preferences for PerforceNB.

Usually options for NetBeans modules are handled via option panel. For that we can use a specialized wizard. You can start the wizard from the contextual menu of the project, where we fire the New - Other - Module Development - Options Panel. In this way we can create primary or secondary panels for options.

This is not our case. That is because for versioning system options, NetBeans has created a panel already. You can find that panel from the main menu by Tools - Options - Miscellaneous - Versioning. Take a look on the dialog box and see what comes next. Our job is to insert another item in the list of versioning systems, handling preferences for Perforce.

We achieve that by extending org.netbeans.spi.options.AdvancedOption. This class represents an advanced interface element for options dialog. We create a new class which extends AdvancedOption.

After that we must configure the layout.xml to inject in the interface this element. The programmatic way is to modify by hand the layout.xml file. This file will look like below:

<filesystem>

    <folder name="VersioningOptionsDialog">

        <file name="PerforceOptions.instance">

            <attr name="instanceClass" stringvalue="org.padreati.perforcenb.ui.PerforceOptions"/>

        </file>

    </folder>

</filesystem>

Another option to generate this content is to find in the IDE the layer GUI editor. Use <this layer in context> representation. Find VersioningOptionsDialog folder. There use context menu to create a new file called PerforceOptions.instance and so on.

Now we injected our UI element in NetBeans IDE. We implement the class to provide appropriate values. I implemented AdvancedOption in class PerforceOptions.


public class PerforceOptions extends AdvancedOption {
    @Override
    public String getDisplayName() {
        return NbBundle.getMessage(PerforceVS.class, "CTL_Perforce_DisplayName");
    }

    @Override
    public String getTooltip() {
        return NbBundle.getMessage(PerforceVS.class, "CTL_Perforce_OptionsTooltip");
    }

    @Override
    public OptionsPanelController create() {
        return new PerforceOptionsPanelController();
    }
}

The listing is clear, we provide a display name and a tooltip for the UI element. I used resources for that. The main method here is create() which returns an instance of PerforceOptionsPanelController.An OptionPanelController is the controller behind UI for managing options (MVC sounds familiar? that's one reason why I love NetBeans and Swing). The controller handles operations of managing data. Here is the listing:

public class PerforceOptionsPanelController extends OptionsPanelController {
    private PerforceOptionsPanel panel;

    public PerforceOptionsPanelController() {
        panel = new PerforceOptionsPanel();
    }

    @Override
    public void update() {
        PerforceModuleConfig config = PerforceModuleConfig.getInstance();
        config.reload();
        panel.setPath(config.getP4Path());
        panel.setDefaultPort(config.getP4DefaultPort());
        panel.setDefaultWorkspace(config.getP4DefaultWorkspace());
    }

    @Override
    public void applyChanges() {
        PerforceModuleConfig config = PerforceModuleConfig.getInstance();
        config.setP4Path(panel.getPath());
        config.setP4DefaultPort(panel.getDefaultPort());
        config.setP4DefaultWorkspace(panel.getDefaultWorkspace());
        config.store();
    }

    @Override
    public void cancel() {
        PerforceModuleConfig.getInstance().reload();
    }

    @Override
    public boolean isValid() {
        return true;
    }

    @Override
    public boolean isChanged() {
        return panel.isDirty();
    }

    @Override
    public JComponent getComponent(Lookup masterLookup) {
        return panel;
    }

    @Override
    public HelpCtx getHelpCtx() {
        return new HelpCtx(PerforceOptionsPanel.class);
    }

    @Override
    public void addPropertyChangeListener(PropertyChangeListener l) {
    }

    @Override
    public void removePropertyChangeListener(PropertyChangeListener l) {
    }

}

There are only some methods which are really relevant. The update method is called when IDE loads configuration data from storage, I update the interface at that moment. The applyChanges is called when a save action is fired from interface. Use isChanged to tell IDE if the configuration data was updated in UI. The UI is specified in getComponent method. This method returns an instance of PerforceOptionsPanel, a class which extends JPanel.

This is the interface. Here is how it looks:

For managing the preferences of the module I created a class called PerforceModuleConfig. This is a singleton which calls NbPreferences to persist it's properties. This class I will use in our module to see which are the options for PerforceNB module. Here is a listing:

public final class PerforceModuleConfig {
    private static PerforceModuleConfig instance;

    private final static String P4_PATH_KEY = "P4_PATH_KEY";
    private final static String P4_DEFAULT_PORT_KEY = "P4_DEFAULT_PORT_KEY";
    private final static String P4_DEFAULT_WORKSPACE_KEY = "P4_DEFAULT_WORKSPACE_KEY";

    private String p4Path;
    private String p4DefaultPort;
    private String p4DefaultWorkspace;

    private PerforceModuleConfig() {
    }

    public static PerforceModuleConfig getInstance() {
        if(instance==null) {
            instance = new PerforceModuleConfig();
        }
        return instance;
    }

    public String getP4Path() {
        return p4Path;
    }

    public void setP4Path(String p4Path) {
        this.p4Path = p4Path;
    }

    public String getP4DefaultPort() {
        return p4DefaultPort;
    }

    public void setP4DefaultPort(String p4DefaultPort) {
        this.p4DefaultPort = p4DefaultPort;
    }

    public String getP4DefaultWorkspace() {
        return p4DefaultWorkspace;
    }

    public void setP4DefaultWorkspace(String p4DefaultWorkspace) {
        this.p4DefaultWorkspace = p4DefaultWorkspace;
    }

    public void reload() {
        Preferences pref = NbPreferences.forModule(PerforceModuleConfig.class);
        String p4PathDefault = "p4";
        if(System.getProperty("os.name").startsWith("Windows")) {
            p4PathDefault = "p4.exe";
        }
        setP4Path(pref.get(P4_PATH_KEY, p4PathDefault));
        setP4DefaultPort(pref.get(P4_DEFAULT_PORT_KEY, ""));
        setP4DefaultWorkspace(pref.get(P4_DEFAULT_WORKSPACE_KEY, ""));
    }

    public void store() {
        Preferences pref = NbPreferences.forModule(PerforceModuleConfig.class);
        pref.put(P4_PATH_KEY, getP4Path());
        pref.put(P4_DEFAULT_PORT_KEY, getP4DefaultPort());
        pref.put(P4_DEFAULT_WORKSPACE_KEY, getP4DefaultWorkspace());
    }
}

The content is obvious. Only notice that I have used NbPreferences, a utility class from NetBeans Platform for persisting preferences. Very useful one. Here is the result of my work from this episode.

As usual, you can see the whole project and code from the kenai project page at http://kenai.com/projects/perforcenb. See you on the next episode.

NetBeans Platform: Implement Perforce client - part I

2009-09-06T17:30:00.000-07:00

NetBeans and NetBeans Platform were always the tools for the heart. Unfortunately, my usual job duties did not included enough time spent with them. So, I tool my chanses to spent some nights on these. Since I have to use Perforce versioning system and because NetBeans has not (yet!) a client for this system, I decided to implement such a client. Hope I can give something back to the community in this way, a humble little piece compared to the things I received. You will see project details here http://kenai.com/projects/perforcenb.

So, a versioning control system. If you want to know more about Perforce, you can go to their site www.perforce.com. It should be enought to say that I know at least two very big companies which use it as a main VCS.

NetBeans Platform gives us an API which can be used to integrate a client for a versioning system into the IDE. A nice side effect of this is the fact that all the versioning control system clients will behave in a similar way. We will implement our Perforce client as a NetBeans module. In this way we can use it on our daily basis usual tasks.

First thing to create is a NetBeans module project. We can do that by using New -> Project from NetBeans IDE. (I use 6.7.1, thought you should use a recent version too). We chose then NetBeans Modules -> Module for the project type and hit Next button.

In the next dialog box we insert information about the project. Like project name, location and so. You can see the data I enetered from the image. Afer that, hit the Next button again.

In the next dialog box we insert some information useful for code generation. Base package can be configured here, title of the plugin and layer. The will be important in the next parts of this story. For the moment just be sure you select it. To generate the code for the project you should use action Finish button.

So, we have now a module project which does nothing for the moment. We want to implement a versioning system client in it, so the starting point should be extending the VersioningSystem class. But, to be able to use that class, we must do another preparation step. Importing the NetBeans modules which we will base our module on. For the beginning we will add two dependencies at the project. For that, action the contextual menu of the project. From there, action Properties -> Libraries. In the dialog box fire Add button which will gives us a search screen.

The interesting thing in this screen is that you can use it in two ways. First you know already which module you should import, so you can roll over the Module list and select modules you like to use it. The second way is to use search Filter. The nice thing here is that you can search for an exposed class. So, if you don't know which module to import in order to use a specific class or interface, you filter module by that class or interface and you will have listed all the modules which offer that name. Nice trick when you are lost somehow.

So, we need to add dependencies to the following modules: Versioning and Utiities API. The last because we use an utility class for getting the resources (look for NbBundle to see what I mean).

The next stept is to let the NetBeans IDE "know" that I just implemented a new versioning client for him.We do this by extending org.netbeans.modules.versioning.spi.VersioningSystem in a service provider interface way. So we create a derived class, PerforceVS which extends VersioningSystem. We create META-INF folder into the source root. In META-INF we create a folder called services. In META-INF/services we create an empty text file. That file will be called org.netbeans.modules.versioning.spi.VersioningSystem and will have one line only: org.padreati.perforcenb.PerforceVS. This is the name of the class which extends VersioningSystem. For a broader view of Service Provider Interface you can take a look here.

package org.padreati.perforcenb;

import java.io.File;
import org.netbeans.modules.versioning.spi.VCSAnnotator;
import org.netbeans.modules.versioning.spi.VersioningSystem;
import org.openide.util.NbBundle;
import org.padreati.perforcenb.wrapper.PerforceSystem;

/**
 *
 * @author padreati
 */
public class PerforceVS extends VersioningSystem {

    public PerforceVS() {
        putProperty(PROP_DISPLAY_NAME, NbBundle.getMessage(
            PerforceVS.class, "CTL_Perforce_DisplayName")); // NOI18N
        putProperty(PROP_MENU_LABEL, NbBundle.getMessage(
            PerforceVS.class, "CTL_Perforce_MainMenu")); // NOI18N
    }

    @Override
    public File getTopmostManagedAncestor(File file) {
        // TODO for the moment all will be considered under
        // Perforce just for testing
        return new File("/");
    }

    @Override
    public VCSAnnotator getVCSAnnotator() {
        return PerforceSystem.getSystem().getAnnotator();
    }
}

This class is in the very basic form. We do the following:

In constructor we set values for menu labels. In order to work I have inserted entries into resource (properties) files for CTL_Perforce_DisplayName and CTL_Perforce_MainMenu.
I implemented getVCSAnnotator just to return the instance of annotator we will use (details a little bit latter).
implement getTopmostManagedAncestor. If this method returns a value, it means that the file/folder receicved as parameter is managed by our versioning system. If not, we return null.

One important aspect is the design of versioning system in NetBeans. It is considered that one resource from disk (either file or folder) can be in two states only. Either is managed by one versioning system (only one versioning system can own the resource in the same time) or is not managed at all. The versioning API consider also that if a folder is managed by a versioning system, all of the folders and files should be managed by that version control. So, to find for a folder if it is managed by a versioning control, we should tell to the versioning API that the specified files resides under a managed folder. We do that by implementing getTopmostManagedAncestor. This method should return the topmost managed folder where resides the file received as parameter.

In my sample I simply return root folder. Why, would you ask. Just for the testing purposes. Returning the root folder of the file system (this is similar to C:\ folder on Windows) I specify that all files are managed by Perforce. Obviously this is not true. We do it for now just to see where we go.

Also, I created a singleton class to hold all the references of the Perforce versioning system. For the moment we hold only annotator instance. But what is an annotator?

package org.padreati.perforcenb.impl;
import java.awt.Image;
import java.util.ArrayList;
import java.util.List;
import javax.swing.Action;
import org.netbeans.modules.versioning.spi.VCSAnnotator;
import org.netbeans.modules.versioning.spi.VCSContext;
/**
 *
 * @author padreati
 */
public class PerforceAnnotator extends VCSAnnotator {
    @Override
    public Image annotateIcon(Image arg0, VCSContext arg1) {
        return super.annotateIcon(arg0, arg1);
    }
    @Override
    public String annotateName(String name, VCSContext ctx) {
        return name + " [PERFORCE]";
    }
    @Override
    public Action[] getActions(VCSContext ctx, ActionDestination destination) {
        // TODO complete actions, for the moment only an empty
        // menu as a sample
        List actions = new ArrayList();
        if (destination == VCSAnnotator.ActionDestination.MainMenu) {
            actions.add(null);
        }
        return actions.toArray(new Action[actions.size()]);
    }
}

An VCS Annotator is the class which implements the decoration in IDE of the code elements controlled by a versioning system. In our case, all the files managed by Perforce should be specified in a way that is visible into interface. Just because we signaled that all files are managed by Perforce (we know that is not true), all the files will be decorated by this annotator.

annotateName will decorate the name of the resource, and annotateIcon will decorate the icon. These methods receives VSContext. This class encapsulates a selection of objects, so we can multiple annotate the resources. In our sample implementation we only append the [PERFORCE] string at the name of resource.

The method getActions deserves also a lot of attention. Bu on that in another next chapter. For the moment just remember that this is a way to provide actions to main or contextual menus. For the moment we give an empty menu.

Until the next episode, just give it a try. Run the module. It will open the IDE with our module enabled. Open a project in IDE and watch for names, You will the the appended text for all the resources. Like it would be managed by Perforce.

On the next things in the following episode. Follow it! NetBeans Platform deserves it!

Powered by Service Provider Interface

2009-08-31T01:39:00.000-07:00

In my previous post I used an annotation processor to enrich the usage of annotations. I stated that to configure an annotation processor you should use a compiler time parameter. In Java 6 you can do more. You have Service Provider Interface API which lets you configure the same processor in a more elegant manner. But what is SPI (Service Provider Interface)?

Brief on SPI

The official java doc is here. A service is an interface or abstract class which defines a contract for a specific functionality. A service provider is an implementation of that service. Java 6 provides a loader for services based on a provider-configuration file. Just as simple.

Steps to put on jobs

You define an interface or use an existing one which defines the contract of your service.
You define and implement one or more implementing classes. This classes should have an empty constructor, that is the only requirement.
You create META-INF/services folder in you jar archive. In that folder you create a file named with the canonical class name of the interface. (as a sample: your.packages.MyInterface). That is the provider-configuration file.
In the new created file you insert the canonical names of the implementing classes. These classes are the service providers. If you have more implementations, you put them on separate lines. The syntax of this file is the syntax of properties file (put comments prefixed with # for clarity).

That's all. The runtime will parse the provider-configuration files and provides service loaders for these services, which you can use.

What are the usages?

Insert providers for existent services

JDK provides some usefull SPIs already, which you can use them. Going back to the beggining of my article, the java annotation processor is such a SPI service. So, in place of putting "-processor org.aap.processor.AAPProcessor" as a compiler option, we can skip that. Instead, we create META-INF/services folder. In that folder we create a file called "javax.annotation.processing.Processor". In that provider-configuration file we put "org.aap.processor.AAPProcessor". Now it works. For the article go here. Simply by providing this, the runtime at the moment of loading the jar library, will parse providers and use them. Nice and clean.

Obviously we can provide implementation services for other SPIs as well. I mention here just a few like: LoginModule for authentication, sound sample API or better here, java text spi API (by the way, nice feature), and others.

Usage of service providers in an Observer Pattern manner
Implement your own interface for observable (eventually by extending java.util.Observer). Don't need to handle yourself contributions, service loader is here for that. And can handle contributions from the whole class path.

Usage of service providers in a Factory pattern manner
Implement an interface with a getter to discriminate between implementations. On execution time, use service loader to iterate through implementations and find which provider to use.

Conclusion
That's only a starting point for service provider. I found a nice feature brought by Java 6. In fact not only nice, but almost fabulous. An option to extending platform.

Annotation checking at compile time with Java Annotation Processor

2009-08-27T04:48:00.000-07:00

Some weeks ago I implemented a feature which collects some information on runtime from some classes. I preferred using annotations against interfaces for flexibility. Practically the task could be described like: decorate with meta information some classes, parse annotations and get information to be stored.

As a sample a had a annotation like:

@Retention( RetentionPolicy.RUNTIME )
@Target( ElementType.METHOD )
public @interface Description 
{
}

As you can see, annotation syntax allows me to specify to store for runtime the annotation and that the annotation to be used for methods. That was frustrating for my job, because I would expect to have more flexibility on that. In my specific case, I would like to allow the meta decoration only on methods which returns strings.

I was thinking to document the annotation and specify that if the annotation is not on a method which returns string, the annotation will be ignored. Said and done. But there is a better and fairly simple method to do the task. This is Java Annotation Processor. This feature is documented in JSR 269: Pluggable Annotation Processing API.

The code I wrote is more complex, but for this post I wrote a sample to show the usage of this API.

The JSR 269 states that you can implement a plug-in for the compiler which can handle the annotations. This plug-in can be given as parameter at compile time, so your code will be called when one of your annotation appears in source code.

First step is to create a annotation processor. This can be done by implementing interface javax.annotation.processing.Processor or by extending the class AbstractProcessor from the same package. I used the second way being much easier.

@SupportedAnnotationTypes(value = {"mypackage.LiveDescription"})
@SupportedSourceVersion(SourceVersion.RELEASE_5)
public class AAPProcessor extends AbstractProcessor {

    @Override
    public boolean process(Set annotations, RoundEnvironment roundEnv) 
    {
        for (TypeElement typeElement : annotations) 
        {
            Set elements = roundEnv.getElementsAnnotatedWith(typeElement);
            for (Element element : elements) 
            {
                // we have only one annotation on methods
                processElement((ExecutableElement) element);
            }
        }
        return true;
    }

    private void processElement(ExecutableElement element) 
    {
        String elementTypeStr = element.getReturnType().toString();
        if (!"java.lang.String".equals(elementTypeStr)) 
        {
            processingEnv.getMessager().printMessage(
                Kind.ERROR, 
                "Method does not return a String", 
                element);
        }
    }
}

Some things need to be explained:

SupportedAnnotationTypes specify one specific annotation. You can use * and package names also.
SupportedSourceVersion specify the Java version. That's OK because we did not had annotations on prior versions of Java language.
the process method iterates though annotations and for every one give the code elements annotated with (in my case only methods); after that calls processElement for any annotated element.
processElement verify get the returned type of the method; if the returned type is not java.lang.String that use the message service to signal a syntax error

That's all about processor. As you can see, is quite obvious and simple to implement that. Of course, your implementation will be more flexible (not harcoded) and complicated.

The final step is to give that to the compiler. I used NetBeans (my beloved IDE) for that, but is simple enough in any IDE. You have only to give the compiler a hint about your plug-in. For that you have to:

put on compiler options "-processor org.aap.processor.AAPProcessor", aka the -processor option with the fully qualified name of your class. In NetBeans you go on Project Properties->Build->Compiling and put that in "Addidtional Compiler Options" text box.
put the class on compiler class path; as I created a jar file containing my annotation processor, you have only to add that to the compiler path. In NetBeans is also trivial. You have to go to Project Properties->Libraries->Compile and add your jar there

That's all. The tested code was:

public class AnnotatedTest {

    @Description
    public String getName() {
        return "String";
    }

    @Description
    public int getAge() {
        return 10;
    }
}

I bet that the second method will fail at compile time. Do you?

Concerned about JBoss Seam? Don't worry, it will be better

2009-08-20T14:30:00.000-07:00

I am a big fun of Java EE. Don't ask me why, if it's not obvious I will explain in another post. Even of the fact that I like Java EE that much, that does not mean I consider it perfect. In fact is not perfect at all.
There is place for a lot of improvements, a lot of them are on the road to be included in the next versions of standards, others not yet. So, working with Java EE alone, sometimes could be a pain. That's why I put in place Seam Framework. Seam Framework is a perfect match for Java EE on server side. It gives you a lot of things which the standard has not. You have Seam components and Seam contexts, which is a big progress. I don't mention the whole features of Seam here, even those have a great weight. If you want to see details on that you can see on http://seamframework.org/. I worked with Seam on three medium/big applications and had a lot of reasons to be happy.
But in these days I had some black thoughts on that. I was wondering what will happen with Seam. You could honestly ask yourself why, if everything was so fine? Just because of WebBeans, the new standard. Here is the story.
O lot of good people of JBoss and Seam were working on the new proposals from JSR. They provided a lot of work and results for EJB3 and JPA. Now they are ready to publish the new JSR-299 Java Context and Dependency Injection ( aka. WebBeans ). That is a great JSR and I am waiting to work with. The WebBeans comes to provide a standard for the main lack of Java EE applications. The poor integration between EJB components and JSF components ( aka. managed beans ). That was the core job of Seam Framework. Now WebBeans put these two layers together, by allowing EJB components to act as JSF components. We will have more multiuser secured acces and transactions on the components beneath JSF, and that's really cool. In fact WebBeans have knowledge from Seam Framework, Struts Shale, Oracle ADF and Google Guice inside.
So what will happen with Seam in this context? The JBoss will renounce at Seam in favor of WebBeans? I was thinking on that until I read a very clear statement from JBoss. You can find it here. It explains how Seam Framework relates with WebBeans.
WebBeans implementation form JBoss will be the core on which Seam will be based. All the good things from Seam related to components and contexts will be based on that and that. Seam Framework continues, it will be alive. And most probably, it will give you in the future also, a lot of reasons to stay sticked your business and use EJB in a painless way.
The good thing here is that we could use WebBeans implementations from another providers together with Seam Framework, it's a standard, isn't it?
If you didn't give a try to Seam Framework, you should start to do it right now. EJB and Seam is a winner bet. Thanks to all guys who works on that.

Slow death by technical debt

2009-08-17T02:07:00.002-07:00

Did you here the words "can't have time now, implement that quickly" or "we need a.s.a.p. that for a presentation"? If you did that, you should know that you are in the middle of the battle. Invisible bullets go near your ears and you and your team are living on the edge. That's not bad in itself, but can became as bad as can be soon, if you can't handle. I'll explain why.

When you have to implement something, either is a new feature or a solution for a bug, you face one common problem. You can take main scenario, fix what it should do and go further. That's called quick and dirt. That is because the code resulted from that is really dirt. The second and best approach is to face to problem for today and tomorrow. Think hard and implement the optimum solution, use a good design. As I said, there are times when quick and dirt saves you from something. Is like in management, the difference between important and urgent. The urgent sometimes is more useful than important. But this has a trade off.

Ward Cunningham invented a metaphor for that, which fits well in understanding the implications. This metaphor is called Technical Debt. Technical debt is similar to financial debt. When your business needs something urgent and you don't have enough money, you borrow some from the bank and do your job. After that you have to pay interests and principal to return the debt. Same in software, but here you deal with quality in place of money. Sometimes to get a good deal, to touch a milestone or to give something with few resources you can accept quick and dirty. After the deal is done you can decide if you live with that or you refactor it, using a good design this time.But you must have always in mind the working on poor code means paying more interests. And if you pay too more interests your deals could became a bad one. So, for your health, refactor as soon as possible. That is called paying the principal and eliminate the technical debt.

Quality in software means resources. You have to spent more resources to have better quality. As Martin Fowler said here, technical debts hurts performance. And the performance is almost unmeasurable in software. You have to manage a proper balance in your technical debts. If you hear the magical words which leads to quick and dirty, open your ears. If you don't hear soon about refactoring tasks, you should put your questions. If these things come again and again then you could go into a swamp with your projects. Everything begins with parts of code which is considered ugly and unmanageable. These become to stink. The project can go to the slowly path of death by technical debt suffocation.

How to handle technical debts?

There no standardized solutions. That's because is hard to measure and because managers like Excel too much. They like to see numbers, that give them the sensation of control. But numbers are not so bad. They really don't show the things how they are (don't let the managers know that!), but the process of getting these numbers enforce some processes which could help in handling technical debts.

A good individual exercise which I practice is using of IDE meta comments like TODO, FIXME or somebody else from the family. When I begun to implement something which is complex somehow I use TODO comments. I use them as bookmarks to remind me that I should complete something. These marks will be removed until I submit. So they exists only to remind to my poor memory that I did not finished the job. Before submit I check to see if everything is like I want by verifying and removing these comments.I call them Transient Technical Debts. Transient because these technical debts are not persisted into version control system.

A similar approach could be followed for the persistent technical debts or the normal technical debts. You can you a marker like FIXME. Maybe a FIXME and a date. Better is to have also a system for controlling them. A good approach is to put an effort in the next iteration of your software and eliminate them. So all the technical debts you accumulated on the current iteration will be paid in the next one. Just to keep things in control.

Another approach is to keep that ledger in the bug and task tracking management system. You can have some attributes on tasks and bugs which tells us if the job was done quick and dirty or not. If we have to spent more effort to put a good implementation in place of a poor one. A mixing solution is to have code comments linked to that kind of a system.

These kinds of ledgers are good because they can give you numbers also. It forces you to have a health quality of the software and keeps you manages happy. They have the input for nice charts and reasons for raise your salary. Anyway, keep your ears tuned and don't go int the technical debts swamp.

NetBeans 6.7.1 with JavaFX

2009-08-17T02:07:00.001-07:00

NetBeans soon after 6.7 had launched another version of its IDE. That's 6.7.1 with JavaFX. As its name states, this version is an update version of the previous one containing few adiitional things:

Support for JavaFX 1.2
Update of GlassFish v3 Prelude
Important bux fixes requested by users

You should give it a try, even if you don't use actually JavaFX. Bring it from here and have fun.

JarSearch.com

2009-08-17T02:06:00.004-07:00

JarSearch.com is the tool of choice for software developers and software engineers searching for the jar file of a missing class. This is the first sentence which tells everything you need to know about that tool.

During time spent with Java programming there are a lot of cases when a class or more are missing from the path. The worst situation is when you don't even know where the class is defined. I mean which jar contains the class definition.

This site helps you with identifing that jars. It gives you all possible jars (most of the possible solutions, or course). It gives you also the jar version.

I found useful sometimes, so hope you will have too. Enjoy it!

Scannotation - java annotation scanner

2009-08-17T02:06:00.003-07:00

Bill Burke a JBoss old timer, Red Hatter, and successful open source entrepreneur, as he calls himself here is one of the good people I read. He created in the past a very interesting and useful small tool. That tool is called Scannotation. You can find more on that from it's own place on web in the big house of sourceforge at this address http://scannotation.sourceforge.net/. The idea at least, if not the final code, which started Scannotation was the fact that Bill worked on JBoss EJB container and needed to know more about the annotated code.

There are two often seen scenarios on annotation usage. You can have classes or instances loaded by class loaders and you want to know which annotations provides these classes. That's the first scenario. The second one is when you want to know annotations used by classes before the class loader loads the definition of classes. Scannotation give you the second scenario.

You can have jars on classpath or even the bits of a class from a stream and you can use Scannotation to load annotations. You can also find annotations from a war type archive (Java EE web application module). The trick is that you don't need to load and spent a lot of processing time and memory to load classes just to know what annotations have. Scannotation parse the bits from the class definition and gives you annotations.

After you know what to parse you can parse and store annotation usages into a AnnotationDB object. That is not a real database. It contains only two maps. The first one gives you each class which have annotations and for each one the used ones. The second map gives you all annotations, and for each one the classes which uses them. You refine the class search by adding ignored packages. There are already some ignored packages by default, also. You can refine the search by setting to collect only some specific annotation place like annotations on classes, methods, parameters or fields.

The usage is really simple, and for that I will give you an excerpt from their own tests:

          URL url = ClasspathUrlFinder.findClassBase(TestSmoke.class);
          AnnotationDB db = new AnnotationDB();
          db.scanArchives(url);
    
          Map<String, Set<String>> annotationIndex = db.getAnnotationIndex();
          Set<String> simpleClasses = annotationIndex.get(
                       SimpleAnnotation.class.getName());
          Assert.assertTrue(simpleClasses.contains(
                       ClassWithFieldAnnotation.class.getName()));
        Assert.assertTrue(simpleClasses.contains(
                       InterfaceWithParameterAnnotations.class.getName()));
    
          Set<String> simpleAnnotations = db.getClassIndex().get(
                       ClassWithFieldAnnotation.class.getName());
          Assert.assertTrue(simpleAnnotations.contains(
                       SimpleAnnotation.class.getName()));
          simpleAnnotations = db.getClassIndex().get(
                       InterfaceWithParameterAnnotations.class.getName());
          Assert.assertTrue(simpleAnnotations.contains(
                       SimpleAnnotation.class.getName()));

As you can see you feed the AnnoationDB instances with URLs. These URLs can be obtained using Scannotation tools. After that you use the two provided indexes.

Scannotation is small, fast and if you like, you can modify for you needs it it does not fit well. It's Open Source licensed with Apache License v2.0.

Java EE is just Java

2009-08-17T02:06:00.001-07:00

I write Java EE applications for about some years. During those years I learn some things and give some cents to others. But most productive things which were happen were the discussions on that topic. When you talk with somebody on a subject where both have some knowledge, you find usually nice points of view. Also I noticed that in the same the same time, the same problems are bypassed.

A lot of discussions on this subject happens having in mind that Java Enterprise applications are applications made from distributed components. That's true. Java Enterprise applications some standard services provided by EJB and web container. That is also true. Java Enterprise are build only from EJB layers ( entity beans - now JPA, session beans, message beans, etc) and presentation layers. That is not true. There is something missing here. Java Enterprise applications are still Java applications. What is the meaning of this note? The fact that Java Enterprise applications are still Java applications is an aspect which is often forgotten or simply not took into consideration. When you build a Java Enterprise application you don't loose the possibility to do the same things as you would do in a normal Java application.

When you debug a Java Enterprise application, as a matter of fact you debug a Java application. The debugging feature is something which happen on the virtual machine and class loader level (more on that on a future article). You debug in the same way a Java EE application as you would do with a desktop application, even local or remote, even through shared memory or TCP port.

You can have static or singletons or factories as would you have with normal Java application. I remember a discussion on a forum when somebody put the following problem. Every client is represented by a stateful session bean. How you would implement a communication between those clients? A saw a lot of responses, more that 15 on that topic. All of them stating more or less that you cannot avoid to use persistence layer to store information to be used by different clients. Nobody thought at a simple solution. A singleton which would hold information send by every client and requested by others (was a IM problem). Don't say that the singleton is the best solution. I state only that developing Java EE solutions sometime makes you think that the only things that you can do are EJB components. That's not true. You can however do everything you want.

The only differences between a Java application and a Java Enterprise are:

The Java Enterprise application is loaded and started by a special piece of code called container (EJB/web), the normal Java application does not need to be started by something else, could have it's own main entry point
Java Enterprise applications are packaged in a specific way to achieve the third difference, while normal Java applications don't have this constraint
Java Enterprise applications can use services provided by EJB and web container, while normal Java applications can't (only if you you an embedded environment)

An that's all. In every other aspect these applications are the same: Java applications.

NetBeans 6.7 was launched, what brings with him?

2009-08-17T02:00:00.000-07:00

: NetBeans 6.7

On June 2009 Netbeans released the final version of 6.7. You can find more about here, on their release page. You can download it here.
From the beginning I must say that I am a big fun of NetBeans. I used since it was named Forte for Java version 2. I appreciate also Eclipse, but don't start here a flame on why I consider Netbeans superior.
From the release page we can see major topics on the improvements of new features brought to us by this version. You can read yourself about them. Here is my only humble opinion on this release.
Overview. The first impression is that is faster than its predecessors. The difference is visible in usage. Also, they added a feature to enable/disable features with you don't work.
Other languages than Java. Since I don't work too much with either of them I can't provide a full coverage. Still I am happy that I can have in the same IDE some tools for managing this kind of projects. That's cool. I tried PHP support, which I found quite good. Comparing with dedicated tools on that, it manages good. I found it fine for may needs. All that languages were supported before. Thought new valuable features were added for all of them. I would call here the sql editing and PHPUnit in php scripts, remote debugging for Ruby, code complettion on Groovy, profiling and QT libraries support for C/C++. Just to name few of them which are really consistent.
GlassFish. Nice that v3 is supported now. You have code completion, there is also a nice plug-in called GlassFish v3 enabler, quite usefull. You have also v2 version support.
Maven. That's really a very good thing. Maven support is much better now. You have a viewer for dependency graphs, you can configure a lot of your settings through UI. Also, you have archetypes for Java EE projects. The most appealing thing on that is that you can easily use your NetBeans project in another IDE. Practically nothing need to be done to do that. That's impressive. For the ones who want to know more on Maven they should take a look here.
Kenai. The most appealing to me. Kenai is a community similar to sourceforge, I think. But the best thing is that is fully integrated with NetBeans. For start up project is increddible. You have almost everything you can wish: bug tracking, wiki, dedicated place for a site, IM chats, etc. Take a loot at kenai.com. It worths the effort.
Conclusion. This release means "get into community" to my. Kenai is very apealing. In the same time they did not lost focus on continuous improvements. I believe everybody can found a new good reason to use NetBeans.
PS: for Eclipse developers now there's a button called "Synchronize editor with views" ;)

Interface vs Annotations

2009-08-17T01:59:00.000-07:00

When I think about OOP languages, my 2 cents goes into choosing a good contract between the components of your code. I never liked "smart" solutions which tries to steal a little time from here, a little from there and so on. Don't say that there are no good solutions of that type. When you accommodate a generic solution to a specific problem, you might be find that your code is much better. But, to be in that position, you have to have first the best design possible. That gives good solutions in every day practice. And a good OOP design implies healthy contracts between components.

Interfaces apart from classes can define a contract without implementation. Interfaces exists only as pure contracts. And interfaces are firm contracts. If a class implements an interface you can be sure that it will respond to you on the contract terms. Of course, nobody saves you from a bad implementation behind, we should live with that possibility.

Interfaces solves somehow the multiple inheritance problem. Can't agree on that

When we think a contract we have in mind classes which consume services stated by interface and other classes, behind interface, who provide the service. In this way interface acts as an indirection between two classes. You can change always the consumer or the provider of that service, things will go on. There was said that interfaces solves somehow the multiple inheritance problem. Can't agree on that. Interfaces does not provides behavior. The classes which implements multiple interfaces provides the behavior. Still, the implementation classes can't be considered as multiroot inherited. The main difference is that the class which implements multiple interfaces doesn't inherit behavior. And that is the main purpose of multiple inheritance.

Multiple inheritance is a bit clumsy and error prone

I always considered multiple inheritance as a bit clumsy and error prone. When a class inherits two behaviors we live on the edge. If the behaviors are small than there is a possibility to handle things in a logical way. If the behaviors are rich in features, that we are already doomed. That is the worst form of dependency. But even if we are in the best situation possible that an be on short term only. In time things can roll on in a bad way. Considering that the maintenance of the code is the biggest stage of a software component, there will be usually a lot of occasions or opportunities to "improve" and "enrich" the behavior of a component. If a class inherits multiple behavior, these kind of improvements is a curse.

Thanks to James Gosling and others that they don't allowed that in Java. But there are problems which still need to be solved.

Interfaces define how a component should look to be albe to be used by others

Interfaces can define the form of a class. That's why they are called interfaces, right? The interface defines how a component should look to be albe to be used by others. We can have marker interfaces or interfaces with content. Our clases can be less or more polluted by methods implemented from many interfaces. For that we allways have the addapter solution. When we have a class which needs to address many targets we always can split the class in many pieces. The main piece will retain the original goal of the class. The other classes will adapt the main class to othe target, of course, by providing appropriate interface implementations. That address well the mltiple inheritance gap. But can be better, and here comes annotations.

Annotations don't enforce types, don't enforce method signatures or exceptions, like interface does

Annotations are like interfaces, but there are suble differences.Interfaces defines a contract on a whole class. Annotations defines contracts for a class, method, field and others. Like interfaces annotations does not provide behavior. Still, the interfaces defines the form of a possible behavior in a complete way. Annotations don't imply these kind of restrictions. The consumer of annotations will have to handle evenrithing in a more generic manner. Annotations don't enforce types, don't enforce method signatures or exceptions, like interface does. That's way provider classes should alter their code to include the contract of it's implemented interfaces. Annotations don't pollute business code. Don't pollute contract of a class. They just decorate the class.

Annotations can be considered more like a part of the consumer which relies on the provider

Let's take the simplest case for the moment. The marker interfaces. A marker interface is an interface which don't have a body. The are used only to "mark" a component. Just to know at runtime that a class "is a" kind of something. You can't use a marker interface to call methods. A classic example of marker interface is java.io.Serializable. When a class implements Serializable, we know that this class is allowed to be persisted. The interface is only a semantic to serialization. The same effect could be achieved using an annotation on class level. We know that on serialization problem, because of the fact that annotations were not invented at that time. Considering that, the interface solution is a normal solution. Still, if we had to design serialization now, when we have all, what should we choose? I would still choose interface. Both annotations and interfaces are ment to adapt a class to a specific usage. Thought, the interfaces are more a part of a class, more dependent to a class than annotations. Annotations can be considered more like a part of the consumer which relies on the provider. That's why they are more dependent of consumer class than interfaces. If on marker interface teh case is not very clear, we go further.

The only discriminator to choose interface or annotations is the degree of business cognation or similarity

When we want that a consumer class to use another one we usually need that the provider class to tell somethings about that. We can do that using an interface to be implemented by provider class or by using annotations. When we provide information to the consumer we have to fight against code pollution. Even if the provided information is in small or big quantity the problem is still there. The only discriminator to choose interface or annotations is the degree of business cognation or similarity. If we want our class to provide a functionality closer to its bussiness purpose, the most appropriate is interface. If we want our class to be used in a completely different way, apart from it's original scope we should use annotations. Finally, if both ways conduct to a lot of work to adapt, we are probably on a wrong way. We should give a call to adapter or it's cousins to help us because in most of the cases our problem can't be handled by our class. We take a look on two examples for clarifying purpose.

We have a BusinessProcess class which handles information about a process of our business. This class is a java bean, so all properties have setters and getters. Nice simple class. This class provides some methods to run a process, to stop it while is runnings and to collect output data as results.

We have to implement a GUI interface which shows us a log with running events, when tasks have started or stopped. A simple GUI list and that's all. We decide that the model behind the GUI to be a class which handle running business execution events. Because announcing when a process has started or stopped fits very well with our class, we can define an interface for Observer pattern. That interface can have as a sample onStart and onStop methods, with process name as a parameter. So our GUI model will implement our ProcessNotifierListener interface. Our BusinessProcess class will have methods to add or remove listeners of that type, and will call them when any event appeared.

Our classes should not be aware of the problems which don't relates to it's business

Second task is to provide a way to specify the level of logging information for each type of process. The purpose is to show full logs for processes related to security transactions. The other type of processes will have only regular logs saved. We can do that by enforcing and interface with a method. But more appropriate is to use a custom annotation with a property defined. Like @LogLevel(LogLevel.FULL). At runtime we can read the annotation and action appropriate. Why is better to use annotations in this case? Because the logging activity is not even a secondary business purpose of our class. Our classes should not be aware of the problems which don't relates to it's business.

The discussion is never ending. For sure there are not rule appliable everywhere. And you always should reevaluate the case on using interface or annotations. That's whay good programmers are valuable. Thought, at least some of the questions, if not answers, will raise in your mind after reading that. Happy choosing!

How to debug Java EE on JBossAS

2009-08-17T01:58:00.001-07:00

A week ago I noticed a problem with a strange behavior of an EJB component.

Source code inspecting was not enough to understand what was happening. So I had to debug the component. In that moment I remembered what I felt the first time when I had to do a debug on such kind of application. I supposed that should be a complicated process behind, that I was needed some sophisticated tool for that. In reality the task is very easy to accomplish. Even the title of this article is misleading. You will understand why.

Java virtual machine gives us the everything to do a remote debug on any kind of Java application. Simply, as long as we have the source code, we can debug anything on the local computer or on the network. JBossAS is a Java application itself, like any other. Ok, not like any other, but from this point of view there is not difference.

Taking thisn into consideration, all we have to do is to configure the virtual machine on which the JBossAS is running. We have to enable a TCP connection for remote debugging, to enable the required port in firewall and to connect our IDE to that port. We need to have an IDE which is able to do a remote debugging, but virtually all the IDEs on the market implement that feature.

Configuring JBossAS

JBossAS make things simpler, from this point of view. If you use Linux, you should modify run.conf, if on Windows, you should modify directly run.bat (don't have any clue why on Windows they don't use run.conf). Here are the lines which should be modified.

# Sample JPDA settings for remote socket debuging
#JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

If have only to remove the comment sign on the second line. We can change the port as we wish (TCP is used). Default value for that is 8787. The suspend deserves a closer look. If we change the value to y, that, the debugged process will wait for the client to make a remote connection and after that will continue to run. This is very useful if we have to debug something in the initializing code of the target application. Now is not useful.

I repeat, this kind of debugging can be enabled on any Java process. In that case this options are give in the command line to the java runtime.

Network configuration

If the target process is executed on another computer we should be able to connect on that machine. In order to be able to do this the specified port should not be blocked by firewall, if we have something like this enable. If the target system is not in our network or we don't have direct acces on that, than we have to create a path to that port. We do that using routing and port forwarding. Eventually from computer to computer until we found one which we can connect to.

Starting a remote debug session from Eclipse

In Ecplise we use menu item Run -> Debug Configurations .. It will open a dialog box with execution configuration. We create a configuration for Remote Java Application. There we specify the project which contains the sources we want to debug, the host name or ip of the target system and the port, also.

Eventually we configure the breakpoints we want and .. happy debugging!

Two ways to start with Seam Framework

2009-08-17T01:57:00.002-07:00

Seam is an Open Source framework for building Web Java EE.

Main functionalities includes:

building managed beans on the fly for web modules
building EJB components in contexts richer that the three standard contexts for web apps (application, session and request)
useful JSF elements
many many other functionalities, but I wil not still from you the pleasure to discover these reading the official reference guide, which worths every minute spent

When we want to create a project structure for a Seam Java EE application we have two options: generate application using seam-gen or create that using JBossTools, an Eclipse plugin published by JBoss. I will not introduce you to the details of these processes, but I will insist on the consequences and what you can expect.

Create application with JBossTools

JBossTools is an Eclipse plug-in dedicated to manage this kind of application. More precisely, it offers a wizard which can be used to generate Seam Web applications. In the dialog boxes of this wizard you should specify all the start up information, including project names and modules, package names and persistence configuration. Using dialog boxes the process of creating the application becomes almost trivial.

JBossTools also offers a lot of functionalities which can be used after the project generation. It contains complex editors for web pages and for specific configuration files. In the same time, using additional wizards, we can add new components to the application. Yopu can generate entities from relational databases, creating web pages for generated entities, add new EJB or client modules and many others.

Generate application using seam-gen

Seam Framework contains in its distribution a tool to generate Seam Java EE projects. Unlike JBossTools, this is a command line tool. It is based on Ant, so is executed in a similar way like a regular Ant taks. In order to generate the application, seam-gen needs also some information. They are the almost the same as in the case of JBossTools.

After you configure and execute seam-gen tool, the result will be produced in the form of a folder in which you will find everything required to build a Seam Web application. seam-gen will generate projects for Eclipse and NetBeans.

Strong/weak points

The two folder structures are not identical at all. JBossTools uses a project for every module of the Java EE application. seam-gen, on the contrary, uses a single project, containing a folder structure having everything you need to build and deploy all the application mdoules. JBossTools has an advantage on that, having a separate structure for every module helps to have an image about the project more closer to the final product.

JBossTool allows fast project configurations, using dialog boxes to set up every property of the projects. On the other hand, seam-gen uses for building and deploying an Ant build script. Using the Ant script is, of course, more harder to manage than a dialog box. Still, the build script is more flexible, practically we can take and implement any decision we like. For begginers the Ant script can seem intimidant, first choise would be JBossTools way. For the advanced ones, the complete control and flexibility makes the seam-gen variant be the first choice. If we count also the possibility of finding bugs in JBossTools (experience confirmed me that), the configuration can become a real nightmare.

The possibility to add with ease new modules brings again JBossTools in front. Modules having separate projects and the UI manipulation of settings is a real advantage. Although, the more experienced programmers know that the structure of a Java EE aplication module is very clear and easy to build. That's why the building of these modules using Ant script is realy easy after you understand basics.

JBossTools is integrated in Eclipse. It uses a lot from Web Tools Platform, a functionality set for Java EE. The advanced editors are often very useful. I name here the JBossTools editor for facelets web pages, which have an autocomplet feature for Seam EL and page preview. If you want another IDE or deploy to another kind of server, other than JBoss (Glassfish), than seam-gen is your choice. You have a generated project ready for NetBeans, but, because we have a project based on An, practically you can use the project with any other IDE. In the same time, using seam-gen you can choose to use various techonlogies for generating web pages (Apache Wicket, just to name one).

Conclusion

For the beginners in working with Seam Web Java EE, probably JBossTools fits well. The more advanced users will apreciate the flexibility and portability of the structure generated by seam-gen, and also the control offered by Ant build script. Even for beginners, learning Ant (not complicated at all) will give good thing on long term. We should not forget the advanced features offered by JBossTools.

My proposal is a simple one. Use the best things from both. Use seam-gen for generating the project structure. In time you can manipulate Ant build scriptwithout difficulties. In the same time, use Eclipse and JBossTools for editing web resources, is priceles very often.