Hybrid Mobile tools can search and use Cordova engines from local directories. This permits custom Cordova engines to be used together with the tools. At this time only custom engines that adhere to the file and naming structure of Apache Cordova distributions will be recognized by the tools.

A preference is added for selecting a default engine. Default engines are used when a configured engine for a project is removed and on the new project wizard to pre-select the engine. See above for a screen shot for the new preference node.

The registry information is now cached. This causes significantly less network calls when using Cordova Plug-in Discovery wizard.

XCode simulator integration has been updated to support XCode 5.1 version.

We contributed the Maven Profile Management UI to the m2e project. You get the same features, the Ctrl+Alt+P shortcut still works but all that is now part of m2e itself (starting from m2e 1.5 Luna M6).

The Maven Profile Management feature was removed from the JBoss Tools update site and the Red Hat Developer Studio installer.

We overhauled the application wizard that was becoming pretty crowded.

We also introduced support for downloadable cartridges. Downloadable cartridges in OpenShift allow you to pass a git repository url which contains your custom cartridge.

Your cartridge code may run as web- (standalone) or add-on-cartridge (embedded cartridge). JBoss Tools supports both breeds.

When you launch the OpenShift application wizard you will get to chose whether you want to use your existing application or create a new one.

Using your existing application is as easy as picking it from the list of all your OpenShift applications. You may freely type it’s name and get content assisted when typing. Alternatively you may hit browse and choose among your applications across all your domains.

When creating a new application you will have to choose the application type (cartridge) up-front. You may choose among the predefined cartridges that are shipped with your OpenShift server. Alternatively you may also decide to provide your own framework code via the url of your git repository ("Code Anything").

The page for configuring application details such as the name, domain, gear and the add-on (embeddable) cartridges now only shows cartridges you have added. Initially the list will be empty.

You now can add embeddable cartridges. Here you can choose among the predefined ones or provide your own cartridge code.

AS 7, EAP 6 and WildFly server adapters now support deploying over management as opposed to the file management api.

The advantage of deployment over management is that you can do this with local and remote servers without having direct access to the filesystem (you of course need to have access to the management api).

The disadvantage compared to file based deployment is that you cannot do incremental updates, it has to be full deployments. Thus if you have large deployments or want to update files incrementally the local/file based deployment is to be preffered.

Servers configured as remote no longer require a runtime locally installed. Allowing you to do deployments/queries remotely.

Adding a local runtime to your server helps with finding things like default ports, and may be required for proper functioning of some lesser-used functionality like the JMX explorer, but for most operations, a remote server no longer requires a local runtime to be present.

Whether or not a profile requires a runtime is determined by how that profile functions. Servers configured for local use always (currently) require a local runtime, while remote servers don’t anymore.

All the server adapters for JBoss AS, WildFly and EAP now has a notion of profiles.

A profile is a set of functionality and pre-configured options that help you decide how you want to run your server and what types of actions it should take for all the different types of functionality.

While earlier server adapters still only have two such profiles (local and remote servers), any server adapter based on JBoss AS 7 or later will have two additional options, specifically whether or not to prefer using "Management" operations instead of filesystem operations.

A server set in a profile preferring management operations will connect to the server’s management service to perform actions such as shutdown, deployment, and determining the state of the server. A server not preferring management operations will continue to, for example, run a shutdown command over ssh to terminate the server, or send files over ssh to your remote server’s deployment folder.

Above, you can see how to select the profile you want to use. When you select a profile you will get another page asking for the details needed for that profile. The image below shows how that looks for a remote server.

Deploy Only server now supports two profiles: local and remote. Local is similar to how it worked before (deploy files locally) and remote is adding support for deploying via Eclipse RSE system (such as secure copy over SSH).

The first step of the New Server wizard is to select either one or the other of these profiles.

When configuring the server for local use, a deploy folder and a temporary deploy folder are required.

When configuring the server for remote use, you’ll be asked to also provide a hostname for the server.

The Deploy-Only server now allow optional start and stop scripts which are used when launching and stopping the server.

Previously Deploy-Only just assumed the server was started, now you can tell it to actually do a start and stop command.

By default there are no start and stop commands available.

If you toggle the "Server is externally managed" you will be able to specify commands for start and stop.

When attempting to shut down your server, the command you’ve entered will be executed on the local or remote system. If the shutdown command fails, though, the Deploy-Only server will attempt to kill the process that was used to launch the server. Users configuring the Deploy-Only server to run the launch or shutdown scripts that wrap a java command (such as JBoss AS, EAP and WildFly) terminating these scripts may not actually terminate the backing java command.

The JAX-RS tooling now detects server-side JAX-RS Interceptors and Filters, i.e., implementations of javax.ws.rs.ext.ReaderInterceptor, javax.ws.rs.ext.ResponseInterceptor, javax.ws.rs.container.ContainerRequestFilter and javax.ws.rs.container.ContainerResponseFilter.

Such implementations are included into the JAX-RS Metamodel associated with the parent Eclipse project, and the JAX-RS validation does not complain anymore when they are annotated with @Provider.

The new @NameBinding meta-annotation is detected when found on a user-defined annotation. This user-defined annotation can be used to bind specific Filters and Interceptors to a Resource Method or a Resource (and hence, all methods of this resource) or to the whole Application.

The JAX-RS validator reports a problem if the user-defined @NameBinding annotation(s) on a Filter or Interceptor is(are) not bound to a Resource, a Resource Method or the Application (and vice-versa), as the JAX-RS Specification states:

Also, the @PreMatching annotation is only allowed on implementations of javax.ws.rs.container.ContainerRequestFilter (in which case, the user-defined Container Request Filters are invoked before the Resource method is matched). The JAX-RS Validator will report a problem if this annotation is used on any other type of JAX-RS element.

When a Filter or Interceptor is annotated with a user-defined name binding annotation, then an hyperlink on this annotation provides the user with navigation to the associated resources/resource methods/application that have the same user-defined annotation (and vice-versa).

For example:

with

and

In that case, ctrl (or cmd) ` click on @CustomInterceptorBinding allow for navigation between all those 3 classes.