We added usage tracking into our JBoss Tools 3.2 M2 release and since then it have been pouring in with pings from all over the world and we love every second of it. Nothing like it, seeing your hard work being used across the planet. Today we've passed 1.000 different cities and the number is ever increasing.

The above screenshot is a snapshot of the current cities we have received pings from over the last week. Darker color and size of the circle indicates the % of visits. For now Brazil and especially the Sao Paolo region has the biggest crowd.

Yesterday we had 2.500+ instances of JBoss Tools starting up within 24 hours and our total of unique Eclipse installs using M2 passed 18.000 this morning.

Very happy to see that much pickup of our M2 release within just a week, I'm very postively surprised so many approved and enabled the tracking and growing every day.

Many thanks for those who did and those who will in the future - it's much more fun than watching simple download counts and give some nice fun content for a Friday blog

While looking into some options on how to make the use of annotations simpler for users, I ran across the Annotation Properties view, which is in Helios in the JAX-WS->Annotation Properties view category when you're trying to open a view (Window->Show View->Other).

If you haven't seen this view before (and I know I hadn't), it offers a way to register annotation classes in a common place to allow you to add/remove/edit annotations in a class. By default in the Helios JEE package, it comes with JAXB and JAX-WS annotations already set up. It's a little clunky in spots, but I think it offers some interesting options as far as functionality goes.

For example, to create a new JAX-WS annotated class, you can start with your favorite POJO and annotate it pretty quickly:

The view also offers the ability to filter the available annotations so you're not simply overwhelmed. To get to the Filters dialog, use the View menu and select Filters...

This is a little clunky as far as an interface goes. You can only open one instance of the view at a time and can't easily switch between annotation types. But it's a start anyway.

So with this in mind, I asked in the WTP newsgroup about how to go about extending it. Shane Clarke was nice enough to provide some tips...

The two extension points associated with the Annotation Properties view are located in the org.eclipse.jst.ws.annotations.core plug-in. The main two are the the org.eclipse.jst.ws.annotations.core.annotationCategory and org.eclipse.jst.ws.annotations.core.annotationDefinition extension points. Basically you just define a category (which shows up in the Filters dialog) and then define one or more associated annotation classes.

The only trick is making sure that the annotations are on the plug-in classpath and then adding the line "Eclipse-RegisterBuddy: org.eclipse.jst.ws.annotations.core" to your MANIFEST.MF.

So as an example, we'll just create a new category:

   <extension
         point="org.eclipse.jst.ws.annotations.core.annotationCategory">
      <category
            id="org.my.annotation.category"
            name="My Category Name">
      </category>
   </extension>

And then we'll define a new annotation for it:

   <extension
         point="org.eclipse.jst.ws.annotations.core.annotationDefinition">
      <annotation
            category="org.my.annotation.category"
            class="some.annotation.class.MyAnnotation"
            name="MyAnnotation">
      </annotation>
   </extension>

For examples of how they implemented the JAX-WS and JAXB annotations, check out org.eclipse.jst.ws.jaxws.core and org.eclipse.jst.ws.jaxb.core.

Pretty easy. I was able to define annotations for some new functionality in our JBoss ESB product that allows you to annotate a class instead of extending a particular interface or extending an existing class.

I obviously think that the Annotation Properties view could be used for more than just Web Service class annotations.

But it needs a bit of work... For example, it would be nice if you could create a saved setting like a working set and made more visible - perhaps in the toolbar area at the top of the view. And it would be great if you could create multiple instances and associate a particular view instance with an editor, similar to how the Project Explorer can be linked to the editors and show which file is being worked on.

And I'm not quite sure how to use all of the functionality - like those other two extension points - or some of the settings on the annotationDefinition extension.

That said, I think it's a great start and it would be awesome to have a consistent way to annotate Java classes. I'm not sure that this is really a WTP-specific view and think it would make more sense in the more general Java tools category, but that's just me.

Big thanks to Shane for the pointers and I'm looking forward to seeing how this functionality improves in future releases!

--Fitz

I'm returning from a way too busy 3-week vacation thus I thought I would give a little update on some of the events occuring while I was out.

Webinar

First of, a reminder that tomorrow I'll be doing a webinar for JBoss Tools and Developer Studio in the JBoss Developer Webinar Series.

The webinar will show off some of the JBoss Tools specific features in Eclipse but many of the tips and tricks I will be showing applies just as well to a plain Eclipse so there should be something for every taste

You need to register to be able to join the webinar; the time and registration links are as follows:

Date: Sept 1, 2010

Time: 16:00 UTC, 12:00 Noon Boston, 9:00 San Francisco, 12:00 Midnight Singapore

Registration: Register Now

Clouds

Last week, Red Hat revealed its strategy for Red Hat Platform-as-a-Service (PaaS) and JBoss Tools/Developer Studio is a major part of these efforts.

The functionallity we are adding is three levels of remote deployment and management of JBoss Application servers.

First level is to perform this via SSH and SCP (secure shell/secure copy) allowing it to work with all existings systems on your local or remote networks/clouds that you have SSH access to (that should cover most cases today . In current versions we only had a SSH only server which did not integrate start/stop/debugging of JBoss AS easily; with this it will.

Second level is to provide Eclipse tooling for the current DeltaCloud which enables us to do portable start/stop of virtual machines at any cloud provider DeltaCloud has a driver for (i.e. RHEV-M, EC2, Rackspace, etc.). This integration will make it super easy to start and stop these instances and together with the SSH/SCP we are already well on our way to have a fully "cloud" enabled IDE with some manual work required.

Third level is to integrate with the CoolingTower functionallity which adds some more abstraction on and around the DeltaCloud API's allowing things like deployment and provisioning to be done just as portable as DeltaCloud is for start/stop of virtual machines. Within the IDE you will not notice this much, beyond the registration to the CoolingTower service and then you can develop/deploy/debug your locally developed applications in any cloud (public or private) that allows execution of Java EE based applications.

We've already been working on it for a while and you will soon see some of this functionallity in the milestone releases.

BPEL at Eclipse

Now something completely different. We or rather Bob and Grid, have been working hard on providing a BPEL runtime (Riftsaw) and related BPEL Tooling (JBoss BPEL Tools). Initially we tried to do this as extensions on top of fine Eclipse.org BPEL functionallity but for some reason there were noone around the Eclipse BPEL project to react for any requests, patches or even doing releases for a long time.

Thus we got tired of waiting and forked of our own BPEL Tooling so we could fix bugs, do releases and move forward.

We did all this and still tried to bring life back into Eclipse.org BPEL project and eventually we got commit access and recently Bob Brodt took over leadership of the BPEL project. Thus we can now merge back our fork into Eclipse.org BPEL and start bringing some life into it again!

Bob outlines the planned work in his blog announcing the move here

Questions/Comments ?

If you got questions about the Cloud and BPEL at Eclipse join the webinar tomorrow for the Q&A or leave a comment here or on our forums.

Have fun!

Andre D. wrote a nice Wiki outlining how to use Google GWT Plugin together with JBoss Tools

It is all done by simply using JBoss Tools Project Archives to package up the relavant War and

there by be able to publish to any of the JBoss AS server adapters all without requiring

moving to Eclipse WTP projects.

It's great to see that our good old Project Archive functionallity can still be put to good use.

We are working on seeing how to get Google GWT Plugin work more integrated with the

remainder of the Eclipse ecosystem, especially in context of being able to use GWT without

fuzz as a Facet on Eclipse WTP based projects allowing the full power of WTP to be used

on GWT based projects.

JBoss Tools tycho build now provides code coverage report for eclipse-test-plugins. All eclipse-test-plugin pom.xml files provide meta information about what bundles are instrumented and what classes are included in coverage report through properties:

• emma.filter - emma filter to define what packages to include to or to exclude from report
• emma.instrument.bundles - comma separated list of bundles to be instrumented on the fly during tests execution

Here is an example from org.jboss.tools.common.test plug-ins

<properties>
     <emma.filter>org.jboss.tools.common*</emma.filter>
     <emma.instrument.bundles>org.jboss.tools.common</emma.instrument.bundles>
</properties>

To enable code coverage report generation during build

-Dcoverage

system property should be added to build command line. It activates maven coverage profile to generate coverage reports on per test plug-in basis in text and xml formats. Text reports are printed out to the build console output like

     [echo] [EMMA v2.0.5312 report, generated Wed Jul 07 12:11:50 PDT 2010]
     [echo] -------------------------------------------------------------------------------
     [echo] OVERALL COVERAGE SUMMARY:
     [echo] 
     [echo] [class, %]     [method, %]     [block, %]     [line, %]     [name]
     [echo] 61%  (22/36)!     28%  (93/328)!     17%  (1056/6326)!     20%  (308.2/1575)!     all classes
     [echo] 
     [echo] OVERALL STATS SUMMARY:
     [echo] 
     [echo] total packages:     8
     [echo] total classes:     36
     [echo] total methods:     328
     [echo] total executable files:     28
     [echo] total executable lines:     1575
     [echo] 
     [echo] COVERAGE BREAKDOWN BY PACKAGE:
     [echo] 
     [echo] [class, %]     [method, %]     [block, %]     [line, %]     [name]
     [echo] 0%   (0/1)!     0%   (0/7)!     0%   (0/78)!     0%   (0/16)!     org.jboss.tools.common.preferences
     [echo] 0%   (0/2)!     0%   (0/40)!     0%   (0/492)!     0%   (0/125)!     org.jboss.tools.common.text
     [echo] 17%  (1/6)!     4%   (3/77)!     4%   (92/2401)!     4%   (24.9/562)!     org.jboss.tools.common.util
     [echo] 67%  (4/6)!     35%  (11/31)!     19%  (77/396)!     23%  (23.2/102)!     org.jboss.tools.common.reporting
     [echo] 75%  (6/8)!     33%  (25/75)!     21%  (367/1734)!     24%  (99.2/419)!     org.jboss.tools.common.xml
     [echo] 75%  (3/4)!     48%  (11/23)!     24%  (135/562)!     32%  (44.1/139)!     org.jboss.tools.common
     [echo] 75%  (3/4)!     42%  (23/55)!     36%  (153/422)!     36%  (52.4/144)!     org.jboss.tools.common.log
     [echo] 100% (5/5)     100% (20/20)     96%  (232/241)     95%  (64.4/68)     org.jboss.tools.common.zip
     [echo] -------------------------------------------------------------------------------

Reports are generated to /target/emma folder of test plug-in.

To enable code coverage for your test plug-in just add properties listed above to your plug-in pom.xml file and activate coverage profile as it explained above.

Update: There is now a final version of JBoss Tools for Helios! No need to use the nightly builds unless you want to live on the bleeding edge!

For those who are trying to run JBoss Tools on Eclipse 3.6 aka Helios then we are working on getting a M1 build out, but for those

eager to use Helios the nightly builds can help you.

We recommend you use the update site over any of the separate standalone zip builds, thus either use the updatesite (http://download.jboss.org/jbosstools/updates/nightly/trunk/) or the update site zip from the nightly zip builds.

Don't forget to let us know if you find something not working as you expect. You can do so in our jira

or discuss them in the forums

Have fun!

[Note: This blog has been replaced by a more up to date How to Build JBoss Tools 3.2 with Maven 3.]

Current trunk version of JBoss Tools can be built with maven 3 and make it faster and easier for everyone.

Prerequisites

1. Java 1.6 SDK
2. Maven 3.beta1
3. About 6 GB of free disk space if you want to run all integration tests for (JBoss AS, Seam and Web Services Tools)
4. subversion client 1.6.X (should work with lower version as well)

Environment Setup

Maven and Java

Make sure your maven 3 is available by default and Java 1.6 is used.

mvn -version

should print out something like

Apache Maven 3.0-alpha-7 (r921173; 2010-03-09 14:31:07-0800)
Java version: 1.6.0_18
Java home: /usr/lib/jvm/java-6-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.32-22-generic-pae" arch: "i386" Family: "unix"

Sources

Checkout sources from anonymous SVN like

svn co https://svn.jboss.org/repos/jbosstools/trunk jbosstools-src

This will take some time dependent on your bandwidth

Build Strategies

All commands below is assuming that commands are executed in jbosstools-src folder after sources checked out as it suggested above.

There are several strategies to chose from building everything to build particular component or part of it like all plug-ins, all tests, all features, particular plugin/feature.

Target platform should be built first like

$mvn -f build/target-platform/pom.xml

If you want to just compile the modules, tests can be skipped by adding system property -Dmaven.test.skip=true and you should be able to faster verify compile issues.

Build/Test Everything

Current version cannot be build without local changes because of problem with with drools component, so to go with this scenario you need to remove drools references from pom.xml and site/site.xml. After that to build/test everything use:

$mvn clean install

Build/Test Particular Component with Dependencies

For convenience there are aggregator projects defined for each component. It provides a simple way to build/test components with dependencies.

$mvn clean install -f build/component/${component.name}.xml

where ${component.name} is component you want to build/test. Currently build/component folder contains aggregator projects for:

1. tests,
2. jmx,
3. archives,
4. as,
5. common,
6. seam

more is coming soon.

Build/Test Single Component

Be aware that to get this work all dependencies for this component must be installed in maven repo. It can be done by build everything first or by build component and its dependencies using aggregated project as it explained above. You can skip tests for this build and then enable them back when you run single component build.

To build single component use pom.xml in component's folder like it is shown below.

$mvn clean install -f ${component.name}/pom.xml

where ${component.name} is component's root folder name. For instance to build jmx component use command below

$mvn clean install -f jmx/pom.xml

Hi again...

I've been working on the JBoss Tools Web Service Tester and have just recently added the ability to select a WSDL file to populate the endpoint/action URLs and generate a Sample SOAP message when testing JAX-WS services. I'm still working on figuring out how to connect to a UDDI v3 registry to browse and select an operation from a published service in that context, but in the meantime you have a way to test your WSDL-based web services a bit easier...

Before I provide an example, I want to bring up a great resource for publicly-accessible web services from around the world - XMethods.net. If you haven't checked it out, it provides some great services that you can use to test tools like the WS Tester. A few that I found that are very useful for testing are:

• Temperature Conversions
• CDYNE Weather
• Driving Directions
• Google Search Results as RSS

So let's start with the Google Search Results one, which has a WSDL at http://www.ecubicle.net/gsearch_rss.asmx?WSDL.

If we look at the WS Tester, it has a new button - "Get from WSDL..."...

So I click on the "Get from WSDL..." button and see the "Select WSDL" dialog:

In the "WSDL URI:" field, I paste my WSDL URL in and it populates the three fields - Service, Port, and Operation. If there is more than one SOAP port available (such as SOAP and SOAP12), you can select it in the list and the operation list will change accordingly. In this case, there's just one operation available, but you have a vertical scroll bar on the right of the list to pick and choose.

When I hit OK, it does a number of things with the WSDL. It searches through the WSDL for the endpoint and action URLs, but more importantly it will try and generate a valid sample of the SOAP Request message. Even if the WSDL has multiple imports and/or imports schemas, it should (knock on wood) generate even complex messages fairly well. (If it doesn't, please let me know by putting in a JIRA.)

So in this case, it comes back populating the WS Tester with these values:

If I change the values a bit...

• searchPage becomes an empty value (delete the "?")
• gQuery becomes "JBoss Web Services"
• numOfResults becomes an empty value (delete the "?")

And hit Invoke...

If I copy the response into an XML file and clean it up a bit, it looks pretty good:

So if you look at a web service with multiple operations like the CDYNE Weather service (WSDL at http://ws.cdyne.com/WeatherWS/Weather.asmx?wsdl), you have more options in the operation list:

And I was able to get the forecast for my city:

So if you have a WSDL file or a URL to a WSDL file, you should be able to use the WS Tester to test it now.

Next step is to get some sort of facility into the mix so you can browse a UDDI repository for the service.

This is checked into the JBoss Tools trunk now, so you should be able to play with it. Let me know what you think!

--Fitz