New Eclipse Chain Completion Improvements and Hippie Privacy Settings

by Simon Laffoy at February 26, 2015 09:15 AM

Codetrails has just released Eclipse Recommenders 2.1.12 and Codetrails Connect 1.3.0. So what’s new? Let’s have a look ...


by Simon Laffoy at February 26, 2015 09:15 AM

Eclipse N!

by waynebeaton at February 26, 2015 04:29 AM

The Eclipse Planning Council—with help from the community—is trying to sort out the name for our eleventh named simultaneous release in 2016. We had some trouble with the first set of names that we selected, and so we’re into the second round.

The Lynn Lobby has significant momentum.

The “Eclipse Lynn” Lobby has significant momentum.

We started following the alphabet a few years ago, naming our fifth release “Helios“, and now we’re up to the letter N. We’ve been bouncing around some N names on Twitter; I quite like the idea of just going with “N”, and stated as much.

I originally put in the exclamation mark to make it seem more exciting, but then it occurred to me that the exclamation mark has special meaning in Lisp. In a functional programming language like Lisp, you generally avoid changing state, so Lisp functions that make changes are marked with a cautionary exclamation point (spoken as “bang”). When you invoke a bang function, things are going to change:

It seems appropriate. Change is in the air. I’m excited by the prospect of having an actual installer. I’m excited by our vision of the future of the developer’s platform.

With Mars, our June 2015 release, we’re making a subtle shift to put more focus on the user experience. This takes the form of our Every Detail Matters for Mars effort which aims to tackle a handful of “little things” like getting more of the default preferences right in our packages, standardizing naming conventions, providing reasonable and useful package-specific new and noteworthy documentation, improving the story for adding simultaneous release plug-ins into an Eclipse-based IDE, and more. I’m pretty excited about some bits of the “and more” part, but I’ll save that discussion for another day.

Of course, we’re also trying to tackle some pretty big things. We’ve come a long way towards having a proper installer for Eclipse. I’m also optimistic that we’ll be including Gradle support in Eclipse (more on this later).

We need your help and so we’ve started the Great Fixes for Mars skills competition. To enter, all you need to do is take responsibility for a bug, mark it as “greatfix”, and submit a patch. We’ve even provided a list of great suggestions where you can make the biggest impact. There’s prizes. Cool prizes.

Enter the Great Fixes for Mars skills competition; there'll be prizes!

Enter the Great Fixes for Mars skills competition; there’ll be prizes!

This shift in momentum will build through Mars and into the 2016 release. I’m certain that N-bang will usher in even bigger changes.

But what do I know? I’m just an Old Dude Who Knows Smalltalk (and Lisp).

EclipseCon 2015



by waynebeaton at February 26, 2015 04:29 AM

You can Fork & Clone a Repo from Fork Visualisation View

by Its_Me_Malai (noreply@blogger.com) at February 26, 2015 12:24 AM

Having added the functionality of visualising Repositories that are online thru Fork Visualisation View, the next usecase was allowing them to the forked into our login and also clone into our eclipse git perspective.

We have now fixed this requirement. You may Fork a Repository from the Fork Visualisation View to your login and also clone it to add to your Git Repositories.

Screenshots as shown below

A new button is available on the Action Bar of the View. Select the repo that you want to Fork and click on this Fork and Clone action.



On successful Forking, this message would he sbown asking for Clone Confirmation. If clicked on YES, it opens the Clone dialog with the required URL filled as it is done on Paste in Git Repositories view.


It is available for download from MarketPlace : http://marketplace.eclipse.org/content/github-extensions
Code is available on https://github.com/ANCIT/eGit-extensions

Enjoyin Eclipsing until we meet next time.

Regards
Malai

by Its_Me_Malai (noreply@blogger.com) at February 26, 2015 12:24 AM

Announcing J2V8 2.0

by Ian Bull at February 25, 2015 06:18 PM

Last year I announced J2V8, a new JavaScript engine for Java that wraps V8 with a set of Java Bindings. We have been using this technology to power Tabris.js on Android — giving us much better performance than Rhino could. While J2V8 was very stable, it wasn’t very easy to consume. Today I’m happy to announce that J2V8 2.0 has shipped, and it’s much easier to embed in your Java Applications.

There are several notable improvements in J2V8 2.0:

Self Loading Native Libraries

Following the lead of SWT from years ago, we have included a Library Loader that will load the native library automatically for you. You no longer need to twiddle with the java.library.path to get J2V8 to work. This also works on Android.

Bundled Native Libraries

The native libraries have also been bundled with the Jar file. Currently we are shipping 5 different Jar files for J2V8:

The final one (j2v8_android.jar) contains the native library for both armv7l and x86, so you can use it on several different Android devices. By adding the jar to your classpath and calling V8 runtime = V8.createV8Runtime(); (V8.createV8Runtime(null, activity.getApplicationInfo().dataDir); on Android: because you need to specify the location to unpack the native library) the native library will be automatically loaded for you. We can add more platforms, but each one takes time as I need to build V8 on the platform first. Any particular platform I should target next?

Available in Maven Central

J2V8 is now available in Maven Central. You no longer need to build the library yourself. For example, add the following snippet to your pom.xml to use J2V8 on MacOS:

<dependency>
  <groupId>com.eclipsesource.j2v8</groupId>
  <artifactId>j2v8_macosx_x86_64</artifactId>
  <version>2.0</version>
</dependency>

Hello, World

Once you’ve added the the dependency to your pom.xml, you can begin embedding JavaScript in your Java Application using J2V8. Here is a simple Hello, World! that demonstrates how to call JavaScript from Java and register a callback.

package com.example;
import com.eclipsesource.v8.V8;
public class Hello {
	public void print(String s) {
		System.out.println(s);
	}
	public void start() {
		V8 v8 = V8.createV8Runtime();
		v8.registerJavaMethod(this, "print", "print", 
                                      new Class<?>[] { String.class });
		v8.executeVoidScript("print('Hello, World!');");
	}
	public static void main(String[] args) {
		new Hello().start();
	}
}

Screen Shot 2015 02 25 at 9.56.47 AM Announcing J2V8 2.0

More Information

I will presenting J2V8 at EclipseCon in San Fransisco on Thursday March 12th. Stop by and say hi if you’re in the area.

Finally, if you want to try it on Android without embedding it into your own Java application, request an invite to Tabris.js.


TwitterGoogle+LinkedInFacebook

Leave a Comment


by Ian Bull at February 25, 2015 06:18 PM

Release Engineering special issue now available

by Kim Moir (noreply@blogger.com) at February 25, 2015 03:26 PM

The release engineering special issue of IEEE software was published yesterday.  This issue focuses on the current state of release engineering, from both an industry and research perspective. Lots of exciting work happening in this field!

I'm interviewed in the roundtable article on the future of release engineering, along with Chuck Rossi of Facebook and Boris Debic of Google.  Interesting discussions on the current state of release engineering at organizations that scale large number of builds and tests, and release frequently.  As well,  the challenges with mobile releases versus web deployments are discussed. And finally, a discussion of how to find good release engineers, and what the future may hold.

Thanks to the other guest editors on this issue -  Stephany Bellomo, Tamara Marshall-Klein, Bram Adams, Foutse Khomh and Christian Bird - for all their hard work that make this happen!


As an aside, when I opened the issue, the image on the front cover made me laugh.  It's reminiscent of the cover on a mid-century science fiction anthology.  I showed Mr. Releng and he said "Robot birds? That is EXACTLY how I pictured working in releng."  Maybe it's meant to represent that we let software fly free.  In any case, I must go back to tending the flock of robotic avian overlords.

by Kim Moir (noreply@blogger.com) at February 25, 2015 03:26 PM

Eclipse Scout Roadmap 2016

by Matthias Zimmermann at February 24, 2015 09:19 PM

For the 2016 release of the Scout framework we will introduce two significant changes. These changes address major pain points we have suffered from in the past. As the scope of the two changes is substantially larger than in previous releases, we would like to start talking about them well ahead of time. So remember in the text below that this is a blog about the future of Eclipse Scout scheduled for 2016, not about the upcoming Mars release.

The first change is driven by our vision of the future of UI technologies for business applications. The second change addresses the need of our customers and BSI that Scout applications should be easy to integrate in a Java EE or Spring based environment. In the text below we will discuss these two changes individually.

A new HTML5 Renderer

The first change is based on our belief that the future of business applications mostly lies in the domain of web applications. In consequence, Eclipse Scout needs to provide the best possible web experience for the users of Scout applications. And to achieve this goal for the 2016 release, we already have started to write a new Scout web rendering engine, directly based on HTML5/CSS3 standards. Thanks to this substantial investment of BSI, Scout applications will comply with the new de-facto standard for web applications and will be able to take advantage of the latest web technologies in the future.

This decision also implies that future Scout web applications are no longer based on the Eclipse RAP project. At the same time, discussing this topic extensively with our customers, we found that their demand for the existing Swing and SWT rendering components no longer matches the necessary expenses to maintain these components. This is why we decided to discontinue the Scout SWT and Swing desktop rendering components after the Eclipse Mars release.

Eclipse Scout will become a Java framework

The second change affects the foundation of Eclipse Scout applications. Currently, Eclipse Scout applications are based on OSGi and the Eclipse runtime platform. In the past, we have addressed the challenge to integrate a plugin based application with Java EE technologies again and again. And according to some Scout customers, integrating the plugin based Scout server with Spring technology did cost them significantly more time than anticipated.

Observing the market and the need of our customers over the past years, we have come to the conclusion that Scout’s dependencies to OSGi/Eclipse platform did bring more harm than good to Scout projects. This is why we now started to implement replacements for familiar Eclipse concepts such as jobs, extension points and services.

As a result of this second change, Eclipse Scout applications will become standard Java applications that will seamlessly integrate with Java EE technologies and other Java frameworks, such as Spring. We also hope that this change will increase the adoption of Eclipse Scout in the Java domain.

What will stay the same?

Although the changes mentioned above may seem substantial, it is important to keep in mind that most aspects of the Eclipse Scout framework remain the same.

  • Scout will continue to be an Eclipse Open Source project.
  • The Scout SDK will continue to be based on the Eclipse IDE.
  • The existing Scout application model will (mostly) stay as it is.
  • Migration efforts for existing Scout applications will remain rather modest (with the exception of the rendering part for your custom controls, if any).
  • From the Scout developer perspective these changes will probably not feel exciting. But this is by design.
  • And to avoid confusion: The Scout Mars release will still be shipped with the known RAP, SWT, and Swing rendering components.

Your Feedback?

Whether you like these changes or are concerned regarding your plans for Eclipse Scout please let us know. Please contact us on the Scout forum. For discussions we have created separate topics. One for the new HTML renderer and another one for removing the Eclipse/OSGi dependencies.

If you prefer a less public channel for discussing these changes you can contact us by email to scout@bsiag.com. Your feedback is very valuable to us and we would like to find/discuss options if you have any concerns or questions.

More Blog Posts to come

  • History of Scout and its supported technologies
  • Current state of the new HTML5 rendering component
  • Progress reports on becoming a Java framework

Scout Links

Project Home, Forum, Wiki, Twitter


by Matthias Zimmermann at February 24, 2015 09:19 PM

Let's put Orion into Context !

by Eric Moffatt (noreply@blogger.com) at February 24, 2015 09:05 PM

OK, try 2 (for those that noticed my earlier, empty, post...;-).

A small aside to start:

I've recently joined the Eclipse Orion team; after >10 years on the eclipse platform it was time for a change. Working on the eclipse UI was easily the highlight of my career so far. The opportunity to work with many truly exceptional people in such an energetic ecosystem made the work even more rewarding. While I missed out on EclipseCon this year I *will* find my way to at least one more so that I can properly thank (in person...with Beer !) at least some of the crew that has been instrumental in moving eclipse forward over the years; far too many to name individually...you know who you are..and thanks !!

Now on to the future and Orion...

It took me literally no time at all to realize that Orion needed some tooling work. Immediately upon my first attempt to work on some JS code I realized that the tooling that made me look effective in JDT just didn't exist. I was reduced to regex searches and the like to wend my way through the maze of JS / CSS / HTML files comprising Orion. This made going up the learning curve for the codebase seem more like climbing a mountain of molasses. Something had to be done...

...and has ! Take a look at the Orion 8 N&N to see the new tooling in Orion 8 and for those lucky enough to be at EclipseCon don't miss Simon Kaegi's talk: "JavaScript Language Tools. In Orion.". These are just the first fruit of the efforts to make the Orion editor more that just a fancy notepad, more are on the way.

Since the new functionality has already been announced  this post will look more closely at where we're going with the tooling. It's worth noting that all the Orion 8 feedback needed was a change in how the existing hover tooltip got its information and 'quick fix' commands (pretty good bang for the buck IMO).

It's all about the context

Most of the help from JDT comes from its crawling large statically analyzed parse trees(AST's). Since this is largely impossible in JavaScript what can we do ?

There are (loosely speaking) three different types of tooling feedback:

Information: Regular tooltip style giving JSDocs or showing a color when hovering over parts of a
file...

Manipulation: The is for feedback that allows the user to modify their files in some way (think quick fixes and, eventually, refactoring and color/font definition).

Navigation: This is the ability for the editor to recognize and locate files referenced from the one they're editing.

Of these three the one that is most important is 'Navigation'. One of the first problems we encountered was that the code is (of course) always written reflecting the directory structure of where it is *deployed* (i.e. where it lives on the server). In cases where anything but the 'null' deploy is used (the code is in the same structure for development as it is when deployed) we needed some sort of 'File Map' to allow us to properly locate the development file given a reference in a deployed file. This is currently available through the file navigation hovers in Orion 8 but this is just the beginning. It's more than just 'require' and 'import' but should also be capable of deeper introspection such as locating a specific CSS class used in a JS snippet that is assigning a class to a classlist (by searching the available CSS classes for that specific class name).

With the ability to navigate from 'required' references in one file to the actual JS (or 'imported' CSS files) we also gain the ability to walk dependencies looking for useful info to show the user (i.e. JSDoc content assist for methods declared in a required JS file...). As we become more proficient in parsing relevant info we will start to gain the ability to answer some of the trickier questions like "Where is this JS / CSS class used ?" and "Where is this method used ?" (needed for eventual refactoring).



Orion 9 and beyond


Here are some of the things we'll be focused on for future releases...

Type Inferencing

Due to its inherently mushy nature JavaScript is effectively tooling resistent. Our goal is to not
restrict what the developer wants to do but instead warn them if they're doing something that will
make the tooling ineffective. For example Orion uses RequireJS to access instances of various JS
services. The 'required' service instances are assigned to variables in the object doing the requiring. The tooling will work only if the code never assigns a different, unknown, value to this var. To help here the tooling will produce a warning should such an assignment be used (preventing us from doing content assist...on that var).

Note that can (and should) be generalized to account for new techniques to 'typify' JS. If we parse a 'type' (whether from JSDoc or some other type description) the underlying mechanisms will be common enough to show the warning any time a 'typed' var is assigned to regardless of how that type was originally specified (unless of course the value being assigned is of a matching type).

Deeper Context Introspection

It's the union of all the references within a web project that truly define its 'context'. Being able to infer as much as possible about the resources being used in a particular scenario is proportional to the tooling support we can provide. One of the possibilities we're looking at is the ability to specify the HTML doc we're doing our development in the context of. This would provide access to the specific CSS files used by that page (which may be different from those used on a different page), allowing us to provide more accurate feedback; in the end everything has some page at its root.

Since the tooling relies heavily on the file map we'll be making it simpler to create and maintain the map for your particular setup as well as providing this functionality 'in the UI' (i.e. allowing the user to define explicitly the file being referenced and having the UI remember this choice, some sort of support people writing the deploy scripts...). The goal here is to make this as simple (for you) as possible so that the advantages of having access to great tooling far outweigh the effort needed to provide the file map for your project.

As a complete noob to the Web development world one of the first differences I noticed is that web pages are the result of the *merge* between the HTML, JS and CSS files. I found that working on these files in separate tabs was a pain. We'll be working on various ways of allowing the coder to focus more closely on working and less on navigation issues. I don't think it'll take 10 years to show multiple editors on one tab within Orion...;-).

What I'd like to see is something like this:





This uses everything we've seen so far. Type inferencing tells us that '_thumb' is a DIV, meaning that we can infer that 'splitLayout' is a CSS class name. We can then search in the appropriate CSS files to locate the actual CSS class and extract it to show in the tooltip. Ideally in this scenario the tooltip would allow you to edit the contents of the class to allow you to 'tweak' it without ever having to open it.


I wish that this was available when I started...;-)


by Eric Moffatt (noreply@blogger.com) at February 24, 2015 09:05 PM

Announcing Sapphire 8.1.2 Release

by Konstantin Komissarchik (noreply@blogger.com) at February 24, 2015 08:21 PM

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 8.1.2 release. This release includes a number of fixes, mostly in the area of accessibility.

by Konstantin Komissarchik (noreply@blogger.com) at February 24, 2015 08:21 PM

New service release for EMF-IncQuery 0.9.1

by ujhelyiz at February 24, 2015 04:19 PM

We have made public a new service release EMF-IncQuery 0.9.1, that fixes a few issues that were found after the last release. It is recommended for every user of EMF-IncQuery 0.9.0 to update.


by ujhelyiz at February 24, 2015 04:19 PM

Eclipse Newsletter - Develop for the Cloud, in the Cloud

February 24, 2015 02:19 PM

Read up on Orion 8 and Che, projects building web-based tools for software developers, and Codefresh's innovative use of Orion.

February 24, 2015 02:19 PM

JBoss Tools Alpha1 for Eclipse Mars

by maxandersen at February 23, 2015 09:12 PM

Happy to announce first Alpha build for Eclipse Mars M5.

Downloads available at JBoss Tools 4.3.0.Alpha1.

Installation

This version of JBoss Tools targets Eclipse Mars 4.5 (M5).

We recommend using the Eclipse 4.5 JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you use our update site directly:

http://download.jboss.org/jbosstools/mars/development/updates/core/

Note: Marketplace entry and Integration Stack tooling will become available from JBoss Central at a later date.

What is new ?

As always there is more than can be covered in a single blog but here are some of my favorites. You can see everything in the What’s New section for this release.

Java EE 7 Batch and CDI Support

The initial work on providing a structured editor for Java EE 7 Batch job.xml files are in. The editor is based on Eclipse Sapphire and over time we want to extend it for smarter content assist both in the structured editor but also in the source view.

Java EE 7 Batch Editor

Furthermore for Java EE 7 we’ve now added auto enablement of CDI for Java EE 7 projects. Meaning the tools also now honor Java EE 7 CDI spec about no longer requiring beans.xml for activating CDI.

BrowserSim Standalone and iPhone 6 skins

BrowserSim adds skins and layout for iPhone 6 devices.

iphone6

These skins and others are also available in BrowserSim Standalone mode which allow you to run Browersim without depending on a full Eclipse install.

You can use this "oneliner" to try it out:

curl -L -o bs.zip http://bit.ly/browsersim-3-7-ss-jar && unzip bs.zip && java -jar browsersim.jar tools.jboss.org

If you are on OSX you need this one:

curl -L -o bs.zip http://bit.ly/browsersim-3-7-ss-jar && unzip bs.zip && java -XstartOnFirstThread -jar browsersim.jar tools.jboss.org

We’ve extended the HTML5 palette to allow easier adding of often used html5 elements.

palette

This grew the palete to be rather big thus we came up with adding a 'Most popular' slot so you always have easy access to the elements you used most often.

The following video shows how that works.

FeedHenry support

If you are a FeedHenry user we’ve now added support for easy importing and running of your FeedHenry Cordova applications.

importFeedHenryAppWiz

Windows Phone support

Apache Cordova support now includes support for Windows Phone projects (requires you to run on Windows still though :)

WPExport

This also adds support for running Windows Phone Emulator.

Hierarchical projects

This feature is actually part of Eclipse M5 and not directly JBoss Tools but I wanted to mention it because the feature is awesome and it was contributed by us by the great work of Mickael Istria.

In Eclipse M5 the Project Explorer now have a "Projects Presentation" in its view menu. Allowing you to switch from the traditional "Flat" view to the new "Hiearchical". This new option lets you view the projects as they are structured on the filesystem as opposed to one big flat list.

Flat vs Hierarchical projects

This is especially super helpful for those who have large multimodule Maven projects. Now you can get some sanity back.

Next steps

While we wait for feedback on Alpha1, we are already working on what will become Alpha2. Some of the things that are moving here are:

  1. OpenShift v3

  2. Docker Tooling

  3. Better JavaScript content assist

  4. Deprecate/remove visual JSF page editor, focusing on html5 preview

  5. Making project imports in Eclipse simpler

  6. And more…​

As always, ask/suggest away and we’ll keep you posted!

Have fun!

Max Rydahl Andersen
@maxandersen


by maxandersen at February 23, 2015 09:12 PM

Open Source Reporting Comparison BIRT, Jasper, Pentaho - Third Edition

by Scott Rosenbaum (noreply@blogger.com) at February 23, 2015 08:07 PM

Innovent Solutions has performed periodic comparisons of the reporting portion of Eclipse BIRT, Jaspersoft and Pentaho starting in 2010 with an update in 2012. In 2015, we have decided to revisit the reporting products to evaluate what has changed and to update our comparison.

To see the full review please visit our website to read the articles:


by Scott Rosenbaum (noreply@blogger.com) at February 23, 2015 08:07 PM

EMF Forms Developer Tooling: Debugging

by Maximilian Koegel at February 23, 2015 06:47 PM

EMF Forms makes it really simple to create forms to edit your data. To get started please refer to our tutorial. We have recently released EMF Forms 1.5.0, which will also ship with the Eclipse Luna SR2 Modeling Tools. For this release we put a focus on improved developer tooling. This involves the View Model Editor and Error Reporting in the run-time. This blog post will describe one particular feature in the run-time: improved debug output.

In default mode EMF Forms is resilient to failure and will try to render as much as possible even in the presence of ill-configured view models and the like. This is good for production but not so nice if you would like to diagnose a problem while still developing your application. Therefore we provide a debug mode for the run-time. If you set “-debugEMFForms” as a program argument you can instruct the EMF Forms run-time to run in debug mode. This will provide detailed output in case of problems.

23 02 2015 19 31 43 EMF Forms Developer Tooling: Debugging

For example if a renderer fails to render something, a view model fails to load or a domain model references is invalid and fails to resolve, EMF Forms will report those failures rather than falling back to default behavior. This should help with finding the culprit…;)

23 02 2015 19 50 14 EMF Forms Developer Tooling: Debugging


TwitterGoogle+LinkedInFacebook

Leave a Comment


by Maximilian Koegel at February 23, 2015 06:47 PM

PolarSys stellt 5 neue Open Source Lösungen für Systems Engineering vor

February 23, 2015 03:11 PM

Die Eclipse Foundation und PolarSys, ein Industrie Konsortium (“Working Group”) innerhalb der Eclipse Foundation, liefert nun 5 neue Lösungen für die Entwicklung von eingebetteten Systemen.

February 23, 2015 03:11 PM

PolarSys Introduces Five New Open Source Solutions for Embedded System Development

February 23, 2015 03:11 PM

PolarSys announces five new industry solutions for embedded system development.

February 23, 2015 03:11 PM

Reformatting multiple source files

by Christian Pontesegger (noreply@blogger.com) at February 22, 2015 07:16 PM

Recently I had to apply a new code formatter template to a project. Changing 50+ files by hand seemed to be too much monkey work. Writing a custom plug-in seemed to be too much work. Fortunately there is this great scripting framework to accomplish this task quite easily.

Step 1: Detecting affected source files

I have already blogged about EASE and how to install it. So I went directly to the script shell to fetch all java files form a certan project:
loadModule('/System/Resources');

org.eclipse.ease.modules.platform.ResourcesModule@5f8466b4
files = findFiles("*.java", getProject("org.eclipse.some.dedicated.project"), true)
[Ljava.lang.Object;@1b61effc
Now we have an array of IFile instances. Easy, isn't it?

Step 2: The formatter script

Ideas how to format source files can be found in the forum. Taking the script and porting it to JS is simple:
function formatUnitSourceCode(file) {
unit = org.eclipse.jdt.core.JavaCore.create(file);

unit.becomeWorkingCopy(null);

formatter = org.eclipse.jdt.core.ToolFactory.createCodeFormatter(null);
range = unit.getSourceRange();
formatEdit = formatter
.format(
org.eclipse.jdt.core.formatter.CodeFormatter.K_COMPILATION_UNIT
| org.eclipse.jdt.core.formatter.CodeFormatter.F_INCLUDE_COMMENTS,
unit.getSource(), 0, unit.getSource().length(), 0, null);
if (formatEdit.hasChildren()) {
unit.applyTextEdit(formatEdit, null);
unit.reconcile(org.eclipse.jdt.core.dom.AST.JLS4, false, null, null);
}

unit.commitWorkingCopy(true, null);
}

Step 3: glueing it all together

Load the function into your script shell, fetch the list of files as in step 1 and then process all files in a loop:
for each (file in files) formatUnitSourceCode(file);
That's it. This short script uses your current source formatter settings and applies it to all selected files.

This little helper is available online in the EASE script repository.

by Christian Pontesegger (noreply@blogger.com) at February 22, 2015 07:16 PM

A Vision of the Future of the Software Developer’s Platform

by waynebeaton at February 20, 2015 04:17 PM

How will the developer’s platform change over the next three years? Will you still be using desktop-based development tools? Cloud-based software development options are getting more powerful, but will they completely replace the desktop? For a certain set of developers, cloud-based software development tools will be a natural fit and so we should expect migration to tools like Che. But the desktop will remain viable and vibrant well into the future: for many classes of problem, the desktop is the right solution.

Of course, there will be grey areas. Some problems can be addressed equally well by desktop- and cloud-based solutions. For these sorts of problems, the choice of development tools may be–at least in part–a matter of developer preference. There will be other drivers, of course (the exact nature of which is difficult to speculate). For this grey area, the ability for a software developer to pick and choose the tools that are most appropriate for the job is important. Further, the ability to mix and match development tool choices across a team will be a key factor.

I’ve spent a good part of the last few months working with a group of Eclipse developers to hammer out a vision for the future of the developer’s platform. Here’s what we came up with:

Our vision is to build leading desktop and cloud-based development solutions, but more importantly to offer a seamless development experience across them. Our goal is to ensure that developers will have the ability to build, deploy, and manage their assets using the device, location and platform best suited for the job at hand. Eclipse projects, the community, and ecosystem will all continue to invest in and grow desktop Eclipse. Full-function cloud-based developer tools delivered in the browser will emerge and revolutionize software development.

Continued focus on quality and performance, out-of-the-box experience, Java 9, and first class Maven, Gradle, and JVM Languages support also figure prominently in our vision of a powerful developer’s platform.

To paraphrase:

  • Desktop Eclipse will remain dominant for the foreseeable future;
  • Cloud-based developer environments like Che and Orion will revolutionize software development;
  • Developers will be able to choose the most appropriate tools and environment;
  • Projects can move from desktop to cloud and back;
  • Desktop Eclipse developer tools will gain momentum;
  • The community will continue to invest in desktop Eclipse-based IDEs;
  • Java™ 9 will be supported;
  • Developer environments will have great support for Maven and Gradle;
  • Support for JVM languages will continue to improve; and
  • User experience will become a primary focus

You’ve likely noticed that this is focused pretty extensively on Java development. This is not intended to exclude support for other programming languages, tools, and projects. As the expression goes, “a rising tide lifts all boats”: as we make improvements and shift focus to make Java development better, those improvements will have a cascading effect on everybody else.

My plan for the near future (Mars time-frame) is to get the Che project boot-strapped and latch onto the that last bullet with regard to the desktop IDE: user experience. While user experience is an important consideration for most Eclipse projects, it needs to be a top focus.

This vision of the future isn’t going to just happen. To succeed, we need organizations and individuals to step up and contribute. I’m aware that project teams are stretched pretty thin right now and many of the things on the list will require some big effort to make happen. Our strategy, then, is to start small.

I’m buoyed (in keeping with my sea metaphors) by the overwhelmingly positive response that we got when we turned line numbers on by default in some of the packages. I’ll admit that I don’t quite understand the excitement (it’s such an easy thing to toggle), but for many of our users, this was a very big and important change. The curious thing is that–while the change was preceded by a lengthy and time-consuming discussion–making the actual change was relatively simple.

My take away is that we can have some pretty big wins by doing some relatively small things. With this in mind, I’ve been poking at an informal programme that I’ve been calling “Every Detail Matters” (I borrowed this name from the Gnome community). Every Detail Matters will initially tackle things like names and labels, default settings for preferences, documentation, and the website/download experience (I’ve set up an Every Detail Matters for Mars umbrella bug to capture the issues that I believe make up the success criteria).

We’re also trying to tackle some relatively big things. The “installer problem” is one that I’m hopeful we’ll be able to address with via the Oomph project. I’m also pretty excited by the prospect of having Eclipse release bits available from the Fedora software repository on GA day.

In parallel, we’ve launched a more formal Great Fixes for Mars competition with prizes for winning contributors of fixes that improve the Java development experience.

Enter the Great Fixes for Mars skills competition; there'll be prizes!

Enter the Great Fixes for Mars skills competition; there’ll be prizes!

I’ll set up a BoF session at EclipseCon to discuss the vision and our strategy for making it real. It’d be great to see you there!


EclipseCon 2015

I wrote about the Platform Vision in the November Eclipse newsletter.



by waynebeaton at February 20, 2015 04:17 PM

Scout Adopters we didn’t know about.

by Jérémie Bresson at February 20, 2015 04:17 PM

At BSI (the company behind the Scout Framework) we have recently discussed our knowledge about the community of Eclipse Scout users and found that it is too limited. This was one of the lessons we learned from our first Scout User Group Meeting. For this meeting we have invited our Scout customers and colleagues. By customer we mean individuals from companies that have paid for services in relation to Scout (consulting, trainings, change requests, project bootstrap, …). And by colleague we mean people we already met (at conferences or democamps) that where doing something with Scout. This get together was important, informative and supported the networking between customers/contacts. However, we found that the real challenge is to contact and learn from Scout adopters that we do not know (yet).

Eclipse Foundation Policy and Set-up.

Both the legal and the technical set-up at the Eclipse Foundation allows interested people to use any Eclipse project without any form of identification. This is great for adopters, but makes it hard for the project teams to learn more about their users. From the conversations I had with the Eclipse Foundation staff member, a registration form is something that we will never have at eclipse.org because this is against the Eclipse policy. So we had to find another path to contact our adopters.

In order to start learning more about our Scout community we decided to try to use the Scout Forum as a starting point. The reason for this decision was based on the observations that we have most of our existing interactions on this channel and that we enjoy a friendly and constructive atmosphere there. And since about 2 months, we ask our regular forum visitors (when we think that they must have built something serious with Scout) to tell us more about themselves and their project. We have made the experience that a good place to ask this question is at the end of a precise answer to a specific question. Then, they can write us an email scout@bsiag.com or fill a “Made with Scout Survey”. The proposition is of course visible and open for everybody at the forum, but asking specific individuals works much better.
We believe that this is a fair compromise to the community members, as they are free to answer or not and their answer does not affect the quality of the answer we continue to deliver.

What are we doing with the Survey Data?

Not much, really. Often we exchange some emails and then agree on a phone or skype call. In the call we are most interested in the background of the people, their experience with Scout so far and what they are currently working with Scout. This external feedback then helps us to improve the Scout experience and to focus our investment on those aspects that are considered valuable for these individuals. Of course, we are only at the beginning of this journey but so far this approach proved to be a valuable experience for both sides.

Some success so far?

In late January I got an email from József Agg. The Application he made with Eclipse Scout is a backend system for a Hungarian travel agency publishing content with JAX-RS to web CMS front end.
The attached screenshots are really impressive, that is why I would like to share them in this blog post.

screenshot1

screenshot2

screenshot3

If allowed, we will also add a screenshot of József’s application to the screenshot gallery on our Eclipse Scout Homepage.

If you are using the Eclipse Scout Framework!

Like József did, please tell us about. We will be happy to get in touch with you. You can:

We really hope to meet more of you and would be happy to invite you to our second Scout User Group Meeting too. According to our planning so far, the event will take place in Ludwigsburg on the Monday of the EclipseCon Europe 2015.

Scout Links

Project Home, Forum, Wiki, Twitter


by Jérémie Bresson at February 20, 2015 04:17 PM

Orion 8.0 – Language Tooling Enhancements – Part 2

by Curtis Windatt at February 19, 2015 08:06 PM

The number of language tooling enhancements added to Orion for the 8.0 release is so large we had to break it up into two parts.  The first part explained the introduction of hovers.  Try out all of these new features right now at orionhub.org

JS Validation

There are plenty of bug fixes and several new rules added to our JavaScript validator in 8.0.  ESLint, which runs our validation rules, was updated to version 0.8.2.

  • Assignments in conditional expressions:
    nocondassign
  • Reserved words used as property keys:
    noreservedkeys
  • Constant as conditional expression:
    noconstantcondition
  • Trailing commas in object expressions
  • Discouraged console use in browser code
  • Multiple spaces in regular expressions
  • Discouraged __iterator__ property use

Remember that you can configure the severity for each rule on the JavaScript settings page, or modify the severity for a specific file by adding an ESLint comment to your file.

Another cool new feature in Orion is the Show Problems action.  Available by right clicking on a file or folder in the navigation pane > Show Problems…  This will run the validator on all of the selected content, displaying the entire list of of issues.  The list can be filtered by text or source file and clicking on any problem will take you directly to the annotation.

problemsview

CSS Validation

Potential problems in your CSS files are found using CSSLint 0.10.0.  You can now configure the severity of each problem on the CSS settings page.

csssettings

You can also configure the severity of problems in each file by adding a csslint embedded ruleset.  There is also now content assist proposals to help you set the severity for specific rules.

csscontentassist

Quickfixes

When hovering over problem annotations in the editor you may see links to resolve the issue.  This is the new quickfix feature.  Quickfixes provide one click solutions to fix problems in your code.

There is no service API to provide quickfixes.  Currently you must provide commands with a scopeID of ‘orion.edit.quickfix’.  The commands will be rendered as links under problem annotations.  In 9.0 we are looking into making quickfixes be contributed through a separate API.

The JavaScript tooling and CSS tooling both provide quickfixes for some problem types and we plan to continue adding more throughout the next release.

jsquickfix

cssquickfix

File Navigation

Quickly searching and navigating between source files is one of the major benefits of coding in an IDE over a simple text editor.  Finding the file referenced in a Node.js or AMD Module dependency can be time consuming.  Orion 8.0 has a number of improvements to make this much easier.

In JavaScript, under the tools menu, you can use the Open Declaration command to jump to the function declaration for your selection (don’t forget that hovering will show you the formatted JSDoc for the function).  The keybinding for this is F3.

We also provide a hover that will link to absolute and workspace relative paths, allowing one click access to your dependencies.

navdefinenavimportscriptsnavrequirenavcss

This feature extends to the CSS and HTML tooling as well allowing you to swiftly move between associated files.

If the tooling isn’t sure which file you are referring to, a list of potential files is displayed.

HTML with embedded scripts and styles

The quality tooling available when editing JavaScript and CSS files is also available in the HTML editor.  When there are embedded scripts and CSS styling in an HTML file content assist, validation, hovers, quickfixes and file navigation are all available.  All of the embedded content is handled as a single unit like the browser will, so you can use tools like Jump to Declaration even if the script is split up in the HTML source.

 


by Curtis Windatt at February 19, 2015 08:06 PM

Hacking OSGi’s bundle resolving

by Florian Pirchner at February 19, 2015 04:32 PM

Last week, we ran into troubles when deploying our system via Equinox P2: All of a sudden, our DSLs simply didn’t work after the installation of the system into a new Eclipse – the DSL projects didn’t request the Xtext nature, and Eclipse didn’t open the appropriate editor without displaying any error message. Big showstopper!

A look in the log revealed the following:

org.eclipse.e4.core.di.InjectionException: java.lang.LinkageError: 
loader constraint violation: when resolving overridden method
"org.eclipse.xtext.xbase.ui.contentassist.XbaseProposalProvider.getProposalFactory
(Ljava/lang/String;Lorg/eclipse/xtext/ui/editor/contentassist/ContentAssistContext;)
Lcom/google/common/base/Function;" the class loader (instance of
org/eclipse/osgi/internal/loader/EquinoxClassLoader) of the current class,
org/eclipse/xtext/xbase/ui/contentassist/XbaseProposalProvider, and its
superclass loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader),
have different Class objects for the type com/google/common/base/Function
used in the signature ...

So the root of the problem were different versions of Google Guava (that contains com.google.common.base.Function). Of course, OSGi supports running multiple versions of bundles at once – which we do in our system since Sirius uses Guava 15 and Mylyn uses Guava 18. No problem so far!

The problem

The problem arose because Xtext is open to a wide range of Guava versions. Unfortunately, the Xtext bundles were not wired to one Guava version consistently, but randomly to one of the two (depending on the order of resolution). This introduced incompatibilities between Xtext bundles, which prevented the system from working.

Wiring Xtext bundles to different Guava versions prevents Xtext from working.

The problem: Xtext bundles were wired to different Guava versions, causing class loader problems within the Xtext class-space. (Click to enlarge)

Searching for a way

Now what can be done?

One possible solution for this would be employing the OSGi “uses”-directive (good explanation here): This directive in the bundle headers of multi-bundle projects can ensure that the class space is consistent. The problem with this solution was that we would have had to fork Xtext in order to add the “uses”-directives. Since we are not (yet) ready and willing to do that, we reported a bug with Xtext. The good news is that the helpful guys over there reduced the likelihood of inconsistent bundle wiring by removing some reexports. The bad news: There is no waterproof solution at hand that will work in any case.

Maybe – just maybe – upgrading to Xtext 2.8 might have helped. With our complex system, this would have taken two weeks and forced the same migration on our customer. No good!

 

Breakthrough: Hacking OSGi

So back to the planning table: What we want is to make sure that all Xtext bundles end up with the same version of Guava. So if we could influence the OSGi resolving process, we’d be fine! But to do that, the code that influences the resolving process needs to be loaded first – a chicken and egg problem: Who makes sure that the code that determines bundle resolution order is the first to be fired up?

A closer look at the OSGi specification showed us that there is a mechanism in place already: The Resolver Hook Service makes it possible to influence the resover’s decisions by writing a system extension to the OSGi framework.

After some research about the details of the Resolver Hook Service, we came up with a system bundle fragment that is called whenever a bundle wants its dependencies resolved. This fragment is given a list of possible candidates for the bundle wiring. Now we can kick out the older versions if a dependency can be resolved by more than one version of a bundle, so only the newest one remains. And voilà: All of Xtext ended up with Guava 18.

The Resolver Hook Service makes it possible to ensure correct bundle wiring.

Our solution: Using the Resolver Hook Service, we can influence the decisions made by the Resolver and control which bundles are used to satisfy dependencies of other bundles. (Click to enlarge)

 

Deploying the solution

We still were faced with one minor problem: OSGi needs to be made aware of the system extension fragment at startup. Locally, this is no problem: One can either add “osgi.framework.extensions=…” to the $ECLIPSE_HOME/configuration/config.ini, to the vm section in the $ECLIPSE_HOME/eclipse.ini or pass it as an argument to the VM (‑Dosgi.framework.extensions=…).

But how to do this automatically during a P2 installation? Well, as Dennis Hübner put it:

p2.inf is your friend

Using a p2.inf located next to the feature.xml of the feature containing the bundle fragment, it is easy to update the $ECLIPSE_HOME/configuration/config.ini during the installation process. Yayy, it works!

 

Our code

The code we came up with is available under the EPL. It can be found in our lunifera-runtime repo at Github (development branch, relevant folders: org.lunifera.runtime.systemextension and org.lunifera.runtime.feature.resolverhooks).

 

Originally posted at Lunifera.com

 



by Florian Pirchner at February 19, 2015 04:32 PM