Overhauling IP Management at the Eclipse Foundation

by Mike Milinkovich at June 29, 2016 01:00 PM

At our recent face-to-face Board meeting earlier this month, an agreement in principle was made to move ahead with the largest overhaul of our intellectual property processes since the inception of the Eclipse Foundation 12 years ago. Now, don’t get too excited because months of work are going to be required before the new policies are approved, and the implementation of new processes are completed. But I did want to share the direction we are heading in with the community to get your input and feedback.

What do we do today?

The Eclipse Foundation takes a very rigorous approach to intellectual property management. As far as I know, we are the only open source foundation to have a dedicated staff whose sole responsibility is the review all of the code distributed by Eclipse Foundation projects. The easy part is the code that is written by Eclipse committers. The far more time-consuming piece is a detailed review of all of the dependencies used by or distributed with Eclipse projects. That dependency review includes checking license compatibility, scanning the code to look for potential issues, and checking in on the provenance of the code in question. That last piece (“provenance”), can be particularly time-consuming because it involves answering questions like “was the code ever re-licensed from licenseA to licenseB, and if so how was permission obtained from the contributors?”. Or “how does this project manage contributions to it?” To my knowledge, no other open source foundations or communities do the level of detailed analysis that we do.

The good news is that the Eclipse community and the IP team staff at the Eclipse Foundation can take a great deal of pride in knowing that what ships from Eclipse has been well reviewed, and can be safely consumed by users and adopters in downstream products. The bad news is that this is a lot of work for the projects, and can be very time consuming for everyone involved.

What are we changing?

The proposal is pretty simple. In the future Eclipse projects will be able to decide what level of IP due diligence they want performed for each of their releases. For the purposes of this discussion, let’s call them “Level 1” and “Level 2”, although there is a high probability that those labels will change.

“Level 2” is what we do now. No change.

“Level 1” takes a much simpler approach for dependencies. Basically, all that will be checked is license compatibility with the project license(s). We won’t do code scans or provenance analysis of any of a Level 1 project’s dependencies. However, all of the existing processes around managing the code which is developed by or contributed to Eclipse projects will continue. (This includes things like committer agreements, CLAs, and git signed-off-by, etc.)

The decision on which level a project wants can be specified on a per-release basis. So, for example, if a project wants have a very fast release cycle (e.g. ship something every 4 weeks) but still wants to ship a fully reviewed major release once a year, that would be a supported use case. The authority to make this decision rests with the project lead for the project.

This new approach will have particular value for new projects at the Eclipse Foundation. Rather than waiting for their dependencies to be cleared by the IP team, once the project can self-certify that all of their dependencies have compatible licenses they will be able to check-in their code and start working at Eclipse. We are hoping that this is going to reduce the ramp-up time for a new project from months to about a week. As part of making this happen we will need to find a scan tool which give an accurate report of licenses contained in code artifacts that is usable by developers. If anyone knows of any such tools, please let me know!

Why are we doing this?

There are lots of reasons, ranging from resources to agility to changing industry perceptions around risk in open source. But the most important one is that we want to help Eclipse projects be more successful. We have a lot of process that our projects need to deal with, and for a great many of them the IP requirements exceeded what their users and adopters required. So the time for a re-calibration has come.

When is this going to get done?

It’s hard to say with certainty, but our goal is to have this fully implemented by the end of this year. There are two major components to making that happen:

  1. We have to make some significant changes to the Eclipse Foundation IP Policy, and have those reviewed and approved by the Board of Directors. That is going to take a few months.
  2. We need to implement some changes in our tools and processes to support this. That includes changes to the Project Management Infrastructure (PMI) to track the IP level for a release, finding and hosting a license scan tool that committers can use to self-certify their dependencies, etc.

Where do we discuss this?

I’ve opened bug 496959 to discuss this, and to track all of the pieces that will go into its implementation. I am really looking forward to hearing from the community about this proposal. Personally, I am very excited by it, and think that a lot of projects will be as well.

Caveat: All of this assumes that the necessary changes are approved by the Board of Directors. The Board makes the call on these policies, and when they see the final edits to the IP Policy perhaps they will have a change of heart. But obviously if I thought that outcome was a high probability I wouldn’t be talking about this yet.

 


Filed under: Foundation

by Mike Milinkovich at June 29, 2016 01:00 PM

Orion 12 Brings Full Support for ECMAScript 2015

by James Chesters at June 28, 2016 05:00 PM

The Eclipse Orion project team has released version 12, bringing full support for the ECMAScript 2015 Language Specification. Mike Rennie, Orion contributor, says the release continues to emphasise Orion's JavaScript tooling, and that along with support for ECMAScript 2015, the release includes improved project configuration capabilities, and support for eslintrc.* files.

By James Chesters

by James Chesters at June 28, 2016 05:00 PM

New and Improved Eclipse Neon UI

by Ricardo Rodriguez at June 28, 2016 02:35 PM

Eclipse Neon comes with many improvements in terms of features, API and UI too. Sometimes it’s hard to notice all the hard work put into the inner workings of Eclipse. For the user, things just work or they don’t. However, one the most noticeable aspects of new software is changes made to the user interface. Sometimes […]

The post New and Improved Eclipse Neon UI appeared first on Genuitec.


by Ricardo Rodriguez at June 28, 2016 02:35 PM

JBoss Tools and Red Hat Developer Studio for Eclipse Neon

by akazakov at June 27, 2016 05:11 PM

JBoss Tools 4.4 and Red Hat JBoss Developer Studio 10.0 for Eclipse Neon are here waiting for you. Check it out!

devstudio10

Installation

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it from our JBoss Products page and run it like this:

java -jar jboss-devstudio-<installername>.jar

JBoss Tools or Bring-Your-Own-Eclipse (BYOE) JBoss Developer Studio require a bit more:

This release requires at least Eclipse 4.6 (Neon) but we recommend using the latest Eclipse 4.6 Neon JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under "JBoss Tools" or "Red Hat JBoss Developer Studio".

For JBoss Tools, you can also use our update site directly.

http://download.jboss.org/jbosstools/neon/stable/updates/

What is new?

Our main focus for this release was on adoption of Eclipse Neon, improvements for container based development and bug fixing. Eclipse Neon itself has a lot of new cool stuff but let me highlight just a few updates in both Eclipse Neon and JBoss Tools plugins that I think are worth mentioning.

JavaScript Development Tools 2.0

Red Hat team along with other contributers have been working hard for the last months on restarting JavaScript Development Tools (JSDT) project for Eclipse Neon. The updated tooling includes EcmaScript 2015 support, JSON editor, Node.js, grunt, gulp, bower and npm tools.

Here is a short video which demonstrates new features and enhancements of JavaScript Tools:

Improved OpenShift 3 and Docker Tools

We continue to work on providing better experience for container based development in JBoss Tools and Developer Studio. Let’s go through a few interesting updates here and you can find more details on the What’s New page.

Dockerfile Editor

The new Dockerfile editor provides users with content assist on the commands (ADD, COPY, RUN, etc.) as well as a customizable syntax highlighting.

Docker Editor

Deploy docker images to the CDK OpenShift registry

The New OpenShift Connection wizard supports setting a Docker registry URL in the advanced properties section. This allows you to push docker images to the given Docker registry via the Deploy Docker Image wizard, right before actually creating the OpenShift resources. The URL is automatically added if the connection has been created by the CDK server adapter.

deploy push docker image

New support for builder images

The New OpenShift Application wizard now supports builder images, on top of the existing template support.

builder support

Compared to regular templates, with the builder image-based workflow, users will be able to define:

  • git source url

  • build triggers

  • environment variables

  • data volumes

  • replicas

  • exposed service ports and routes

Create new resources

The OpenShift Explorer provides a New > Resource menu, that lets you create new OpenShift resources from an existing file, similar to the oc create -f some_resource.json command. Resource files can be local (from File System or Workspace), or remote, by providing a URL.

Scaling pods

It is possible to scale pods up and down, from the Service context menu in the OpenShift Explorer, or the Deployments and Deployment Configuration context menus in the Properties view.

scale up down

New EAP 7 quickstarts

Red Hat Central now lists quickstarts targeting the newly released Red Hat JBoss Enterprise Application 7.0 server.

central eap7

And more…​

You can find more noteworthy updates in on this page.

What is next?

Having JBoss Tools 4.4 and Developer Studio 10.0 out we are already working on the next maintenance release for Eclipse Neon.

Enjoy!

Alexey Kazakov


by akazakov at June 27, 2016 05:11 PM

EMF Forms and EMF Client Platform 1.9.0 released!

by Maximilian Koegel and Jonas Helming at June 27, 2016 07:45 AM

We are happy to announce that together with Neon, we have released  EMF Forms and EMF Client Platform 1.9.0! We want to thank all committers and contributors for their work as well as the active ecosystem of users and adopters for the feedback and support!

EMF Forms is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for a introduction.

Both frameworks are part of Eclipse Modeling Tools Neon, but you can also find the new release on our download pages:

 

Both projects have been amazing successes since their inception over 5 years ago. We are proud of having a continuously active team of 15 contributors:

We also would like to thank all of our customers and sponsors for making this success possible. EMF Forms and ECP are great examples, that business models based on open source work well and that open source can continuously save costs. The contributions and sponsoring of the last years have created an incredible value, which is successfully used by many projects for their benefit. At the same time the costs have been shared among many contributors. If you believe in code stats, we are close to total costs of 9 Million Dollar (see below). However non of the existing contributor or sponsor has accounted for more than a small fraction of this.

It is also amazing to see, that EMF Forms and ECP are used in a huge variety of application domains from engineering over e-commerce to finance, from high technology vendors to sailing associations. While the managed data is completely different in those domains, the cross-cutting requirements are often shared. This is part of the success of sharing the code. Especially in the last months, we often had very similar feature requests from completely different domains, sometimes literally within a week. If every contributor or sponsor takes over a small piece, they benefit from all the other pieces, which are already there.

So what is next? You might have noticed, that we have started on a new renderer for EMF Forms based on a native web stack called JSON Forms. We see it as the optimal complement for EMF Forms and hope to make the idea of declarative UI development even more attractive. We are amazed by the progress of JSON Forms and we will soon start a blog series to introduce it more in detail. However, as you can see in the EMF Forms / ECP repository, we have not in anyway reduced our effort for the existing frameworks and do not have any plans to do so.

As always, we will also blog about new features of the EMF Forms / ECP1.9.0 release in the upcoming weeks! Please follow this blog or follow us on twitter to get notified about the new posts.


TwitterGoogle+LinkedInFacebook

Leave a Comment. Tagged with eclipse, emf, emfcp, emfforms, eclipse, emf, emfcp, emfforms


by Maximilian Koegel and Jonas Helming at June 27, 2016 07:45 AM

Eclipse Neon: 5:30-minute demo of 22 nice improvements

by howlger at June 26, 2016 04:31 PM

Watch a 5:30-minute demo of 22 nice Eclipse Neon improvements, including IDE, Java and Web/JavaScript:

Eclipse Neon: 5:30-minute demo of 22 nice improvements

For more details there are 4:34:25 hours of Eclipse Neon Webinars.



by howlger at June 26, 2016 04:31 PM

Solve weird java.io.EOFException at java.io.DataInputStream.readFully in Oomph with Eclipse Neon

by Michael Vorburger (noreply@blogger.com) at June 26, 2016 07:35 AM

If you are getting the first error (1) below when using an Eclipse Installer (Oomph) v2441, then just re-download a fresh later version from https://www.eclipse.org/downloads/ (e.g. 2444 at the time of writing), and it will work again.  For some reason, the Auto Update does not work to get from Oomph 2441 to 2444.

If you are then still getting the second error (2) below, after having upgraded Oomph, then simply retry by restarting Oomph or even simply by using the <Back and Next> and this appears to go away.  Alternatively, perhaps you would like to blow away your entire p2 cache via rm -rf ~/.p2 (although normally this should not be required).


(1) Fetching content.xml.xz from http://download.eclipse.org/technology/epp/packages/neon/
ERROR: org.eclipse.equinox.p2.metadata.repository code=1002 Unable to read repository at http://download.eclipse.org/technology/epp/packages/neon.
java.io.EOFException
  at java.io.DataInputStream.readFully(DataInputStream.java:197)
  at java.io.DataInputStream.readFully(DataInputStream.java:169)
  at org.tukaani.xz.SingleXZInputStream.initialize(Unknown Source)
  at org.tukaani.xz.SingleXZInputStream.<init>(Unknown Source)
  at org.tukaani.xz.XZInputStream.<init>(Unknown Source)
  at org.tukaani.xz.XZInputStream.<init>(Unknown Source)
  at org.eclipse.equinox.internal.p2.metadata.repository.XZedSimpleMetadataRepositoryFactory.load(XZedSimpleMetadataRepositoryFactory.java:80)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57)
  at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768)
  at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:370)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:177)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:437)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
  at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$RepositoryLoader$Worker.perform(ProfileTransactionImpl.java:1625)
  at org.eclipse.oomph.util.WorkerPool$Worker.run(WorkerPool.java:416)
  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)


(2) ERROR: org.eclipse.equinox.p2.metadata.repository code=1002 Unable to read repository at http://download.eclipse.org/releases/neon.
ERROR: org.eclipse.equinox.p2.repository code=0 An error occurred while downloading http://download.eclipse.org/technology/epp/packages/neon/content.xml.xz. The cache file /home/vorburger/.p2/org.eclipse.equinox.p2.repository/cache/downloading/2079680757 could not be renamed to /home/vorburger/.p2/org.eclipse.equinox.p2.repository/cache/2079680757.
  at org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:428)
  at org.eclipse.equinox.internal.p2.repository.CacheManager.createCacheFromFile(CacheManager.java:132)
  at org.eclipse.equinox.internal.p2.metadata.repository.XZedSimpleMetadataRepositoryFactory.getLocalFile(XZedSimpleMetadataRepositoryFactory.java:56)
  at org.eclipse.equinox.internal.p2.metadata.repository.XZedSimpleMetadataRepositoryFactory.load(XZedSimpleMetadataRepositoryFactory.java:78)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57)
  at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768)
  at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:370)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:177)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:437)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
  at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository.addChild(CompositeMetadataRepository.java:166)
  at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepository.<init>(CompositeMetadataRepository.java:106)
  at org.eclipse.equinox.internal.p2.metadata.repository.CompositeMetadataRepositoryFactory.load(CompositeMetadataRepositoryFactory.java:122)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:57)
  at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:768)
  at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke(Method.java:498)
  at org.eclipse.oomph.util.ReflectUtil.invokeMethod(ReflectUtil.java:116)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:370)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager.loadRepository(CachingRepositoryManager.java:177)
  at org.eclipse.oomph.p2.internal.core.CachingRepositoryManager$Metadata.loadRepository(CachingRepositoryManager.java:437)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:96)
  at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
  at org.eclipse.oomph.p2.internal.core.ProfileTransactionImpl$RepositoryLoader$Worker.perform(ProfileTransactionImpl.java:1625)
  at org.eclipse.oomph.util.WorkerPool$Worker.run(WorkerPool.java:416)
  at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

by Michael Vorburger (noreply@blogger.com) at June 26, 2016 07:35 AM

Presentation: Best Practices Using The CDT Debugger

by Marc Khouzam at June 25, 2016 07:03 PM

Marc Khouzam presents best practices for debugging using dynamic printf, reverse debugging, the GDB console, the standalone debugger, a Docker container and connecting CDT to a running GDB session.

By Marc Khouzam

by Marc Khouzam at June 25, 2016 07:03 PM

Presentation: Scripting Eclipse with Python

by Tracy Miranda at June 25, 2016 05:57 PM

Tracy Miranda demonstrates Python with the Eclipse Advanced Scripting Environment (EASE) for collaboration, reproducible research, and exploratory computation and data analysis.

By Tracy Miranda

by Tracy Miranda at June 25, 2016 05:57 PM

Boost Eclipse Neon JavaScript Development with JSjet

by Brian Fernandes at June 24, 2016 02:14 PM

While far from an expert, I’ve been working with JavaScript for ages. I started off using JavaScript for DHTML (anyone remember that term?) when cross-browser meant your site would work with Internet Explorer and Netscape Navigator. I moved on to using JavaScript for desktop widgets and finally, browser extensions for Firefox and Chrome. A big […]

The post Boost Eclipse Neon JavaScript Development with JSjet appeared first on Genuitec.


by Brian Fernandes at June 24, 2016 02:14 PM

Eclipse Webinar series - JSDT and Docker Tooling for Eclipse Neon

by xcoulon at June 24, 2016 10:23 AM

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


by xcoulon at June 24, 2016 10:23 AM

Vert.x 3.3.0 is released !

by cescoffier at June 24, 2016 12:00 AM

That was a long run …. but here we are. We are very pleased to announce the release of Vert.x 3.3.0!

This release is huge with lots of new features, improvements, and obviously bug fixes. We won’t detail all the new features here (some are highlighted below), and full release notes are available: https://github.com/vert-x3/wiki/wiki/3.3.0---Release-Notes

Breaking changes are there: https://github.com/vert-x3/wiki/wiki/3.3.0---Breaking-Changes. Be sure to read them before migrating.

The event bus client using the SockJS bridge are available from NPM, Bower and as a WebJar:

Docker images are also available on the Docker Hub. The Vert.x distribution is also available from SDKMan and HomeBrew.

Let’s highlight some of the major features shipped with this release.

  • Vertx 3.3.0 is the first version to support HTTP2 (client and server). You can now configure HTTP servers and clients to use HTTP2. Proxy support for TCP and HTTP client has also been added.
  • This version shows also the introduction of a bridge with Apache Camel. So, integrating Vert.x applications with legacy systems (using EIP) has never been so easy.
  • Several new components have been developed to implement microservice-based applications. First, a pluggable service discovery is now available. An implementation of the circuit breaker pattern has also been provided.
  • AMQP 1.0 support has been also integrated thanks to a bridge to send and receive messages from AMQP. A client has also been shipped to interact directly with an AMQP broker or router.
  • New metrics has also been introduced to ease the monitoring of running applications. For instance, it’s now possible to monitor the thread usage in the worker thread pool and in the JDBC connection pools.
  • With this version, you can configure the TCP aspects of the event bus for, for instance, use SSL. Also notice a bridge between the event bus of Vert.x 2 and the one from Vert.x 3.
  • Most of the delivered components are now deployable in OSGi environments. So you can easily integrate Vert.x in Apache Karaf, Service Mix, or Apache Sling.
  • Vert.x Unit usability has been greatly improved. It is now possible to write test using Hamcrest, AssertJ, Rest Assured, or any assertion libraries you want.

Many thanks to all the committers and community whose contributions made this possible, especially to Alex Lehman, Paul Bakker, Robbie Gemmel, Claus Ibsen, Michael Kremer, and many many other!

The artifacts have been deployed to Maven Central and you can get the distribution on Bintray.

Just a word about the future. As we did last, year, a poll will be organized in the next few weeks to collect ideas and prioritize the Vert.x 3.4 and beyond roadmap. Stay tuned, we love hearing about your ideas and issues.

Happy coding !


by cescoffier at June 24, 2016 12:00 AM

Eclipse Newsletter - Eclipse Neon Shines Bright

June 23, 2016 02:00 PM

Read about the top ten Neon features, the new Eclipse User Storage Service (USS), Eclipse CDT 9.0, and Eclipse PDT 4.0.

June 23, 2016 02:00 PM

New Eclipse Neon Packages for JavaScript and Android

by ignaciom at June 23, 2016 01:24 PM

Eclipse Neon Android Package Now that Eclipse Neon is just around the corner, I was pleased to see that Eclipse for Android Developers is back. We’ve all waited a long time for it! This package bundles the Andmore-Eclipse Android Tooling—a fork of Google’s ADT (Android Development Tools) plugins for Eclipse. These are maintained separately from […]

The post New Eclipse Neon Packages for JavaScript and Android appeared first on Genuitec.


by ignaciom at June 23, 2016 01:24 PM

Eclipse Neon and ssh-agent

by Gunnar Wagenknecht at June 23, 2016 12:31 PM

Eclipse Neon is out. Time to give a long awaited feature a try again. It’s support for re-using the identify from ssh-agent running on my system within Eclipse. I want this primarily for the Eclipse Git integration.

As it turns out, the core support is part of Eclipse Neon. The SSH interface had been made extensible for additional identity discovery. The remaining missing piece is the actual code that bridges the ssh-agent connection into the Eclipse SSH interface (powered by JSch). The reason for this are – of course – legal issues. It would be great if those can be addressed and this can be shipped out of the box in Eclipse.

I forked the initial work from the JSch folks and made it consumable as an update site.

Please give it a try:
https://eclipseguru.github.io/eclipse-jsch-agent-proxy/


by Gunnar Wagenknecht at June 23, 2016 12:31 PM

Clean Sheet Update for Eclipse Neon

by Frank Appel at June 23, 2016 05:37 AM

Written by Frank Appel

In celebration of the latest Eclipse release, we provide a Clean Sheet Update for Eclipse Neon. Congratulations and a big ‘thank you’ to all the diligent Eclipse committers and contributors that made the Neon version happen, great work! While the Clean Sheet Update for Eclipse Neon primarily ensures compatibility it comes also with some nice Look-and-Feel improvements. This post gives a short overview of the most important innovations of the feature’s new version (0.4).

 

The Clean Sheet Eclipse Design

In case you've missed out on the topic and you are wondering what I'm talking about, here is a screenshot of my real world setup using the Clean Sheet theme (click on the image to enlarge). Eclipse IDE Look and Feel: Clean Sheet Screenshot For more information please refer to the features landing page at http://fappel.github.io/xiliary/clean-sheet.html, read the introductory Clean Sheet feature description blog post, and check out the New & Noteworthy page.

 

FlatScrollBar Overlay for ScrolledComposite

Styling capabilities have been enhanced to allow adoption of ScrolledComposite widgets and derivatives by the FlatScrollBar overlay mechanism on Windows platforms. The picture shows how the content area of the preference dialog blends in the Clean Sheet scrollbars on diminution.

Clean Sheet Update for Eclipse Neon: Scrolled Composite Overlay

Forms Style Adjustment

The styling of FormToolkit based views and editors has been overhauled. Together with the FlatScrollBar overlay mechanism on ScrolledForms (Windows only), UI parts like the PDE Manifest editor integrate now quite nicely with the overall look and feel of the Clean Sheet theme.

Clean Sheet Update for Eclipse Neon: Forms Look and Feel

Clean Sheet Installation

Drag the 'Install' link below to your running Eclipse instance

Drag to your running Eclipse installation to install Clean Sheet

or

Select Help > Install New Software.../Check for Updates.
P2 repository software site: @ http://fappel.github.io/xiliary/
Feature: Code Affine Theme

After feature installation and workbench restart select the ‘Clean Sheet’ theme:
Preferences: General > Appearance > Theme: Clean Sheet

 

On a Final Note, …

Of course, it’s interesting to hear suggestions or find out about potential issues that need to be resolved. In particular, as the ScrolledComposite widget has some interesting layout mechanisms by itself there still might be some uncovered spots with the newly added scrollbar overlay mechanism. Feel free to use the Xiliary Issue Tracker or the comment section below for reporting.

With this in mind, I’d like to thank all adopters for the support and hope that everybody likes the Clean Sheet Update for Eclipse Neon as much as we do 😉

The post Clean Sheet Update for Eclipse Neon appeared first on Code Affine.


by Frank Appel at June 23, 2016 05:37 AM

Eclipse Marketplace: Neon and 20 Million

by Ian Skerrett at June 22, 2016 07:40 PM

The Eclipse Neon release is now out. I also noticed Eclipse Marketplace just passed the 20 million successful install milestone. Wow, that is a lot of developers using Eclipse Marketplace.

Eclipse Marketplace - 20 million

For the Neon release, there are two key features that I think will accelerate the use of Eclipse Marketplace Client (MPC).

  1. Eclipse MPC now allows you to store your Favorite with your Eclipse account. The other very cool feature is you can import someone else favorite list. Here is my favorite list if you are to give it a try.

mpc favorites

2. In Eclipse Neon, selecting the text editor for associated file types now allows a user to search Eclipse Marketplace Client for plug-ins that support that file type. This should make it a lot easier for developers to find the appropriate plug-in from Eclipse Marketplace.

Congratulations to everyone that made the Eclipse Neon release possible. Another great community collaboration.

 



by Ian Skerrett at June 22, 2016 07:40 PM

New and noteworthy for codeEdit widget 12

by Libing Wang at June 22, 2016 06:25 PM

Orion codeEdit widget debuted just one year ago in Orion 9.0. Thanks to all the valuable user feedback over the past year, now in Orion 12, the widget has been improved a lot for both usability and customizability. We’ve updated the widget wiki page to include the latest features, summarizing user feedback in the FAQ section.

The codeEdit demo page shows you two of the biggest improvements in the widget: customizable editor configurations and fine tuning your web language tooling. In Orion 11.0 we introduced tern project – now this feature is integrated into the widget. In the demo you will see a zoom ruler in each editor, enabled by an editor configuration change. You will also see how the javascript file validation behavior changes while live editing the tern project and eslint rule files.

Aside from that, there are other major improvements that are not shown in the demo.

With all the improvements so far, we found it’s been much easier for the existing users to consume and customize the widget. We are still improving in other areas so please stay tuned.


by Libing Wang at June 22, 2016 06:25 PM

New and Noteworthy in Javascript tooling for Orion 12.0

by Olivier Thomann at June 22, 2016 05:15 PM

As noted in our Orion 12.0 announcement, a tonne of work has gone into this release of Orion.  Over 350 Bugzilla reports were fixed.  Here are some of the many things we have been working on for the JavaScript language tooling.  Expect more in-depth looks at these items in the next few weeks.

Cross-file linting

The ESLint based validation in our JavaScript tools up to Orion 11 was only focused on the single file you were editing.  No consideration was given to the rest of your project setup.  With 12.0 the linting is now aware of the other files in your workspace and the project configuration you have set up.

  • no-undef: Warn when a global variable has not been defined
  • no-undef-expression:  Warn when a function (member expression) has not been defined
  • no-unused-vars: Warn when declared variables are not used.
  • unknown-require:  Unknown required library
  • type-checked-consistent-return: Discouraged inconsistent returns

So we can now in many cases tell you that you are using a function that doesn’t exist.  Especially helpful when you mistype the name or use the wrong casing.

Make the tools consumable

We have created a new API and webpack build that will package up the JavaScript tooling in one consumable bundle that can be used to drive language plugins for other IDEs, such as Brackets or Atom.

A deep-dive into the new API is coming in a subsequent blog post. To get a jump on it, we have provided two wiki pages: (1) JavaScript tools API and, (2) Building the JavaScript API.

Improved Tern integration

In Orion 12.0 we moved the remainder of our client-side services to be Tern plugins.

These new plugins include:

  1. ESlint
  2. Occurrences
  3. Templates / templating
  4. Quickfixes
  5. Outlining

The move to be more Tern-centric with our features carries many benefits, but most importantly it allows us to cut down on message passing, improve memory use and make the features more portable.

ECMA 2015 support

Orion 12.0 supports all of the ECMA 2015 specification like arrow functions, import/export statements and classes.

The tooling completely understands the new language syntax with new quick fixes and code templates also being available to get you started.  The linting rules have also been updated to respect the new ECMA 2015 code patterns.

Outlining has been updated:

ECMA 2015 outlining support

ECMA 2015 outlining support

Occurrences has been updated:

ECMA 2015 occurrences support

ECMA 2015 occurrences support

Linting has been updated:

Lint rules updated for ECMA 2015

Lint rules updated for ECMA 2015

We also support import and export statements which require the source type to be “module”. This is set through the .tern-project file – and you can use a handy quickfix to write it all for you.

Change sourceType quickfix

Change sourceType quickfix

Support for ESLint project configuration files

Users can now include .eslintrc files in their projects.  These files can configure all of the ESLint settings that your files are validated with, including rule severities.

.eslintrc file example

.eslintrc file example

When this file is present, the rule values will override any workspace settings.  If you go from editing your project to changing settings the page will warn you that an .eslintrc file is present.

Preference warning banner for .eslintrc overrides

Preference warning banner for .eslintrc overrides

We support other forms of ESLint configuration too, such as settings in package.json. There is a hierarchy of configuration files that you can use. Read the full details on ESLint’s configuration page.

Package.json ESlint configuration section

Package.json ESlint configuration section

Support for in-project definition files

You can define and use your own definition files in your project. See the file IndexCreation.md to find out how to proceed.

Tern index file example

Tern index file example

The tooling will include all the type information found in your definitions to improve content assist, tooltip hovers and more.

Content assist for example in-project index file

Content assist for example in-project index file

Updated third-party libraries

Most of our third-party libraries have been refreshed:

  • Acorn 3.1.0
  • Doctrine 1.2.1
  • ESrecurse 4.1.0
  • Estraverse 4.1.1
  • Escope 4.2.0
  • Tern 0.18.0

A notable change to our consumed library lineup is that we have discontinued use of the Esprima parser in favour of Acorn.  There are many reasons for the switch, but the main reasons are:

  • Acorn has complete ECMA 2015 support (with recovery for most of it).
  • We can easily extend the Acorn parser via its plugin mechanism, so there is no need to edit parser code to have our Orion customizations.
  • Acorn has robust recovery support right out of the box (no more editing the parser to hack our own in).

by Olivier Thomann at June 22, 2016 05:15 PM

Announcing Handly 0.5

by Vladimir Piskarev at June 22, 2016 05:00 PM

I am very pleased to announce the availability of the Handly 0.5 release, a true “2.0” version in spirit. This release introduces an entirely new design that gives the implementor of a Handly-based model complete control over the model API. Among other things, this should make it possible to use Handly for (re-)implementing handle-based models where the model API is a given, just as in the case of a preexisting model API that needs to be preserved for backward compatibility. Many of the core APIs have been revised in this release to make Handly even more flexible and robust.

New and Noteworthy
Migration Guide
Downloads

Any feedback would be greatly appreciated.

Many thanks to all who contributed to this release:

  • Ondrej Ilcik, head of IDE Team at Codasip, has kindly contributed a navigator view for the Java model example, which made its way into this release. This is the first significant (~ 4K LOC) contribution to the project by a non-committer. Codasip Studio is one of the earliest adopters of Handly, and it is really great to see that a major adopter becomes a significant contributor. Also, Ondrej has been so kind as to share a great success story of Codasip Studio and Handly, which is all the more valuable as the first success story published by a Handly adopter.
  • Vlad Dumitrescu, the project lead of erlide, has been actively participating in discussions on the project’s mailing list. His earlier feedback helped inspire the new design introduced in this release, and he has also contributed great ideas about restructuring the project’s web page to make it more readable.
  • Peter Gribanov, 1C, has contributed a success story describing how 1C:Enterprise Development Tools, the earliest adopter of the project, is using Handly.

Thank you for contributing!


by Vladimir Piskarev at June 22, 2016 05:00 PM