Enable the CSS3 Profile in Eclipse

Eclipse has a rich and powerful CSS editor. It provides the expected features like syntax highlighting, content assist and outline. If you have already tried it and you are already on CSS3, you may have noticed that the content assist misses the new CSS3 properties. It looks like the Eclipse CSS editor has somehow stuck on CSS2. But it is not really. The support for CSS3 is there, but ... guess what ... not enabled by default.

Here is how you can enabled the CSS3 features:

1. Right-click on a CSS file and call the Properties dialog.
2. Open the Web Content Settings page.
3. There you will find a field CSS Profile set to "none".
4. Change the CSS Profile value to "CSS3: Cascading Style Sheets, level 3".
5. Click the OK button.

Now, try again the content assist in the CSS editor. It will suggest also the CSS3 properties like "border-radius".

This is how to change the CSS profile per file. It is also possible to change it per project using the same steps on the project's Properties page. But it only works if the project is a Dynamic Web Project or a Static Web Project one. The Web Content Settings page is not available for other project types like PHP projects. It is also not available as a workspace-wide preference. So, for the majority of project types it is only possible to change the CSS profile per file.

The good news is that with Neon M6 the default CSS profile becomes CSS3. See bug 438283. So, the above steps won't be necessary in the near future and users will see the CSS3 features off the shelf.

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. 

STS 3.0 and SAP NetWeaver Cloud

This article was originally posted in the SAP Community Network. 

One of the interesting news this week is the release of the Spring Tool Suite 3.0.0. In addition to the new features, the highlight is that the complete project is now available as open source software on GitHub under the Eclipse Public License. This is really great news for the Eclipse community! More details about this move can be found on the SpringSource Blog.

After reading this news, I was thrilled to try developing a Spring application with STS 3.0 and deploying it on my trial account in SAP NetWeaver Cloud. I went to the STS download site, grabbed a package and installed it. Then I followed the usual steps for installing the Eclipse Tools for SAP NetWeaver Cloud on top of STS. Since STS 3.0 is based on Eclipse 4.2, the Eclipse Tools for SAP NetWeaver Cloud must be installed from the Juno update site: https://tools.netweaver.ondemand.com/juno.

STS comes with a nice dashboard that brings you up to speed with the Spring technology. Luckily there is a nice example project "spring-mvc-showcase" that demonstrates the capabilities of the Spring MVC web framework through small, simple examples. Just a single click and the project was fetched from GitHub and installed in my Eclipse workspace.

The Maven Integration for Eclipse resolved all required libraries and the project was ready to deploy. I quickly got a functional Spring application, so I will skip any real Spring development for now.

Deploying it on the SAP NetWeaver Cloud required a few more clicks. I just called the "Run on Server" action from the project's context menu and deployed it successfully on the Local Test Server and on my trial account in SAP NetWeaver Cloud.

Trying out Spring with SAP NetWeaver Cloud was a really easy win for me!

Bundle Dependency Graph moved from Virgo to Libra

Those of you who are familiar with the Virgo Tooling know about the rich tools in the Virgo server editor. It consists of editor parts like:

• The Bundle Repository that allow easy installation of bundles from the SpringSource EBR into the OSGi framework.
• The Bundle Overview that lists all bundles installed in the OSGi framework with their states, attributes, imported and exported packages and services, etc.
• The Bundle Dependency Graph that visualizes the dependencies between the bundles as a graph.
• The Server Console that allows executing shell commands in the OSGi framework (somewhat duplicating the standard Eclipse Console). 

The good news today is that three of these editor parts - Bundle Overview, Bundle Dependency Graph and Server Console - are now released from their Virgo dependencies and moved to the Libra project, which allows using these tools with any OSGi framework as well as integrating them in adopter's server adapters for OSGi-based application servers.

This move has been done in the timeframe of Juno M3 that will be officially released on November 11, 2011. From this date on, this new Libra feature will be able to be installed from the Juno Discovery Site. Until then, those who are eager to try it out now, can do this from the Libra Nightly repository.

The new feature is called "OSGi Framework Editor". However, if you want to try it with the Libra server adapters for the open-source OSGi frameworks (like Equinox, Felix, etc.) you will need to install also the "OSGi Framework Launchers" feature. Watch these great video tutorials for an introduction to these server adapters.

The Bundle Overview and the Bundle Dependency Graph editor parts retrieve the bundle information from the OSGi framework via JMX. Therefore, make sure you configure JMX correctly by following the user guide.

In case you like these tools and you want to integrate them in your own server adapter, then take a look at the comprehensive adopter guide that explains how to do this.

So, that's all folks for Juno M3. I plan making some enhancements for the next Juno milestones. My hope is that these editor parts become a useful tool for analyzing the state and the dependencies of  OSGi bundles.

Another sign in the Eclipse Zodiac

The Eclipse Zodiac expands with one more sign. The Libra project arises next to the Gemini and Virgo runtime projects. This time it is about a project that will provide tools for the OSGi Enterprise specification, like development of Web Application Bundles and Persistent Bundles.

The Libra project has just passed successfully the Creation Review and is now being provisioned. The best source of information for the moment is the proposal document as well as the discussions in the forum.

Some of the initial committers are already preparing their initial contributions, so stay tuned for announcement about the first features delivered to the community. The new project will be also presented at EclipseCon 2011: Libra - New Tools at Eclipse for OSGi Enterprise Development

JPA Diagram Editor 0.5 RC2 released

The JPA Diagram Editor project has just published the next release candidate - 0.5 RC2. This milestone build requires Graphiti 0.7.0 RC1. Check the project's wiki page for installation instructions.

This RC comes with a significant list of bugs fixed. There are still some more left. So we are going to have one more RC in the next weeks and then we will officially release version 0.5, which will be compatible with Helios and Graphiti 0.7.

I'd like to thank my colleagues Stefan and Petya for their great job in driving the project. Kudos go also to Ram, Tuukka and Alex for the great bugs they have reported.

By the way, we have set up a Hudson build, so everybody can have an early look at the bug fixes we commit to CVS. More info: http://wiki.eclipse.org/JPA_Diagram_Editor_Project#Build_Infrastructure

And, by the way, the JPA Diagram Editor will be presented at the Eclipse Summit Europe 2010 :-)

Stay tuned!

JPA Diagram Editor first milestone released

I am happy to announce that the JPA Diagram Editor project made its first milestone release - 0.5 RC1. Just follow the installation instructions, posted on the project's wiki, and you are ready to build your JPA model in a diagram. There is a nice Getting Started tutorial to help your first steps. If you want to take a quick look before installing, then check our demo on YouTube.



The JPA Diagram Editor is a new incubating project in the WTP Incubator. The project is initiated by SAP and aims to contribute the existing JPA Diagram Editor from the SAP NetWeaver Developer Studio, and continue its future development in the Eclipse community. This contribution is based on the Graphiti project - the new graphics modeling infrastructure in Eclipse.

The official 0.5 version of the project will provide a stable release of the initial contribution. Due to the migration to Graphiti, there are some bugs to be cleaned and we are actively working on them. Nevertheless, we decided to release early to hear your feedback sooner. If you eventually find a bug, then please report it in the WTP Incubator Bugzilla (use component wtp.inc.jpaeditor). You can check the list of already reported bugs if that bug has already been found - we are actively testing at the moment.

Please, note that currently the JPA Diagram Editor supports only JPA 1.0 projects. This mean that you will not see the "Open Diagram" action in the context menu of JPA 2.0 projects. JPA 2.0 support is definitely on our radar screen. We will start working on it after releasing the stable 0.5 version.

Any feedback is very welcome. Especially with suggestions how to evolve the project in the future months. We are available on the WTP Incubator Forum and wtp-incubator-dev@eclipse.org mailing list.

Call for screenshots

I have mentioned earlier that the Eclipse WTP project is taking steps on improving the default layout of the Java EE perspective. We made an UI walkthrough in the Eclipse UI Best Practices group and reached consensus for some small, but valuable, things to improve. We have scheduled this small step for Galileo M3.

Before we continue the discussions on the topic, we would like to look inside the development environment of WTP users. We have some statistics from the Usage Data Collector, but it is invaluable to see how Java EE developers compose the different views in an effective and convenient perspective. We are sure that everybody has its own favourite layout depending on the screen resolution and the working style.

We will be happy if you take some minutes to submit a screenshot of your IDE on the designated wiki page.

Plans for changes in the Java EE perspective

The Java EE perspective hasn't changed much in the last years. There were only minor tweaks that surely make the things better, but nothing special yet.

Recently a discussion started on how to update the default layout in the Java EE perspective. The first suggestions came from Mik Kersten. They are related about better integration with the Mylyn project. This includes:

• adding the Task List view


• replacing the old Problems and Tasks views with the brand new Markers view

This started tickle my mind. I have an old usability problem with server management in the Java EE perspective. When I use an application server that produces logs in the standard output (like all open source servers), whenever I execute a start, stop or deploy operation, the Console view suddenly pops up and pours tons of logs on the screen. It nice to have a view on the logs, but this hides the Servers view where I can see what's happening at a glance. In such situation I always decide to change the docking location for either the Servers view or the Console view.

So, why don't we just change the default docking location of the Servers view? I find it very comfortable on the left-bottom side - under the Project Explorer view. This way I can see both the server status and the console output without any tab switching. Another benefit is that both views, which deal with projects, are on one and the same side and I can easierly drag-and-drop a project on a server instance.

Here is how the new Java EE perspective layout would look like:


Other thoughts that cross my mind are:

• why do we have the Data Source Explorer view by default?


• isn't it better to have the Snippets view docked on the right next to the Outline view rather than at the bottom?

If you have any wishes that the Java EE perspective should meet, feel free to comment in the Eclipse Bugzilla where the discussion currently happens. The community feedback is the best guarantee that we will come to great ideas!