Gwt-maven-plugin-2.1.1-SNAPSHOT repository

I just spend a while to find the right repository for the gwt-maven-plugin version 2.1.1-SNAPSHOT.

To cut it short, one possible repository is:

<pluginRepositories>

<pluginRepository>

<id>Codehaus Group Snapshots</id>

<url>https://nexus.codehaus.org/content/groups/snapshots-group/</url&gt;

<snapshots>

<enabled>true</enabled>

</snapshots>

</pluginRepository>

</pluginRepositories>

 

Resources

SmartGWT and Ext GWT/GXT (or the question of the GWT UI framework)

Really exiting about GWT is the promise to develop sleek user interfaces with Java; even the GWT UIs created out of the box look quite impressive when compared for instance, with a vanilla Swing interface. However, a number of frameworks help tremendously in unleashing the full capabilities JavaScript offers nowadays. The brief exploration of some frameworks here is coloured by the requirement to implement a visual tree with drag and drop capabilities. Specifically, the tree should be able to support custom renderers for different kinds of trees.

The space of GWT UI frameworks seems to be dominated by the frameworks Ext GWT (also known as GXT) and SmartGWT (formerly GWT Ext). A number of smaller frameworks can also assist in GUI development, among them, for instance, gwt-dnd, the GWT incubator, GWT Widget Library and GWT mosaic. The latter listed frameworks seem to be rather immature and not very feature rich. However, they are trying to keep closer to the original GWT GUI APIs.

The main discussion on the net seems to boil down to three alternatives: (1) SmartGWT, (2) Ext GWT, and (3) sticking to the GWT standard widgets.

SmartGWT:

(+) Licensed under LGPG, therewith can be used in commercial products without purchasing a licence

(+) Many powerful widgets

(+) I have read some comments that their data binding model is superior to Ext GWT (but I didn’t look into this issue)

(-) Is very tightly linked to the underlying JavaScript library, SmartClient JS. JSNI calls are literally everywhere in the code.

(-) Maybe it is just my specific browser configuration but I found their showcase components to be quite slow and sluggish. Surprisingly the deprecated GWT Ext components seem to work better?

Ext GWT:

(+) Lots of Java Code

(+) Supported by Sencha, the maker of the Ext JS framework

(+) Compare the descriptions of GUI frameworks on the official GWT website; the description of Ext GWT seems to be the most positive ( Ext GWT (GXT), GWT-Ext, SmartGWT)

(+) They seem to plan to integrate their code closer with the GWT standard.

(-) Licensed under GPL, therefore for any commercial product a licence must be bought.

(-) The performance of GXT is 2x to 10x slower than vanilla GWT.

(-) Senacha has recently given a lot of attention to their Senacha Touch framework for developing cross-platform mobile applications. It seems they have been given less attention to Ext GWT in the recent past. However, this could also be a plus if features from Sencha Touch are migrated to Ext GWT.

(-) Since the framework is based on Java classes, GWT compile time increases (in comparison to frameworks relying on pre-built JavaScript libraries). However, the tailor made compilation also potentially reduces the download size and performance of the generated JS scripts.

Vanilla GWT Widgets:

(+) Increase portability/reusability/reliability of your code; if there is no functionality provided by the frameworks you MUST provide, stick to the standard.

(+) High customizability

(+) Best performance

(-) Limited set of widgets in comparison with Smart GWT and Ext GWT

(-) Weak support for drag and drop

Issues to Consider

GWT Integration: Can the widgets of these libraries be mixed with GWT standard widgets?

Many libraries such as SmartGWT or GWT Ext are mostly JSNI wrappers around existing java script frameworks. This of course raises more or less subtle issues of integration in the long run. However, also the current version of the Ext GWT framework (especially the layouts) are reported to work together with vanilla GWT poorly. However, I usually use <div ..> elements to do the layout of my pages. Using this approach I did not have any issues combining widgets from different frameworks.

Debugging: Is it possible to debug the code easily?

Debugging is difficult for framework relying on JavaScript. Moreover, having the code available as Java source code helps greatly in using and customizing the widget library (for instance by using inheritance). Also, the documentation of these frameworks is not exhaustive in places; therefore its good to be able to look at the code directly and let is speak for itself. However, if you are a JavaScript wizz, the same applies for the JavaScript libraries.

Licence: Open source/commercial?

Both SmartGWT and GWT ext seem to have suitable open source licences for creating client side code. To take full advantage of SmartGWTs server-side capabilities, the Pro version must be obtained.

Ext Gwt seems to have switched to an GPL licence, unsuited for most commercial applications. However, their licenses are cheaper than SmartGWT.

Drag and Drop for Trees

Ext Gwt (GXT)

Gwt Ext

  • Tree nodes can only be defined by a string. Constructor for tree nodes public TreeNode(final String text)
  • Expand/Collapse seems to work smooth
  • Drag and drop works fine

SmartGWT

  • Expand/Collapse does not seem to be very performant. Continuous expanding/collapsing leads to the UI not reacting to some of the ‘clicks’ (Strang, this seems to work better in Ext Gwt, try for yourself on the showcases)

Prototypes

Drag and drop tree with gwt-dnd:

Only a very simple demo (which can of course be improved). However, it led me to the conclusion that gwt-dnd does not seem to be mature enough to handle complex drag and drop operations on trees out of the box.

There are a number of other projects providing Tree support, such as gwt-dnd-tree – but they do not seem to provide a wide range of functionality.

Prototypes for Ext Gwt (GXT) and SmartGWT are not required, since their showcases already illustrate the functionality. It took me around 1 hr to rebuild an Ext Gwt example in an Maven/Eclipse/OSGi environment.

Showcases (as of 11.12.2010)

SmartGWT Showcase

EXT Gwt Showcase

GWT ext Showcase (superseded by SmartGWT)

GWT Incubator Demo

GWT Drag and Drop (gwt-dnd) Demo

GWT Mosaic Gallery

GWT Widget Gallery

Further Resources

Official Google Web Toolkit page on Ext GWT (GXT) (and on GWT-Ext, SmartGWT) – read between the lines …

Example Gallery for Grids, Tree and Tree Grids with Ext Gwt (with tutorials + source code)

Stackoverflow Discussion “Best GWT widget library?”

Discussion on theserverside.com on GWT toolkits

Stackoverflow Discussion “GWT vs SmartGWT, extJS”

Long and comprehensive discussion on the Google Web Toolkit Group

GWT Built in Widgets (GWT Doc)

GWT Ext Homepage (superseded by Smart Gwt)

Cannot add files to svn ignore in eclipse

The Problem

You want to exclude certain files and folders from being uploaded to the SVN repository in eclipse.

However, some files in the project allow you to right-click them and select Team / Add to svn:ignore and for other files this action is ‘greyed out’.

The Solution

  • Often you might have already checked out the file you want to ‘ignore’. In that case, there is no other option (to my knowledge) other than manually deleting the file, committing the delete, recreating the file and then adding it to svn:ignore.
  • Sometimes this problem occurs for projects, which have not been uploaded at all. In that case the following solution might work:

In the following example, the option “Add to svn:ignore” in the team context menu will be ‘greyed out’ for the file ‘acachea.txt’:

We need to commit the other file ‘NxUiGwtTree.gwt.xml’ individually to the repository (right click on this file). Afterwards, we are able to select “Add to svn:ignore” for the file ‘acachea.txt’.

Leverage Eclipse to Create Executable OSGi based Applications

Both eclipse and the Netbeans IDE provide strong tool support for deploying applications based on their respective platforms. This includes supports for branding for instance with custom splash screens as well as creating executables for various platforms (Windows, Mac OS X, Linux).

Eclipse allows to define Product configurations, which can be used to export eclipse RCP applications. However, the same mechanism can be used to deploy generic applications composed of OSGi bundles; including, for instance, OSGi applications based on Swing.

The following gives a number of pointers how the eclipse export function can be used to generate an executable of an application consistent of OSGi bundles organized as Maven artifacts.

  • Right click on the module, which manages your application life cycle and add a new Eclipse Product configuration.
  • Define ID, Version and Navme of the product.
  • Under Product Definition, empty Product and Application

  • In order to export the application, you might need to download the Eclipse Delta Pack. However, in my case the delta pack for Helios (3.6.1) did not seem to work very well and I had to download launchers individually.
  • Add the following dependency to your project:

<dependency>

<groupId>org.eclipse.equinox</groupId>

<artifactId>app</artifactId>

<version>1.0.0-v20070606</version>

</dependency>

 

  • Implement a class as the following:

import org.eclipse.equinox.app.IApplicationContext;

 

public class LinnkEclipseApplication implements org.eclipse.equinox.app.IApplication {

 

    @Override

    public Object start(IApplicationContext context) throws Exception {

        return null;

    }

 

    @Override

    public void stop() {

        

    }

 

}

(I used this class as ID for the application in the configuration but not sure if that has any implications)

  • Under Dependencies, add the bundle, which manages your application lifecycle. Then, click Add Required Plug-Ins. (Do not add other bundles of the platform)
  • Under Configuration, make sure that your main bundle is on auto start. If you use Declarative Services, also the *.equinox.ds bundle should be on auto-start.
  • From the Overview page you can export your project. The export will generate executables for the platforms you have selected (eg eclipse.exe) with a preconfigured eclipse.ini and a plugins directory with the dependencies of your project.
  • With module dependencies declared in Maven, I found that these are often not assembled correctly into osgi bundles from the eclipse product export function. Therefore, I took the ‘raw’ Maven artifacts and replaced the bundles created by eclipse with them. As the naming conventions of Maven and OSGi are slightly different, I wrote the following crude routine to rename the Macen artifacts.

package de.mxro.zz.mavenosgibundlerenamer;

 

import java.io.File;

 

public class BundleRenamer {

 

    public static void main(String[] args) {

        

        File file= new java.io.File(“C:/Data/Jars”);

        

        for (File f : file.listFiles()) {

            

            String jarName = f.getName();

            String bundleName = jarName.replaceFirst(“-“, “_”).replaceFirst(“-“, “.”);

            

            f.renameTo(new File(bundleName));

            

            System.out.println(“Jar : “+f);

            System.out.println(“Renamed to: “+bundleName);

            

        }

        

    }

 

}

 

  • If you want to get rid of the console window started by eclipse, just remove the Program Arguments from the tab ‘Launching’.

 

Screenshots

 

 

Resources

Info on Interfaces to create custom Eclipse application (Eclipse documentation)

Eclipse PDE Tutorial from vogolla.de

Eclipse help pages for product export

How to create an Eclipse product (on eclipse wiki)

Eclipse Downloads – download the delta pack from here

Download the individual launchers from this location (only for Helios 3.6.1)

 

“build.properties does not exist” and Maven Eclipse Plugin

The Problem

After generating an eclipse project using both the Maven Eclipse Plugin and the Maven Bundle Plugin (BND), eclipse warns that “build.properies does not exist”.

The Solution

Maybe more a workaround than a solution but it is relatively simple to create the build.properties file manually in the eclipse project. Below an example for a build.properties file for a Maven project, which should not result in any errors.

source.. = src/test/java,\


src/main/java/

 

“No required execution environment has been set” from Maven Bundle Plugin

The Problem

After generating the MANIFEST.MF with the Apache Felix Maven Bundle Plugin (BND) for an eclipse project, eclipse warns that “No required execution environment has been set”.

The Solution

The solution is to add an instruction to the configuration of the maven bundle plugin and explicity specify the execution environment as shown below.

<plugin>

                <groupId>org.apache.felix</groupId>

                <artifactId>maven-bundle-plugin</artifactId>

                <extensions>true</extensions>

                <configuration>

                    <instructions>

                        <Bundle-SymbolicName>${project.artifactId}</Bundle-SymbolicName>

                        <Bundle-Version>${project.version}</Bundle-Version>

                        <Import-Package>${module.importedPackages}</Import-Package>

                        <Export-Package>${module.exportedPackages}</Export-Package>

                        <Service-Component>${module.serviceDefinitions}</Service-Component>

                        <Bundle-RequiredExecutionEnvironment>JavaSE-1.6</Bundle-RequiredExecutionEnvironment>

                    </instructions>

                </configuration>

            </plugin>