CDI Tools now support CDI 2.0 projects. If your CDI project (with enabled CDI support) has CDI 2.0 jars in its classpath, CDI Tools will recognize it as CDI 2.0 project automatically. There is no need to use any special settings to distinguish CDI 1.0 or CDI 1.1 from CDI 2.0 in CDI Tools.
The new javax.enterprise.event.ObservesAsync is now being validated according to the CDI specifications.
Related JIRA: JBIDE-24949
We are happy to announce the addition of new Apache Karaf server adapters. You can now download and install Apache Karaf 4.0 and 4.1 from within your development environment.
You can now change the Apache Camel version used in your project. To do that you invoke the context menu of the project in the project explorer and navigate into the
Configure menu. There you will find the menu entry called
Change Camel Version which
will guide you through this process.
The validation in the editor has been improved to find containers which lack mandatory child elements. (for instance a Choice without a child element)
It is now possible to set Bean references from User Interface when creating a new Bean:
Editing Bean references is also now available on the properties view when editing an existing Bean:
Additional validation has been added to help users avoid mixing Beans defined with class names and Beans defined referencing other beans.
A new server adapter has been added to support the next generation of CDK 3.2. While the server adapter itself has limited functionality, it is able to start and stop the CDK virtual machine via its minishift binary. Simply hit Ctrl+3 (Cmd+3 on OSX) and type CDK, that will bring up a command to setup and/or launch the CDK server adapter. You should see the old CDK 2 server adapter along with the new CDK 3 one (labeled Red Hat Container Development Kit 3.2+ ).
All you have to do is set the credentials for your Red Hat account, the location of the CDK’s minishift binary file, the type of virtualization hypervisor and an optional CDK profile name.
Once you’re finished, a new CDK Server adapter will then be created and visible in the Servers view.
Once the server is started, Docker and OpenShift connections should appear in their respective views, allowing the user to quickly create a new Openshift application and begin developing their AwesomeApp in a highly-replicatable environment.
Related JIRA: JBIDE-25055
It is possible to login from JBoss Tools to OpenShift.io. A single account will be maintained per workspace. Once you initially logged onto OpenShift.io, all needed account information (tokens,…) will be stored securely.
There are two ways to login onto OpenShift.io:
through the UI
via a third party service that will invoke the proper extension point
In the toobar, you should see a new icon . Click on it and it will launch the login.
If this is the first time you login to OpenShift.io or if you OpenShift.io account tokens are not valid anymore, you should see a browser launched with the following content:
Enter your RHDP login and the browser will then auto-close and an extract (for security reasons) of the OpenShift.io token will be displayed:
This dialog will be also shown if an OpenShift.io account was configured in the workspace and the account information is valid.
The OpenShift.io integration can be invoked by a third party service through the
org.jboss.tools.openshift.io.code.tokenProvider extension point.
This extension point will perform the same actions as the UI but basically will return an access token for OpenShift.io to the third party service.
A detailed explanation of how to use this extension point is described here: Wiki page
You can display the account information using the Eclipse
Jboss Tools → OpenShift.io preference node. If you workspace does not contain an OpenShift.io account yet, you should see the following:
If you have a configured OpenShift.io account, you should see this:
Related JIRA: JBIDE-24793
A new command has been added to tune resource limits (CPU, memory) on an OpenShift deployment. It’s available for a Service, a DeploymentConfig, a ReplicationController or a Pod.
To activate it, go the the OpenShift explorer, select the OpenShift resource, right click and select
Edit resource limits.
The following dialog will show up:
After you changed the resource limits for this deployment, it will be updated and new pods will be spawned (not for ReplicationController)
Related JIRA: JBIDE-24145
When an OpenShift connection is created, the Docker registry URL is empty. When the CDK is started through the CDK server adapter, an OpenShift connection is created or updated if a matching OpenShift connection is found. But what if you have several OpenShift connections, the remaining ones will be left with the empty URL.
You can find the matching Docker registry URL when editing the OpenShift connection through the
Click on the
Discover button and the Docker registry URL will be filled if a matching started CDK server adapter is found:
Related JIRA: JBIDE-24491