A JBoss Project
Red Hat

Posts tagged with 'eclipse'

In this article we are happy to introduce new features and improvements that have been implemented as part of the JSDT project and now available in the Neon.1 release:

  • Oomph installer for JSDT setup

  • Node.js debugger improvements

  • New JavaScript debugger

  • "Quick Access" for Gulp / Grunt tasks

  • npm scripts support

Overall, 41 bugzillas have been resolved during the Neon.1 development cycle (some of the bugs have been waiting to be fixed for more than 5 years!) Also, we would like to shed some light on our plans for the Neon.2 release.

In order to have all new JavaScript features available out-of-the-box, please, use "Eclipse IDE for JavaScript and Web Developers" / "Eclipse IDE for Java EE Developers" packages

Oomph installer for JSDT setup

Want to contribute to JSDT project but do not know how? Think that environment setup is too difficult and comprehensive? Now you can easily setup JSDT using Oomph within a few minutes! Here is a short demo video which explains how to do it:

More details about Oomph setup can be found on the following link

Node.js Debugger Improvements

Node.js support was originally implemented as part of the Eclipse Neon release. In Neon.1 debugger facilities have been significantly improved. Previously in order to change the code during the debug session one should have saved the JavaScript file, right click on it → V8 Debugging → Push Source Changes to VM. Now saving the file is just enough - new changes will be applied automatically:

node debugger hot swap

Also, there are a few important bug fixes that improve the debugging experience:

  • Bug 491735 - Terminating V8 debugger process should also kill main Node process

  • Bug 497685 - Cannot set a breakpoint in "node_modules" (Windows specific)

  • Bug 497424 - Source not found for main .js file inside node_modules

More details about Node.js support in Eclipse can be found in the article Neon and Node.js: A magical friendship!

New JavaScript Debugger

Now there is a possibility to debug JavaScript using Chrome / Chromium browser. Basically, in order to debug JavaScript one should simply right click on the html file → Debug As.. → Chrome / Chromium Debugger:

There is also a possibility of debugging JavaScript for applications running on servers using Chrome / Chromium Debugger menu item:

"Chrome / Chromium debugger" menu enabled on the server adapters will work only for maven projects in which JavaScript files are located in the "webapp" folder. However, one can always tune the source mapping logic for particular project manually and run Chrome / Chromium with the debugging port enabled. More details about manual debugger setup can be found in the following video

"Quick Access" for Grunt / Gulp tasks

Now it is possible to execute tasks via "Quick Access" - just press Cntrl + 3 / ⌘ + 3 and choose Run As Grunt / Gulp task:

gulp task quick access

npm scripts support

All npm scripts defined in the package.json can be now executed via Run As.. → npm Script context menu:

npm scripts

The output of the script command will be reflected in the "Console" view:

npm scripts console

Neon.2 Agenda

In the next release we are going to switch to the Closure compiler which is more tolerant and has better performance in comparison with currently used Esprima parser. Moreover, we are going to return broken JavaScript search facilities back to JSDT. Actually, most of the work in the search direction is already done:

Other plans are coupled with polishing Node.js / JavaScript debuggers and making the whole feature set smooth, stable and complete. If you want to have some particular bug fixed in Neon.2, please, speak up on the wtp-dev mailing list or let us know on twitter, youtube, stackoverflow etc.

Thank you!

Thank you to the contributors who made the Neon.1 release happen:

  • Patrik Suzzi

  • Esteban Dugueperoux

  • Victor Rubezhny, Red Hat

  • Gorkem Ercan, RedHat

  • Angel Misevski, RedHat

  • Shane Bryzak, RedHat

We would like to express special gratitude to the community for their feedback! We look forward to hearing your comments, remarks and proposals about new Neon.1 release.
Have fun!

Ilya Buziuk
@ilyabuziuk

To celebrate the release of Eclipse Neon, the Eclipse Foundation produced a webinar series with a list of 7 of the Top New & Noteworthy Features that are integral to the Eclipse Neon Release.

Amongst those webinars, Ilya and Gorkem presented the Eclipse JavaScript Development Tools (JSDT) and I presented the Docker tooling.

JSDT Tooling

Description:

The Eclipse JavaScript Development Tools have reached a new level of features and usability with Eclipse Neon. Many things were implemented as part of the JSDT 2.0 release that is now available with Eclipse Neon. This webinar demonstrates the following new features:

  • Package managers (npm / bower)

  • Build systems (grunt / gulp)

  • Node.js Tools

  • ECMAScript 2015 (ES6) parser

The talk also features plans for the future of JavaScript development in Eclipse IDE.

The slides for the presentation are available here.

Docker Tooling

Description:

Docker is awesome, but how to use it well when doing development? In this talk you will get a quick introduction on how to use Docker effectively, especially for development from within Eclipse. We will show how the release of Eclipse Neon supports Docker to make it even more integrated into your day-to-day work from within your IDE. In particular, you’ll see how you can pull and run an image for a database, build a custom image for an application server, run it and deploy an application using data volume, exposed ports and container links. We will also take a look at some of the newest features, such as support for Docker Machine, TM Terminal integration, run configurations for containers, and a variety of other UI improvements.

The slides for the presentation are available here.

Other Webinars

Other webinars have also been recorded and are available on the Eclipse Neon Webinar Series on Youtube.

Enjoy !
Xavier Coulon
@xcoulon

I just wanted to add a few updates and my two cents to this old but still useful and accurate blog post (which is a must read of course!). Some elements were already mentioned in comments and I think all of that is worth providing a new detailed article.

Favorites - static import

There were mentions of adding static imports for JUnit Assert methods. I recommend also to add some others for these popular frameworks:

Please check out the below screenshot for what to add to your favorites:

favoritesStaticImport

Improvements for Method Templates

There is no more need to type twice Ctrl+space to have the JUnit 4 Template proposals. Even better, when you start typing "test", the JUnit 4 Template is listed first.

testAutoCompletionJunit4before

Test Failures - How to easily compare results

Did you ever noticed the little icon on top right corner of JUnit view?

compareResult JUnit

Click on it! You will get a nice dialog comparing the actual and expected results:

compareResultDialog JUnit

MoreUnit - Avanced Test Development Toolbox

MoreUnit is a plugin helping you to create and maintain Unit Tests. Some of its nice features are:

  • Wizard to create test stubs, including Mock support

  • Navigate between test class and class under test using Ctrl+J

  • Refactoring: renaming classes/methods also renames the corresponding test code

If you have tests in another projects - for instance you are an Eclipse RCP developer and use fragments for your unit tests - you can specify this folder from the MoreUnit Preferences page.

specificTestFolderMOreUnit

Infinitest - Continuous testing

Infinitest is a useful plugin to respect the Fail fast principle. It continuously executes tests in the background each time you save a file.

statusBarUpdatedOnEverySave Infinitest

If there are test failures:

  • The bottom-left status bar is turning red

  • Problem Markers are created to spot failing tests easily

ProblemMarkers InfiniTest

As some tests might be time consuming or requiring some external configuration or UI interactions, you can filter those by providing a infinitest.filters file at the root of the project. The same file will be used in other supported IDEs by Infinitest.

Eclemma - Spot untested code

After you wrote your tests, I recommend to launch the Eclemma Coverage tests. You can use Alt+Shift+E+T. It will show you a nice overview of possible missing test coverage in your code.

eclemma

Note: Don’t focus too much on the percentage but have a deeper look to uncovered or partially covered lines. Make sure that these lines are not critical ones.

For Eclipse RCP Developer

If you’re an Eclipse RCP developer, I will be happy to see you assisting to presentation at my talk at EclipseCon France (Toulouse, June 7-9). I will talk about possible architectures and available tooling to have fast Unit tests while developing Eclipse plugins. I’m looking forward sharing my experience and continue discussions later on.

And You?

Do you have some other Tips, Tricks and best practice to share?

If you are using a different IDE, do you know about killer features enabling you to efficiently write unit tests but which are missing in Eclipse? Please share them!

I’m glad to announce that the RedDeer project has graduated from the incubation phase to the mature phase.

reddeer

Don’t you know RedDeer?

RedDeer is a framework for testing Eclipse plugins (or RCP) and can be executed over various operating systems (Linux, Mac, Windows). At the beginning it was developed as an alternative to SWTBot but now it contains many features and tools which can help you with writing automated tests.

Now, when the project has left the incubation phase, the API won’t be significantly changed for a long time and you don’t have to change your existing code together with RedDeer updates. Like the previous version (0.8.0.Final) the RedDeer 1.0.0.Final is also intended for Eclipse Mars.

Main features

  • Easy to use - just create an instance of the needed widget

New LabeledText("Project name:").setText("Demo");
new PushButton("OK").click();
  • High level API - wizards, views, etc are already implemented

NewJavaClassWizardDialog newJavaClassDialog = new NewJavaClassWizardDialog();
newJavaClassDialog.open();
new NewJavaClassWizardPage().setName("Demo");
newJavaClassDialog.finish();
  • Wait conditions - wait for a specific state

new WaitWhile(new JobIsRunning(), TimePeriod.LONG);
  • Requirements - validate and set the environment according to your requirements

@ApacheTomcatServer(state = ServerReqState.RUNNING)

Tools

  • Project wizards - start testing by creating a test project with everything you need

  • Recorder - create an automated test by recording your steps

  • Spy view - spy all widgets just by mouse hover

  • GEF Spy view - spy GEF componets in a GEF editor

  • Log Parser - define rules how you want to see the log file

  • Code Generator - don’t write the code manually, generate it

Future of RedDeer

In addition to making the framework more and more stable we also plan to improve the recorder and our code generation tool. Moreover, the RedDeer framework is becoming a part of JBoss Tools target platform which means it will be available for any developer contributing to JBoss Tools.

Do you have any idea about a new feature? Raise an issue on github! If you want to contribute, please follow steps described at https://github.com/jboss-reddeer/reddeer/wiki/Developer-guide.

Article was updated on Nov. 12th with the video published on YouTube.

On Monday I had the chance to give a Tools In Action talk about Docker Tooling for Java EE Developers. After a quick introduction about the main concepts of Docker (images, containers, daemon, clients and registries), I gave a demo of the tooling that we’ve been working on in the Linux Tools and JBoss Tools team.

The goal of the demo was to deploy and debug the "HTML5 Kitchen Sink" quick start application from JBoss Central in a container running WildFly and linked to another container running PostgreSQL.

The demo showed how a user can:

  • Connect to a Docker Machine.

  • Pull images from Docker Hub.

  • Build custom images from a Dockerfile (as we needed to customized WildFly to include the PostgreSQL driver and datasource configuration)

  • Run images by configuring environment variables, links to other containers and data volumes.

  • Open a web browser on the published ports.

  • See the container logs streamed in the Eclipse console.

  • Create and configure a server adapter in the Servers View to deploy the application in the container data volume.

As explained during the demo, the Docker tooling is available from the Linux Tools project at Eclipse.org and is also bundled in JBoss Tools and Developer Studio, so you can get it from the update sites or from the marketplace.

Slides for the demo are available on Slidehare.

As Devoxx decided to stop Parleys and publish all talks for free on Youtube just after they were recorded, you can already watch the presentation here:

As usual, feedback on the Docker tooling is much appreciated, so don’t hesitate to contact us on linuxtools-dev@eclipse.org or on jbosstools-dev@jboss.org

Enjoy!
Xavier
@xcoulon

As Eclipse Mars.1 is landed a few weeks ago, let’s take a look at the main new features that we`ve worked on since our first release in June.

Improved Docker Explorer View

We’ve added icon decorators on the containers to show their state. This makes it clearer if a container is running, paused or stopped.

Improved Docker Explorer View

New Dialog to Search and Pull Images

We’ve worked on the workflow to pull and search images from Docker Hub. The updated 'Pull Image' wizard can be launched from the 'Docker Images' view or from the 'Docker Explorer' view (a new context menu entry is available on the connection node and on the 'Images' node)

Pull Image Wizard

The wizard detects the tag in the image name and if none is specified, the image tagged latest will be pulled.

If the user needs to search a specific image name, she can click on the 'Search…​' button which will open the 'Search' wizard:

Search Image Wizard

followed by a second page that displays all the tags for the selected image:

Search Image Tags Wizard

Even though this wizard can only search from Docker Hub, users can nonetheless pull images from other third-party registries. In that case, image name needs to be prefixed with the registry host and port, such as 192.168.59.103:5000/centos:7.

New Launcher to Build a Docker Image

Finally, we`ve also added a new launcher to build images from a Dockerfile.

Build Image Launcher

The source path is a directory in the workspace or on the file system and the 'Docker Connection' combo box specifies on which Docker daemon the image will be built.

As always, feedback, feature requests and bug reports are welcome. Since this tooling is developped at Eclipse.org, you can join us on our public mailing-list or use Bugzilla to report any bug or feature request.

Have fun !
Xavier Coulon
@xcoulon

JBoss Tools team is so lucky to have a great QE team who assist in testing and verifying the Eclipse plugin stack continues to function as expected. In that process they have over the years been putting together a eclipse (SWT) testing library called RedDeer.

This RedDeer project released version 0.8 just recently.

RedDeer provides various utility testing, junit and SWTBot extensions and some quite unique tools specifically liked by QE to find errors/issues during their Eclipse testing.

We are planning on contributing this to Eclipse.org in the future, but would like to get early feedback on it.

Here is what Jiri Peterka recently wrote about it in his announcement on RedDeer:

Today, version 0.8.0 was released and RedDeer is again a step closer to version 1.0. RedDeer 0.8 supports Eclipse Mars (EE). This version is mainly about architecture improvements, related re-factoring and lot of bug fixes. In terms of these changes lots of underlying functionality went into o.j.r.common and mainly to o.j.r.core plugin. This helped us to keep architecture cleaner and to avoid cross dependency issues we have faced. Still you can also find multiple API and tooling features and enhancements in this release, for example:

When you start writing test plugin you can also use org.jboss.reddeer.go as an aggregate plug-in for a start in your MANIFEST.MF instead of thinking what set of the individual plugins is right for you.

Besides that, many (~70) bug fixes and other issues (~180 in total) were resolved. Thanks to all who helped again to push RedDeer project forward.

That’s it. Enjoy your testing with new RedDeer.

— Jiri Peterka
on behalf of RedDeer dev team

More info

You can find more info at these locations:

There is complete list of RedDeer public resources:

Let us know if you like what you see and feel free to leave a comment on this blog or reach out to the RedDeer project to give them feedback.

Have fun!
Max Rydahl Andersen
@maxandersen

I’m happy to report that a few days ago the final paperwork around Red Hat upgrading their membership to Strategic Developer at Eclipse was completed and now announced at Eclipse.org.

What does this mean ?

Strategic Members are organizations that view Eclipse as a strategic platform and are investing developer and other resources to further develop Eclipse Foundation technologies. Strategic Developers commit to assign at least eight developers full time to develop Eclipse technology, lead Eclipse projects and contribute annual dues up to 250.000 $.

At Red Hat we already have more than eight developers doing development Eclipse technology, both at and around the base Eclipse distribution.

  • m2e-wtp

  • JavaScript Development Tools (JSDT)

  • vert.x

  • Linux Tools

  • Thym

  • BPMN2

  • BPEL

  • SWTBot

..and contributing to many more.

This work is used in our JBoss Tools project and two products: JBoss Developer Studio (Middleware) and Red Hat Developer Toolset (Linux Platform).

By upgrading to Strategic Developer we are confirming our continued support and commitement of resources to Eclipse, but also increasing our funding to be $250.000 annually.

Red Hat have an interest in Eclipse Foundation continues to thrive, and that its flagship, the Eclipse IDE and other opensource development tools and runtimes continues to evolve and improve.

Stepping down and up from the board

This announcement also means I’ll have to step down from the board as solutions member representative, but I’ll be joining again as Red Hat’s representative for their newly aquired Strategic Developer position.

I’m happy to have served and I’m looking forward to see which other solutions member will come join in on the board and bring Eclipse Foundation forward.

What next ?

We’ve been contributing and continue to help making Eclipse Mars a great release, together with the rest of the community. We are especially working on fixing GTK/SWT on Linux, making Docker support and looking at improving the Java Script Development tools. The latter I did a presentation at EclipseCon which provide some of ideas what we are working on.

By becoming strategic developer we also plan to be involved more in how Eclipse IP and Development process works and evolves. Something that become more important to make more effective for fast moving projects to feel better at home at Eclipse.

On top of that Eclipse have a lot of other areas going on which Red Hat are keeping our eye on - especially in the area of web IDE’s and Internet-of-things.

If you are interested in hearing more about this or have a suggestion please feel free to contact me by mail or leave a comment below!

Let’s Have fun!,
Max Rydahl Andersen
@maxandersen

JBoss Tools and Eclipse Linux Tools team members from Red Hat are currently busy working on Docker tooling for Eclipse and even though the code is not public yet (more details on that at the end of this blog entry), I thought it would be interesting to share our progress on the project.

Since this blog was published binary builds are now at http://download.eclipse.org/linuxtools/updates-docker-nightly/ and code is available from git.eclipse.org and mirrored on github.

The Docker tooling is aimed at providing at minimum the same basic level features as the command-line interface, but also provide some advantages by having access to a full fledged UI.

Docker Explorer

The Docker Explorer provides a wizard to establish a new connection to a Docker daemon. This wizard can detect default settings if the user’s machine runs Docker natively or in a VM using Boot2Docker. Both Unix sockets on Linux machines and the REST API on other OSes are detected and supported. The wizard also allows remote connections using custom settings.

Connection wizard

The Docker Explorer itself is a tree view that handles multiple connections and provides users with quick overview of the existing images and containers.

Docker Explorer view

Built-in filters can show/hide intermediate and 'dangling' images as well as stopped containers.

Managing Docker Images

The Docker Images view lists all images in the Docker host selected in the Docker Explorer view. This view allows user to manage images, including:

  • Pulling images from the Docker Hub Registry (other registries will be supported as well)

  • Uploading images to the Docker Hub Registry

  • Building images from a Dockerfile

  • Creating a container from an image

Docker Images view

A wizard lets the user input all the arguments to create a new container from an image. When the container is started, all the logs can be streamed into the Eclipse Console:

Docker Images view

Managing Docker Containers

The Docker Containers view lets the user manage her containers. The view toolbar provides commands to start, stop, pause, unpause, display the logs and kill containers.

Docker Containers view

This view also provides a filter to show/hide stopped containers. Users can also attach an Eclipse console to a running Docker container to follow the logs and use the STDIN to interact with it.

Info and Inspect on Images and Containers

We also integrate with the Eclipse Properties view to provide users with info and 'inspect' data about a selected container or image.

Properties view

Where is the code ?

Roland Grunberg and Jeff Johnston from Red Hat started this project and are currently in the process of getting the code accepted to Eclipse.org as part of the Linux Tools project (even if the tooling also runs on other platforms), which explains why the code has not been made public yet.

Taking about code, we rely on the open source Docker client developed by Spotify to handle the low-level communication with the Docker daemons and I should thank the Spotify developers who maintain this library. They’ve been very kind to quickly review and merge the pull requests that we’ve submitted and it’s been a pleasure to contribute to their project. Open source collaboration FTW :-)

What’s next ?

There is still some work and the screenshots showed above may still evolve as we add more features, but we hope that this blog entry will give you a taste of what’s coming soon in Eclipse with regards to Docker tooling.

While the code will be hosted in Linux Tools project at Eclipse.org, we intend to also ship it as part of JBoss Developer Studio 9 and JBoss Tools 4.3 later this year.

We also created a JIRA component to track this work-in-progress in the scope of JBoss Tools, including some issues with mockups.

Beyond this basic Docker tooling we are looking at integrating launching servers and even native CDT builds on docker containers, but this will be the subject of future posts on this blog ;-)

As usual, feel free to provide us with feedback on our forum, on JIRA or on IRC. Questions, comments and suggestions are always welcome!

Stay tuned!

/Xavier
@xcoulon

Even back when the first line of code was dropped for Hybrid Mobile tooling, making the tools as part of the Eclipse foundation was a goal. When starting, we looked at the available tools for developing Cordova applications. We found out that there were no open source solutions that we could contribute and use as part of our tools. Furthermore, interoperability among what very little existed was poor. Of course, our main goal is creating good tools for Apache Cordova development, but while doing that we always keep an eye on interoperability and extendibility.

It is only natural that we are moving the development of our tools for Cordova based application development and forming the Eclipse THyM project. We hope that, as a vendor neutral non-profit organization, Eclipse foundation will encourage contributions and be the base for interoperable Cordova tooling.

What is contributed

Everything related to Cordova based development including the project management, plugin discovery, and support for iOS and Android excluding the Cordova simulator is contributed to Eclipse.org. We have excluded CordovaSim for now because of its complex set of dependencies

What is changing

The development will continue to happen on GitHub but on a repository owned by Eclipse foundation. The contributed code is already renamed, cleaned and on the new repository. If you are a contributor, or want to be one, please use https://github.com/eclipse/thym

We will use bugzilla, and thym-dev mailing list from now on as provided by Eclipse foundation. As expected project documentation is at the wiki. The builds will be running on eclipse.org build server instance.

What is NOT changing

JBoss tools will continue to have support for Cordova development. We will consume Thym project and extend them with more capabilities and integrate with other parts of the tools and technologies coming from projects such as Aerogear.

And of course our wish to create good tools for Apache Cordova development continues with a hope for better collaboration with other individuals and companies.

Looking for older posts ? See the Archived entries.
back to top