XMPP/GTalk Shell Connector for Apache Karaf / Felix GoGo

Connecting Felix GoGo Shell through XMPP / Google Talk ?

I did a pretty interesting experiment (and will be useful at least to myself) connecting the Felix GoGo Shell in Apache Karaf/ServiceMix to XMPP/Google Talk Instant Messaging Protocol via Smack library. I spent almost 24 hours just for this. The results is pretty amazing though. :-)

I also spent quite some time to make ANSI colors sort of "working". It's not strictly correct, but at least it's not entirely boring.

What do you think ?

UPDATE: The OSGi Blueprint-compatible XMPP Shell connector is available as open source with Apache License 2.0 at https://github.com/soluvas/com.soluvas.shell.xmpp

Recommended Resources
For more in-depth explanation on OSGi, I highly recommend OSGi in Action: Creating Modular Applications in Java.

How to Fix Eclipse BIRT Designer 3.7.1 Crash when Prevewing Reports in Linux 64-bit

When previewing a report or running the report in embedded web browser, Eclipse Reporting / BIRT 3.7.1 running in 64-bit Linux crashes with only the following messages:

No bp log location saved, using default.

[000:000] Browser XEmbed support present: 1

[000:000] Browser toolkit is Gtk2.

[000:000] Using Gtk2 toolkit

[000:000] Warning(optionsfile.cc:22): Load: Could not open file

[000:000] No bp log location saved, using default.

[000:000] Browser XEmbed support present: 1

[000:000] Browser toolkit is Gtk2.

[000:000] Using Gtk2 toolkit

[000:273] Warning(optionsfile.cc:22): Load: Could not open file

[000:273] No bp log location saved, using default.

[000:273] Browser XEmbed support present: 1

[000:273] Browser toolkit is Gtk2.

[000:273] Using Gtk2 toolkit

Opened debug file '/home/ceefour/tmp/mozdebug'

It happens with all reports, even with a blank one.

To reproduce:

1. Launch Eclipse for Java & Report Developers 3.7.1 64-bit in Ubuntu 11.04 64-bit
2. Create a new report
3. On the blank report, click Preview tab ...... crash

It is reported as Eclipse Bugzilla Bug 362416.

Here's a workaround to fix it:

./eclipse -vmargs -Dorg.eclipse.swt.browser.DefaultType=mozilla

This solves the crashing problem entirely. So it's not a fix but a temporary workaround until the BIRT developers come up with a fix to this problem permanently.

Workaround found from: https://bugs.eclipse.org/bugs/show_bug.cgi?id=349837#c14

The (upstream) Eclipse bug was marked fixed as of 3.7.1 however it still requires the manual command-line argument to avoid the crash in Eclipse Reporting/BIRT 3.7.1.

My sistem info:

Linux annafi 2.6.38-12-generic #51+kamal3~mjgbacklight5-Ubuntu SMP Wed Oct 5
20:13:06 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
java version "1.6.0_26"
Java™ SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot™ 64-Bit Server VM (build 20.1-b02, mixed mode) 

I first reported this bug in BIRT Exchange forum thread here.

Want to create complex business reports easily? Get BIRT: A Field Guide (3rd Edition) for an excellent starter resource.

To integrate BIRT reports with your application, check out Integrating and Extending BIRT (3rd Edition).

Generation Gap Pattern vs Protected Regions in Xtext MDD

During the development of the awesome Xtext Protected Regions Support created by Daniel Dietrich, Daniel asked a really interesting question:

Just interested in your opinion / your 2 cents:

It's best practice to separate generated from non-generated code (when it comes to put it in a versioning system).
Therefor people use the generation gap pattern - the generated class is a base class (or s.th. similar), the manual written / generated-once classes implement the generated classes.

When using protected regions, all files (including the generated) have to be checked in. Some say, this ends up in a versioning disaster.

I prefer the protected regions approach. the base classes of the ggp nearly double the count of classes. this is a technical vehicle which makes no sense for the application. but how could be avoided, that generated classes are checked in?

my only answer is, that the generated code has to be cut of the files. empty files will disappear, protected regions are preserved. when checking out files, the generator has to be started. before checking in files, the generated code has to be stripped (into a special dir which will be checked in?).

this sounds like a technical vehicle, too. would that make sense?

To which replied: (note that these are my opinion, and I don't claim to be an expert, so feel free to challenge my assumptions and prove me wrong!) :-)

I have nothing against GAP. It definitely has its valid uses. So for certain problems, GAP is a valid solution, and is even preferable to regions.

About versioning, I'm not sure it's a "disaster". Redundant maybe, but dangerous? I don't think so. Avoiding to checkin generated files maybe preferable where the source DSL files are "authoritative" and the target files are "final".

Let me illustrate: wsdlimport. The WSDL file is an authoritative source. The generator is stable. Generated Java Proxy Classes are "dumb" target files. You can regenerate those anytime, no need for customization. And the generator is never changed so you can be sure generated files will actually compile and work. No need to checkin the Java targets.

Xtext can be used for projects of that kind, and very easy for that.

There are also projects that fall in the middle: need some customization. So you do GAP: generate the base class and the customizable subclass. This technique is excellent for some cases, but fails when:

1. You're restricted by the class hierarchy in some way.
2. Target language doesn't support subclassing, say: XML. Or my case, this would be yet another custom DSL.

There are also cases where GAP technically works, but the generated class structure is complex enough that separating the base class from the actual class makes it "unnatural". I'm sure you've seen stuff like that. Oh, let me give a concrete example from one of my prototypes:

def StringConcatenation genMainFile(String fileName) { val result = new StringConcatenation() result.append( augmenter.beforeMainFile(fileName) ) result.append( augmenter.aroundMainFile(fileName, [fn1 | { doMainFile(fn1, [ fn2 | augmenter.innerMainFile(fn2, [fn3 | { genImportBlock() genClassBlock() null }]) ]) }]) ) result.append( augmenter.afterMainFile(fileName) ) result }

Mind you the above code actually works, but it's damn ugly! At least with protected regions there will only be (marker) comments. And with most editors, comments can be folded and not so distracting, so it's much more bearable.

Some may say "it's only the base class, nobody will touch it". On the contrary, you'll see those structural methods on your debugging stack traces, just "perfect" at the time when you're in deep need of clear & cohesive program structure, but oh... you're buried in nested method calls. :-( AspectJ/AOP/weaving also has this problem, though it's manageable to some extent. They only fall apart when pushed too far, so moderate use is OK.

The third class is projects that require extensive customization. The source DSL only comprises of ~20% of the target, providing structure or supporting form, and gives places to fill, where these are filled by the programmer or some other DSL.

In my (currently hypothetical, but hopefully realized soon) the Entity->UI generator will not generate JSF/GWT forms/pages directly, but generate to an intermediate UI DSL. (you can argue this is Model-to-Model, not M2T, but hey, textual models are much easier to inspect/hack than something buried in XML!) The UI DSL can then be processed to generate JSF or GWT.

I'm not really interested in supporting class inheritance in a UI DSL. In fact the "class" concept itself may not exist in a UI domain, it only matters to OO world. So protected regions is the only option, and thankfully Xtext supports comments by default.

With that, it's possible to customize the generated UI DSL files right in the places where they're needed.

Another use case that I'm exploring, is two or more generators (which may or may not be sourcing the same model) generating to the same file, but in different regions. And the FSA should automagically merge them.

And then, add to the mix that the generators themselves are in constant development. That means the same source DSL when processed, may yield target files that are broken, uncompilable, buggy, etc. And the target files are needed because they form the foundation of yet another project, so unless the previous "working" target files can be recovered, the development of the derived project effectively stops.

For those uses cases, would I checkin the target files? Of course.

With all of the above said, I have nothing against GAP or un-checkin generated files. GAP & un-checkin may be common, but I believe there are classes of problems where they're inappropriate.

To learn Modeling with Eclipse Modeling Framework (EMF), I highly recommend the book EMF: Eclipse Modeling Framework.

How to Fix Ant Build Error: "Could not load a dependent class com/jcraft/jsch/Logger. It is not enough to have Ant's optional JARs"

If you get an error message like this while running a problematic Ant build script file :

remote.flush:

BUILD FAILED
/home/ceefour/git/magento-id/build.xml:13: The following error occurred while executing this line:
/home/ceefour/git/magento-id/build.xml:22: Problem: failed to create task or type sshexec
Cause: Could not load a dependent class com/jcraft/jsch/Logger
       It is not enough to have Ant's optional JARs
       you need the JAR files that the optional tasks depend upon.
       Ant's optional task dependencies are listed in the manual.
Action: Determine what extra JAR files are needed, and place them in one of:
        -/home/opt/eclipse_web/plugins/org.apache.ant_1.8.2.v20110505-1300/lib
        -/home/ceefour/.ant/lib
        -a directory added on the command line with the -lib argument

Do not panic, this is a common problem.
The commonest cause is a missing JAR.

This is not a bug; it is a configuration problem

It means your Ant build script file using optional Ant libraries and need to tell Ant where to find them.

In my case, it needs jsch.jar aka libjsch-java package in Debian/Ubuntu Linux.

First you need to install ant-optional package for Ant optional libraries support :
sudo apt-get install ant-optional

Then the libjsch-java Debian/Ubuntu package:
sudo apt-get install libjsch-java

Then put it in correct directories so that Ant can find them :

sudo ln -s /usr/share/java/jsch.jar /usr/share/ant/lib/
mkdir -vp ~/.ant/lib
ln -s /usr/share/java/jsch.jar ~/.ant/lib/

Ubuntu's Ant look for libraries in /usr/share/ant/lib folder, while Eclipse IDE's Ant look for optional Ant libraries in $HOME/.ant/lib folder.

Note that for Eclipse IDE, you may need to refresh Eclipse Ant Plug-in's Runtime Classpath, by going to Window > Preferences > Ant > Runtime, and clicking "Restore Defaults".
Make sure that the required libraries are now listed under "Global Entries".

Ant build system is frequently used in typical Java EE 6 enterprise application development. I highly recommend The Java EE 6 Tutorial: Basic Concepts (4th Edition) for a practical guide to the Java EE 6 technology.

How to Create A Software Site from Plug-in Bundles for Eclipse Tycho Maven

As of Eclipse Tycho Maven plugin 0.12.0, it can only use "InstallationUnit" type (aka Software Site sources) from a target platform definition file. So you cannot use Features, Installation, or Directory in your target definition file.

If all the plug-ins your Eclipse Platform application requires are already in a Software Site/Update Site, you're lucky. But if not, don't despair. Gather all the plug-ins in a directory and...
(note: you may need to OSGify some files beforehand using Bnd or Eclipse PDE)

The lighting way:
If it already contains feature(s) that list the available plug-ins, just create a .target definition file and in Eclipse right click the .target and export it. Done!
If not, continue below...

The quick way:

1. Create a Feature project, initial plug-in list is empty.
2. Create a .target platform definition file in PDE, inside the Feature Project. Add the bundles. Activate it.
3. Open the feature.xml, Plug-ins tab. Select all plug-ins (use "*.*" filter)
4. Right click the Feature project, Export... as a deployable feature :-) There, you get your Software Site neatly prepared and ready for some serious Tycho action! :D
   

The hard way:
https://docs.sonatype.org/display/TYCHO/How+to+make+existing+OSGi+bundles+consumable+by+Tycho
;-)

To learn more about Eclipse platform programming, I highly recommend Eclipse Rich Client Platform (2nd Edition).

Configuring Eclipse Tycho Maven Plugin to use Target Definition File and Publishing Target Platform Bundles to Update Site

I answered an Eclipse Tycho Maven Plugin question on StackOverfow and I think I should repeat it here (for my own purpose, hehe.. I am forgetful :-)

I should expand this to have better coverage of Tycho workflow but usually I'll get lazy so here it is pretty much verbatim.

Create a Target Definition file (.target) and put it inside a Maven project, see here for example target: https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo/blob/master/platform/indigo.target

You need to attach the .target file to the artifact, using the build helper:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>build-helper-maven-plugin</artifactId>
    <version>1.3</version>
    <executions>
        <execution>
            <id>attach-artifacts</id>
            <phase>package</phase>
            <goals>
                <goal>attach-artifact</goal>
            </goals>
            <configuration>
                <artifacts>
                    <artifact>
                        <file>indigo.target</file>
                        <type>target</type>
                        <classifier>indigo</classifier>
                    </artifact>
                </artifacts>
            </configuration>
        </execution>
    </executions>
</plugin>

(from https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo/blob/master/platform/pom.xml )

Then, in the parent POM or the plug-in projects that use that target definition file, you need to configure the "target" of target-platform-configuration Maven plugin, for example:

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>target-platform-configuration</artifactId>
    <version>${tycho-version}</version>
    <configuration>
        <resolver>p2</resolver>
        <ignoreTychoRepositories>true</ignoreTychoRepositories>
        <target>
            <artifact>
                <groupId>com.eclipsesource.sandbox.weaving.demo</groupId>
                <artifactId>com.eclipsesource.sandbox.weaving.demo.platform</artifactId>
                <version>0.1.0-SNAPSHOT</version>
                <classifier>indigo</classifier>
            </artifact>
        </target>
        <environments>
            <environment>
                <os>${build.os}</os>
                <ws>${build.ws}</ws>
                <arch>${build.arch}</arch>
            </environment>
        </environments>
    </configuration>
</plugin>

(taken from https://github.com/eclipsesource/com.eclipsesource.tycho.aspectj.demo/blob/master/releng/pom.xml )

Then your project(s) should build very nicely using Tycho. :-) If your .target references remote p2 repositories and not already in the p2 bundle pool, the necessary artifacts will be downloaded automatically.

Good luck!

Known Issue:

[WARNING] Target location type: Profile is not supported 

As of Tycho 0.12.0, It means the "Eclipse Installation" target source type cannot be used with Tycho (yet?), along with "Directory" and "Features".

Solution: Use the "Update Site" target source.

If you don't have yet an update site, here's to generate an update site from an Eclipse installation (or from any folder containing bundles, for that matter):

/opt/eclipse_rcp/eclipse -consolelog -nosplash -verbose \
  -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher \
  -metadataRepository file:/home/ceefour/p2/bonita/ \
  -artifactRepository file:/home/ceefour/p2/bonita/ \
  -source /home/ceefour/BOS-5.5.1/studio/ \
  -publishArtifacts

Note:

• change /opt/eclipse_rcp to your own Eclipse SDK installation
• metadataRepository and artifactRepository is the folder where the new update site will be created
• source is --you guessed it-- the folder/installation containing the original bundles

To learn more about Eclipse platform programming, I highly recommend Eclipse Rich Client Platform (2nd Edition)

Hot Deploy & F5/Refresh-Driven Web Application Development Are Ancient Compared to Eclipse RAP!

Most web applications developer would be very familiar with F5/Refresh-Driven development. You know, make a little change and press F5 in the web browser and you can view the updated page. This was the good old PHP days.

Java EE web application developers used to not that lucky. While some changes like JSP pages, JSF facelets, etc. take effect immediately (and thus, "refresh-driven"), in some cases they have to "redeploy". This usually means developer changes a Java class backing bean or an "important" file like web.xml. Redeploy means undeploying the web app from the Java EE container or application server, then redeploying the web app or WAR again. IDEs like the excellent Eclipse IDE Indigo (yay!) automate this but a redeploy can take anything between a few seconds to... minutes! I think typical web apps would deploy in about 20-30 seconds so that is painful.

JRebel from ZeroTurnaround (which just won the Most Innovative Java Technology in JAX Innovation Awards 2011, congratulations guys!) really helps here, by allowing most common changes to not cause a full redeploy, but just... hot deploy! It's like JSP/JSF but for the rest of Java app, Spring beans, etc. JRebel is a commercial plug-in but is definitely worth it.

But I'd argue Eclipse RAP should won the Most Innovative Java Technology title... Here's why!

(Eclipse Rich Ajax Platform/RAP is framework to develop AJAX-powered web applications easily based on Eclipse RCP programming model, see Eclipse Rich Client Platform (2nd Edition) for more information.)

I've just noticed something today. I know I should've noticed this long ago, but when you launch an Eclipse RAP rich internet application from Eclipse IDE using Debug (F11 key), ALL your code changes take effect immediately! No exceptions!

No need to even refresh the web browser!

Change the code for a menu item or a view or an action, save the .java file, go to the browser and click it... your new code is there!

"No refresh? But how can it be!"

Part of the magic is due to OSGi Dynamic Module System, that is brilliantly integrated as part of the Eclipse platform itself.

So when you save a Java file, Eclipse IDE will compile your class (and only your class, due to incremental builder feature, so it's very fast!), then update the OSGi bundle or Eclipse plug-in in the Eclipse RAP application. And only your bundle/plug-in is updated/refreshed in the application, so again, even if it's a different process it's also very fast. The whole process typically takes less than a second on a typical developer workstation, even on moderately complex apps! Most of the time the process is already done before you have a chance to hit Alt+Tab. ;-)

The other part of the magic is even though Eclipse RAP application comes with full AJAX features by default (it's not an option, it's actually a requirement), most of the business logic is server-side Java. So even if the most of the render JavaScript/HTML presentation layer in the web browser, when you perform an action for example by clicking a menu item, this will trigger a server request...

Which means your updated code! Yay! :)

Also important feature of Eclipse RAP is that for background/long-running jobs or "server push" operations, Eclipse RAP supports several approaches: Eclipse Jobs API or session-long UICallback.

This is pretty much automatic if you're already an Eclipse RCP programmer utilizing Jobs API. There's no need to do workarounds and hacks like traditional AJAX web development or learn yet another new API (and programming model) just for server push.

To learn more about Eclipse platform programming, I highly recommend Eclipse Rich Client Platform (2nd Edition). It's really good for learning Eclipse RCP/RAP development, most of the things that apply to RCP also applies to RAP. In fact, you can single-source an application to two target platforms (RCP for desktop, RAP for web) simultaneously. :-)