The Import wizard that you can access via File > Import Projects from Folder…, File > Import… > General > Projects from Folder or File > Import… > Git > Projects from Git (auto-import) allows more user control. You can now see a proposal for the import (what will be imported and how) and select which sub-projects to import or exclude.
Performance is also significantly improved, and importing a Maven project will now suggest installation of m2e connectors when necessary.
A new feature has been added to safely store your credentials for various domains in a central location. As our tools grow, credential re-use by several different features is required. Having a central place to store, for example, your Red Hat Access credentials or JBoss.org credentials, for re-use by our server adapters or download-runtime features helps to prevent you from having to constantly type the same usernames and passwords in multiple locations. It also helps to ensure that if you change your password on some remote server, you only need to update one location in eclipse.
To access the central credential storage, browse to Window > Preferences > JBoss Tools / Credentials. From there, add custom domains for which you wish to store credentials, or add username/password combinations to the two pre-existing domains: access.redhat.com and jboss.org.
At this time, only
Download Runtimes and the new (experimental)
CDK Server Adapter use this new framework. However, usage is expected to increase in the future across the toolset as the tool matures.
When running an image, a launch configuration is created based on the selected image. This is useful when users want to try tweaking a previous run for various reasons (e.g. binding in new volumes or changing command parameters, etc.)
Running a container from an image can now be also done via a launch configuration.
Docker Machine is now supported for the creation of a new connection. Simply click the "Search…" button and you will be prompted to select an active Docker Machine connection, if one exists.
Containers created with a pseudo TTY allocated (-t) will open within a TM Terminal. This is much more fully featured interaction when compared with the previous standard console. In particular, the Terminal view recognizes the color code on logs and displays messages in appropriate colors.
A shortcut to build a Docker image from a Dockerfile is available. On the first call, it will prompt for the Docker connection to use and an optional name (repo/tag) to give to the image.
The launch configuration also now supports most of the build options available from CLI.
The included Forge runtime is now 3.0.0.Alpha3. You can find the full release notes here.
- Major changes
Forge now requires JDK 8 to run;
Commands are now unix-like. For example,
--targetPackagewas renamed to
--target-package. This may impact existing scripts and documentation.
Start the Forge runtime using the Ctrl+4 (or Cmd+4) key combination.
Freemarker library included in the Fremarker IDE was updated to latest available version 2.3.23.
Related JIRA: JBIDE-20908
JST / JSF / HTML Editor
Read more about their New and Noteworthy features here:
Note: These features are available via JBoss Central - Early Access as a part of AngularJS for Web Tools
Related JIRA: JBIDE-21180
More than 80 issues are fixed in this release of the OpenShift tooling, mostly targeting OpenShift 3 support. OpenShift 3 was introduced as a technology preview feature in JBDS 9.0.0.GA but will graduate to a supported feature in the upcoming JBDS 9.1.0.GA release. The following is a list of improvements and additions in this release:
You can now deploy existing workspace projects to OpenShift 3 instances. You can either create a new OpenShift application, using an OpenShift 3 connection and then select the workspace project to deploy, or you can start by right-clicking on a project and use the
Deploy to OpenShift… menu.
The project needs to be shared with git and declared a remote git repository using the HTTP(S) protocol. That repository needs to be accessible from the target OpenShift instance. Once a project is selected, a selection of compatible templates will be displayed, matching the type of the project. The remote git URL is injected as a value for the
SOURCE_REPOSITORY_URL (or legacy
GIT_URI) template parameter.
Related JIRA: JBDS-3489
A prototype for a new OpenShift 3 server adapter is now available. Its goal is to allow incremental deployment of workspace resources directly into the deployed node on OpenShift, bypassing the build step. Its capabilities are currently limited and require a number of manual steps to set up, but the usage will be streamlined in subsequent releases. Currently only Node and PHP based applications are supported.
|This feature requires a version of the OpenShift binary higher than 126.96.36.199. If no official release is available, you can download a CI build for your OS from https://ci.openshift.redhat.com/jenkins/job/devenv_ami/lastSuccessfulBuild/artifact/origin/artifacts/release/|
To create a new OpenShift 3 server adapter, ensure that you have:
the oc binary available in your system PATH, or set in
Preferences > JBoss Tools > OpenShift 3
it’s strongly recommended rsync be on the PATH too, to get a faster turnaround
an existing OpenShift 3 connection
a workspace project (preferably Node.js or PHP for now) already deployed to that connection
From the Servers view, create a new Server, select
OpenShift 3 Server Adapter and click the
Next button to reach:
Select the workspace project to deploy and this updates the
Source path to synchronize from. For Node.js and PHP projects, that means the root of the project will be deployed. Other types of projects could use different source folders (for example, an exploded WAR folder for web projects, but this is currently not heavily tested/working).
Pod Deployment Path is the target location where the files will be copied on the OpenShift pod. The current value is set to work for Node.js and PHP applications, but that could potentially be some place else for other kind of projects. Finally, you need to select the target OpenShift service. You can click finish directly once you’re set.
Now, every time you want to push your local changes directly to OpenShift without having to commit and push them to git first, right-click on your new OpenShift 3 server, in the
Servers view, and click
Publish. The content of
Source path will be automatically synchronized to the deployed pod. The initial deployment might take several seconds to perform, but subsequent deployments will be much faster. If the deployed application support resource updates (for examples, Node.js supports html updates, but needs to be restarted for JS ones, unless it’s started in debug mode), then you should be able to see your changes by simply refreshing your browser.
In future releases, this will become more streamlined. Server creation should be more automatic, changes will be automatically published (and faster) without having to manually hit the Publish menu every time, we should also be able to better support incremental deployment of JavaEE applications.
Related JIRA: JBIDE-20764
The explorer is now listening to server side events, so it can automatically refresh itself for instance, if it detects a new build or deployment has been triggered, even from the command line or the web console.
Related JIRA: JBIDE-20571
Edit… menu is available in the OpenShift Explorer, allowing you to edit any resource (except Builds) as JSON in a text editor. This is equivalent to the
oc edit command in a terminal. If a JSON editor is installed, it will be used to open the configuration, else the standard text editor will be called. When saving the configuration changes in the editor, its content will be sent to the OpenShift instance to update the underlying resource. This can be useful to, for instance, add label to resources or edit the git source URL.
|Be aware this is a very powerful tool, to use with caution, as you might risk accidentally corrupting your OpenShift project.|
Related JIRA: JBIDE-20761
When deploying a Docker image, searching for a docker image has never been easier. Click on the
Search… button and find your favorite image from the the selected Docker registry:
Please note that the image needs to have been pulled in the selected docker registry, before it can be deployed to OpenShift, or else we won’t be able to perform port mapping and OpenShift will fail to create the service.
It is now possible to expose ports to a deployment, other than just those explicitly exposed on the docker image (they still need to be exposed by the image though).
The default exposed ports can be changed, reset, but not removed, as opposed to the new aforementioned ports.
Related JIRA: JBIDE-20531
A new server adapter has been added to help start and stop the Red Hat Container Development Kit (CDK), a set of tools meant to quickly set up an OpenShift instance inside a Docker container running inside a virtual machine. While the server adapter itself has limited functionality, it is able to start and stop the CDK virtual machine via its Vagrantfile. Once 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.
This plugin is still experimental, mainly due to the rapidly changing, fast-paced development going on in the underlying CDK. It’s also worth noting that several features will not work with the raw Red Hat CDK, and depend on the presence of a
.cdk file in the same folder as your
.cdk file is included alnog with the
Vagrantfile available at the
openshift-vagrant github repository. Instruction to install and use this enhanced CDK Vagrantfile can be found at https://github.com/redhat-developer-tooling/openshift-vagrant.
Related JIRA: JBIDE-21157