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

Announcing Developer Tool Updates: DevSuite, DevStudio, CDK, more

I’m extremely pleased to announce additions and updates to our Red Hat Development Suite of products, including Container Development Kit 3.3, JBoss Developer Studio 11.2, and our DevSuite 2.2 installer. These updates are a continuation of our efforts to increase developer usability, while adding new features that matter most for targeting Red Hat platforms.

Red Hat Development Suite is a curated, integrated set of desktop tools especially suited for developing Linux container-based microservices that can be deployed on Red Hat Enterprise Linux, OpenShift Container Platform, and other Red Hat platforms.  In addition to the components listed above, it also enables easy installation of JBoss Enterprise Application Platform, JBoss Fuse and Kompose (tech preview), as well as numerous complementary pieces required to get an integrated development platform configured and running on your desktop. It combines these components in an easy-to-use installer to make setup simple for Windows, macOS and RHEL.

Continue reading “Announcing Developer Tool Updates: DevSuite, DevStudio, CDK, more”

Share

Red Hat & Eclipse Che

During the DevNation General Session today we talked about how we need to rethink some of the basic concepts of software development. We think it’s essential to make developers more effective and get started quickly. Rethinking what and how developers write and debug their code (what we normally call the “IDE”) is central to that.

Today, during the DevNation keynote, Red Hat announced that it is making a strategic investment in Eclipse Che. In this blog post I’ll talk about why, and also where we are starting to contribute.

One of the things that has struck me, that I realized as I’ve worked with Che over the last nine months, is that I had forgotten what the acronym “IDE” stands for — Integrated Development Environment. As I spent more time with Che, I realized that most IDEs and coding tools I used to date have focused heavily on source code (editing, compiling, building, visualizing) and have ignored the environment part — you nearly always have to follow a README to get the application running.

Che has fundamentally rethought the whole development experience, and put source code and environments on an equal level. At Red Hat we feel that Eclipse Che is fundamentally changing the very approach many of us take towards developing software. We think that the notion of a universal workspace is incredibly liberating for developers.

Continue reading “Red Hat & Eclipse Che”

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