Continuing our series about new inspectIT 1.6 features, we want to present you today a new approach for developers which we introduced to setup their development environments.

In the past, developing for open source projects always involved some challenges. One of those challenges is that every project has its own guideline on how to structure the code, which frameworks and tools are used, how dependencies are managed and the build is executed and possibly many more. Such definitions could create a rather high hurdle especially for externals of the project to submit some fixes or even a new feature. We at inspectIT always try to improve on this topic to allow this to be as painless as possible. And coming from a documentation describing on what tools to download, which plugins to install, some configurations to be imported manually at the end and many more steps in total, we identified that there has to be a better way to accomplish this goal (not only because of efficiency but also because it was not clear for every developer on what must be done if an update to this documentation has been performed).

Workspace Mechanic: the solution?

In another customer project in the company we established the usage of workspace mechanic some years ago, an eclipse plugin which synchronizes preferences over different development environments. This includes already definitions of code formatters, templates and all the other stuff that are stored directly in the preferences. Back then it was a good choice as we distributed the whole IDE in a virtual machine and developers only had to accept incoming changes from workspace mechanic and thus were always up to date. For inspectIT on the other hand, this would not solve the whole “problem” we have: which IDE + plugins to install, other dependencies we have to the system (like an existing JDK 1.5 for developing on the Agent) and some other stuff.

What about other alternatives?

As workspace mechanic was not fulfilling our requirements completely, we were looking for other tools and approaches and we found 3 of interest: Vagrant, Yatta and Oomph.

Vagrant would be our choice if it just comes down to internal project developers as it will not only set up e.g. Eclipse but also the whole operating system as it is basically a virtual machine running in VMWare. Even though it is pretty easy to get such a development environment via:

It just feels too much of an overhead to have every possible developer install Vagrant and run a virtual machine on their machines just to submit something to inspectIT.

Yatta and Oomph on the other hand are going in a different direction: Use the operating system you have but automate everything around Eclipse itself. By comparing those two, the biggest difference is on how you get profiles and where they are stored. Yatta requires you to have a registered user to access these profiles which are stored centrally on their server. Oomph just needs a so called setup file which could be located anywhere (be it on a local machine, online in the source repository itself or in any other place you would like to have this available).

Oomph to the rescue!

Thus the final decision for now was pretty easy for us: Oomph! And before writing any further, look up the correct pronunciation. I really don’t understand why one could choose such a word for this tool, but I guess you just have to live with that :-).

Now, how does it look like to get the development environment for inspectIT up and running? Just some very few steps need to be executed which I want to show here:

1. Download Oomph Eclipse installer

For sure, you need to have the tool itself available. Just jump over to their official website and download the one fitting for your operating system.

2. Start Oomph and switch to the Advanced Mode

Next step is again pretty obvious: Start the tool. You will be presented with default products which you could also download through the official Eclipse site but now within this installer. There is a very good reason for not downloading anymore through the official Eclipse site and just use this tool for all of your Eclipse installations: instead of downloading everything over and over again, a shared p2 repository containing all the needed plugins is created and thus subsequent installations will reuse these already downloaded artifacts. This allows creations of new Eclipse installations (be it e.g. for testing purposes) sometimes a matter of seconds in the end. A very cool feature in my opinion!

After starting the tool, just head over to the options (the button in the top right) and go to the advanced mode:

oomph-advanced-mode

This allows us to define – on top of the default products – some further configurations.

3. Select Product

In the advanced view, you can now select the appropriate product you want to download. For inspectIT, it is Eclipse for RCP and RAP Developers in the version Neon:

neon

4. Add inspectIT configuration

In the next screen, just press the green plus button on the top right of the window and enter the following GitHub URL:

As you can see, the setup file is located in our own GitHub repository and thus synchronizes with the current state of the whole application. If we go for new plugins or changes in this configuration, you could just reinstall and be ready again in a matter of seconds.

oomph-project-selection

5. Change some Variables

As the very last step, just modify the shown variables to your liking. For instance you can change your name so that the templates reflect this in creation of new classes. After you’re finished here, just go on and finish the setup process.

Really finished?

Yes, you are :-). As you can see now for yourself, all the needed artifacts for Eclipse are downloaded automatically, plugins are installed, inspectIT source code is retrieved, preferences are set and projects are imported to a working set. PMD, Checkstyle, FindBugs, all the plugins which usually take some time to setup correctly and make them work as you want are just there and already validating your new code.

For me, Oomph is a really great tool. Not only because it helps us now with inspectIT directly, but also that I can easily create a new Eclipse instance basically on the fly without worrying about that they interfere with each other. I can only recommend this to everyone who is actively using Eclipse on a day-by-day basis!

If you want to know more technical details about how to create this specific setup files, let me know! I might create another blog post which goes into details about this!

And don’t forget to head over to our new and fancy inspectIT homepage and download the latest version with all the cool features. You’ll love it!

— Patrice

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close