Tuesday, August 12, 2014

Highlighting Breakpoints Like in Zend Studio 5.5

Looking at the feedback we receive, it seems that lots of our long-time users feel nostalgic to the pre-Eclipse era of Zend Studio. Here is one hint how you can bring the look and feel of the latest Zend Studio a little bit closer to the one experienced with the legendary Zend Studio 5.5.

In Zend Studio 5.5 when adding a breakpoint the complete line was highlighted in pink color. In later releases of Zend Studio this was replaced by the usual way of the Eclipse Platform - a blue bullet appears in the marker area on the left side of the editor's line.

Luckily, this can be configured in the same way it was in Zend Studio 5.5, following these steps:

  1. Call Window > Preferences from the main menu.
  2. Navigate to the General > Editors > Text Editors > Annotations preference page.
  3. Select "Breakpoints" in the list of annotation types.
  4. Select the "Text as" checkbox.
  5. Select "Highlighted" from the drop-down list.
  6. Change the color to #FFC0CB.
  7. (Optional) If you want to remove the blue bullet then deselect the "Vertical ruler" checkbox.
  8. Click the OK button.

Note. You need to upgrade to the latest Zend Studio 11.0.1 Early Access build or wait for the official 11.0.1 release (due in a week) to take advantage of this hint. There was a bug in the PHP editor that prevented breakpoint highlighting in previous releases.

Tuesday, July 8, 2014

Coding Like a Pro

When switching to an Eclipse-based IDE like Zend Studio, some developers become annoyed by the help they are provided in the code editors. Auto closing of braces, parentheses, tags and the like is helpful for beginners and advanced developers who got used to this feature. But for those migrating from tools where they used to have the full control in the editor, this is nothing but a hurdle.

Fortunately, you can switch this off. As you may guess it is hidden in the ocean of preferences. The easiest way to find it is to enter "typing" in the filter field of the Preferences dialog.

As you can see on the above image this filtering gives you the necessary pages where you need to go and deselect the desired checkboxes for the PHP editor, the JavaScript editor and so on in order to customize your typing experience in the IDE.

Saturday, December 21, 2013

Eclipse for PHP Developers is Back

After a few years pause the Eclipse for PHP Developers package is back with the Luna M4 milestone of the Eclipse Simultaneous Release.

The package assembles the PHP Development Tools (PDT), the JavaScript Development Tools (JSDT), HTML, CSS and XML editors, and productivity tools like EGit and Mylyn. It is one of the easiest way to start using PDT for developing PHP applications.

The package can be downloaded from the Developer Builds section on the Eclipse Downloads page: http://eclipse.org/downloads/index-developer.php

Friday, August 9, 2013

Comparing feature.xml Files With XMLUnit

Recently, I worked on a releng tool that compares two build results of an Eclipse-based product and reports the differences. Depending on how the build is modelled, there are metadata files, which content changes with each build, e.g. version timestamps in feature.xml. In order to avoid polluting the report with such changes, I wanted to filter them.

So, I needed a way to compare feature.xml files, but yet ignoring differences found in some xml attributes like "version", "download-size" and "install-size". Luckily, I stumbled upon XMLUnit, which saved me lots of efforts.

XMLUnit was designed as a helper for asserting test results for code that produces XML output. But it's also turns to be a great helper for any use case that involves comparison of XML data.

Comparing two XML files is as easy as creating a new Diff object and calling any of the two test methods: identical() and similar(). In my case, similar() worked better.

The above snippet compares the XML files, but it does not ignore the attributes I am not interested of. Customizing the comparison mechanism of XMLUnit is very easy by overriding the so called DifferenceListener with own implementation.

In my own implementation I simply check if the found difference is related to any of the three attributes I want to ignore. If this is the case then I simply tell XMLUnit to treat these difference as "similar".

And this is everything you need to get the job done.

Monday, July 15, 2013

Moving Forward

After more than 12 years working for SAP, it was time for a change. I decided to refresh my professional life and joined the Zend Studio team.

All these years at SAP will remain a cornerstone in my professional career. I built myself as a software engineering. I worked on exciting projects together with so many great colleagues in the lab in Sofia, in the headquarters in Walldorf, and across the globe. I engaged with the Eclipse open source community.

My participation in the Eclipse community was perhaps the most romantic part during that time. I am extremely happy that in my new job I will continue being part and contributing to the community.

After two months working for Zend Technologies, I can say that this was the right move for me. I am now having the environment I wished for some time: smaller company, less processes, less politics, faster decision making, ROWE, telecommuting, shared office space, using modern and friendlier tools... In short: more freedom.

Thursday, October 25, 2012

Committer Access to Eclipse.org Git Repositories behind a Proxy

There are lots of Eclipse committers that are employed by corporations and spend their day in an office protected with strong security measures. In other words they work behind a corporate proxy and have not direct access to Internet, which makes it hard using some network protocols on their usual ports, like SSH on port 22.

These committers have three alternatives for committer access to git.eclipse.org:
  1. Find a pubic WiFi or 3G network and temporarily switch to it. This is not always possible: requires WiFi / 3G adapter and available network, and not really convenient: requires to switch network adapters and proxy settings. 
  2. Request the Eclipse webmasters to provide HTTPS access to the respective Git repository. HTTPS works very well behind corporate proxies. Unfortunately it is not enabled by default for Eclipse.org Git repositories and the webmasters have their security concerns for doing this. 
  3. Try the good old proxy.eclipse.org as we know it from the CVS Howto guide. If it worked for you for accessing the CVS repositories then it should work also for the Git repositories. This is a nice workaround - it tunnels the SSH protocol from proxy.eclipse.org:443 to git.eclipse.org:22. If the configuration of your corporate proxy is not absolutely paranoic then you should be able to take advantage of this option. Here is an example screenshot of EGit configured to clone the Eclipse Libra website repository:

Happy gitting!

Monday, August 27, 2012

Changing the Context Root of Web Applications

This article was originally posted in the SAP Community Network. I post it here with few changes that generalize it for all Eclipse WTP users.

Soon after the first steps in developing web applications with Eclipse WTP, developers often realize that the default context root of their applications is not exactly what they want. By default, the context root goes after the project name - if the name of your project is "HelloWorld" then it will be deployed with context root "/HelloWorld".

Changing the context root is a piece of cake. In this post we will see how you can do this in Eclipse WTP.

Setting the context root when creating a new web project

As described in the Web Tools Platform User Guide, when creating a new web application, you typically use the "New Dynamic Web Project" wizard. Instead of finishing it on the first wizard page, you should click on the Next button to advance to the "Web Module" wizard page. There you can set the context root of the application by modifying the value in the "Context root" text field. If you wish to deploy the application in the server's root then simply give "/" as context root.

Changing the context root of an existing web project

To change the context root of a web application that is already available in the Eclipse workspace, simply right-click on the web project and call the "Properties" action from the context menu. Then navigate to the "Web Project Settings" property page and you will find the text field where you can change the context root.

Depending on the server adapter you use, if your application is already deployed and started then you may need to redeploy it or restart it for the change to take effect.