Apache Camel URI completion: easy installation for Eclipse, VS Code, and OpenShift.io

Discoverability and ease of installation of Apache Camel tooling based on the Language Server Protocol has been improved. Manual download and installation of binaries is no longer necessary!  For the Eclipse desktop IDE and the VS Code environment you can now find and install the Camel tooling directly from the marketplaces for each development environment.

Camel Language Server is now also available in Red Hat OpenShift.io!

In this article, I will show you how you can install Camel tooling via the marketplaces for Eclipse and VS Code.  I will also show how to enable Camel tooling in your OpenShift.io workspace.

Continue reading “Apache Camel URI completion: easy installation for Eclipse, VS Code, and OpenShift.io”

Share

Apache Camel URI completion in VS Code XML Editor and Eclipse Che

Apache Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent APISpring or Blueprint XML Configuration files, and a Scala DSL. It also uses URIs to work directly with any kind of Transport or messaging model such as HTTPActiveMQJMSJBI, SCA, MINA or CXF, as well as pluggable Components and Data Format options. Apache Camel is a small library with minimal dependencies for easy embedding in any Java application.

Continue reading “Apache Camel URI completion in VS Code XML Editor and Eclipse Che”

Share

Apache Camel URI completion in Eclipse XML Editor

Apache Camel empowers you to define routing and mediation rules in a variety of domain-specific languages, including a Java-based Fluent APISpring or Blueprint XML Configuration files, and a Scala DSL. Apache Camel uses URIs to work directly with any kind of Transport or messaging model such as HTTPActiveMQJMSJBI, SCA, MINA or CXF, as well as pluggable Components and Data Format options. Apache Camel is a small library with minimal dependencies for easy embedding in any Java application.

Continue reading “Apache Camel URI completion in Eclipse XML Editor”

Share

Deliver support for new languages in Eclipse IDE faster with Generic Editor and Language Servers

If you’re a regular on this blog, you’re probably well aware of Red Hat’s efforts in improving the Eclipse IDE and of the rise of Language Servers Protocol to develop common developer tools. Red Hat fully jumped on this opportunity to better factorize and share language-specific logic which is very likely to benefit to multiple editors, IDEs and languages at once. It also better separates the concerns of what an editor or IDE is supposed to do (text edition, integration with SCM, debug and deployment workflows…) with the target language itself. With this approach, a single language server can enable language features to multiple development tools at once, and a single development tool can be made more generic to support new languages for free, just by binding to the language server through the protocol.

Continue reading “Deliver support for new languages in Eclipse IDE faster with Generic Editor and Language Servers”

Share

Red Hat and Eclipse IDE, looking back at Neon and forward at Oxygen

Last June, Eclipse IDE had a great release, named Neon. It features, among many other less visible but still quite useful improvements, many new functionalities for everyone. If you did not migrate yet and are still using an older Eclipse version, just move to Neon right now, it’s worth it!

For this Neon release, Red Hat managed to increase its contributions to the Eclipse IDE. The 2 main teams doing Eclipse IDE development (to package Eclipse IDE as .rpm for Fedora Linux and Red Hat Enterprise Linux, and to develop JBoss Tools Eclipse plugins and Red Hat JBoss Developer Studio) could spend more time working upstream, directly on the Eclipse IDE and related projects.

If you follow some Eclipse mailing-lists or Bugzilla discussions, you’ll see that Red Hat developers are involved in many areas about improving the Eclipse IDE: look and feel, usability, necessary feature set, Linux, new trends… The intention of Red Hat regarding Eclipse IDE is clear and public: we all want the Eclipse IDE to remain great and even greater than it has even been and probably the greatest desktop IDE on the market – and this continuously. Together with the numerous other motivated contributors to the Eclipse community and ecosystem, we’re confident that’s something achievable.

Continue reading “Red Hat and Eclipse IDE, looking back at Neon and forward at Oxygen”

Share

Java Language Support for Visual Studio Code has landed

Java language server is an implementation of the language server protocol for Java. If you recall, language server protocol provides a common way for editors and IDEs to integrate with language smartness providers. By design, all of the language tooling magic happens on the Java language server, and can provide same level of smartness to tools that support the protocol. In fact, we are working with communities such as Eclipse Che to make this server available for their tools.

Continue reading Java Language Support for Visual Studio Code has landed

Share

A common interface for building developer tools

“There is already a command line for it, why can’t my favorite editor support this language?” As a developer, you’re probably familiar with this sentiment, and in reality there has never been a better time to be a software developer.

Developers have access to a growing list of languages, frameworks, libraries, and technologies that can help them solve the problems they are tasked to tackle. However, the abundance of choices often hinders the ability of Integrated Development Environments (IDEs) and code editors to support such an abundance of choice. As a result,  developers often choose to use multiple IDEs and editors for building their solutions, in order to get access to best IDE support.

IDEs are frequently architected to have direct access to the tools related to the technology for which they were designed — for programming languages this often means that IDE has access to parsers, compilers and an in memory presentation of the developed code usually in the form of an Abstract Syntax Tree (AST). This approach also means that IDE developers need to create and maintain these tools.

As an example, Eclipse Java Development Tools (JDT) project provides a compiler for Java and a Java editor which in turn uses the AST generated to implement features like code assist, outlines, refactoring, etc.

Another approach is to define an API that the IDE will invoke to provide language features. In this architecture, the IDE has no real knowledge of the programming language and instead relies on the implementations of the interface.

We think this approach has a couple of advantages: first, it allows the interfaces to be implemented by the communities that create the technology, and so know it best; second, it frees up IDE developers for what they know best — we think this results in better IDEs and editors.

Unfortunately, we do not get the full benefits of the approach because there are as many of such interfaces defined as there are editors and IDEs.

Continue reading “A common interface for building developer tools”

Share