Eclipse Projects: Level Playing Field

For many open source organisations, open means the same thing as transparent: open as in open book. At the Eclipse Foundation, we regard being transparent as the practice of making sure that the community can see and understand what the project is doing; and being open as the act of giving up absolute control and welcoming the community to participate as an equal player on a level playing field (i.e. being open to participation by the others).

Screenshot from 2017-07-31 23-22-35

Not really a field, but this is the closest thing that I have to a picture of field-based sporting event. Ice is about as level as you can get.

At the Eclipse Foundation, we take the open part of open source very seriously. It’s codified in the Open Source Rules of Engagement found in the Eclipse Development Process.

Everybody needs to play by the same set of rules. A level playing field doesn’t necessarily mean that a project team needs to accept every single contribution that comes their way. Rather, it means that the project team needs to have a set of rules by which everybody participates; and these rules can’t include things like for whom the contributor works.

Contribution rules can require that contributions fall within the project’s scope and current release plan. The rules can require that all code contributions be accompanied by unit tests and documentation; or that contributions implement a solution for an issue that’s been discussed by the project team in their issue tracker. Some sort of quality bar is a reasonable part of any set of contribution rules.

For most open source projects, these contribution rules aren’t formally captured. However, most of the rules that I’ve listed so far collectively form a pretty reasonable default set of participation rules. A quality bar is (obviously) hard to quantify, but for many project teams it’s enough that any committer feels that the contribution should be accepted (some projects require that two committers sign off on a contribution before it can be accepted).

Note that it’s also perfectly reasonable for a project team to require that significant contributions come with a promise of continued investment in the form of the contributor becoming a member of the project team.

Regardless of the rules that define the level playing field for any particular project, any content destined for the project’s code base should have some public record of contribution. Otherwise, the project would be operating (at least in part) hidden from community involvement and so counter to the open source rules of engagement. That public record can take the form of a Gerrit review, GitHub pull request, or (if you’re in a pinch) an attachment on a Bugzilla or GitHub Issue record.

Regardless of how a contribution is presented, the contributor must be listed as the author in the Git commit record and must complete the Eclipse Contributor Agreement before any contribution can be accepted.

The best way to get involved with an open source project is connect with the project team. All Eclipse project repositories should have a contribution guide in the root of every Git repository with this contact information and more. You can also search for project information on the Eclipse Projects website.

Posted in Eclipse 101, EDP, Project Management | Leave a comment

Follow @EclipseJavaIDE

If you’re new to the Eclipse IDE you’re already a big fan, you’ll find something of value every day by following @EclipseJavaIDE.  Frankly, there’s so much good stuff coming out of this account, that it’s hard to pick any favourites. So, I’ve pulled out a couple of recent ones.

Menu entries exist to help you complete incomplete thoughts and—of course—CTRL+1 is always there for Quick Fix or Quick Assist; but sometimes you just don’t want to take your hands off the keyboard.

Automating tedious operations like generating fields, getters and setters, etc. is something that the Eclipse IDE does well. Converting anonymous classes into lambda expressions? Easy.

Follow @EclipseJavaIDE to get your daily Eclipse IDE tips and tricks.

Download the Eclipse IDE, Oxygen Edition today.

EclipseCon Europe 2017

Posted in Eclipse 101, Java | Leave a comment

License Certification (Mostly) Just Happens

The Eclipse Intellectual Property Policy defines two types of intellectual property (IP) due diligence for third party content. The so-called Type A Due Diligence is concerned exclusively with license certification; and Type B Due Diligence is concerned with license certification, provenance checking and a deep dive scan of the content for various anomalies.

Regarding the analysis of Type A third party content, the IP Policy makes this statement:

It will be the responsibility of the Eclipse Project to run and analyze the results of a scan tool provided by the EMO, using parameters provided by the EMO, to obtain the terms and conditions under which such Content would be distributed by the Eclipse Foundation, and ensure that such terms are consistent with the Project Licenses. The Eclipse Project will certify that the terms and conditions of its Non-Eclipse Content conform to the then-current licensing guidelines as provided by the EMO. No further approvals will be required from the EMO prior to the Eclipse Project placing the Non-Eclipse Content into the Repository.

In short, it is the project team’s responsibility to run a tool, analyse the results, and certify the content as being consistent with the various conditions. It took us a while to identify the scan tool.

The Eclipse IP Team has been using open source Fossology for a while. While Fossology is a very comprehensive tool that’s great for IP Analysts, our experience suggests that the learning curve is too steep for it to be used by committers. What we wanted to provide was a tool that could generate a simple report (both human and machine readable) containing a manifest and corresponding licensing.

We found what we needed in ScanCode, which is produced by some old friends at NexB. ScanCode has the ability to generate the manifest and summarize findings in a number of different formats, including HTML, JSON, and SPDX RDF and Tag/Value. Using ScanCode is pretty easy. In fact, it’s so easy that the Webmaster integrated its use into an Eclipse Genie script. So… for a project team to run the tool, all they really need to do is create a CQ. The rest just happens automatically.

license-certification-workflow

In cases where the third party content has a single white listed license, committers only need to create the CQ and then add the content to their builds. If Eclipse IP Team review is required, the committer may need to participate in that review.

To leverage this automatic scan, a project committer creates a Type A contribution questionnaire (CQ) in the usual way and attaches the corresponding source code. The magic happens after the PMC gives their approval: the Eclipse Genie process identifies every Type A third party content CQs that has been approved by the PMC, runs ScanCode on the source code attachments, and then attaches the report directly to the CQ.

If a single license is identified for all files in the third party content, and that license is on our white list (see below), then the CQ is automatically marked license_certified, its license information is updated, and the CQ is marked resolved. If multiple licenses, blacklisted licenses, or otherwise problematic licenses are detected (i.e. anything other a single white listed license), then the CQ is sent to the Eclipse IP Team for further investigation.

When you see something like the following on your CQ, you’re good-to-go.

Screenshot from 2017-07-18 15-19-46

At this point, the content can be used in project builds and included in milestone builds. Once all project CQs are either marked as license_certified (type A) or approved (type B), the project can do an official release.

I’m really curious to see what sort of hit rate we get on automatic license certification, vs. how many requests will have to be reviewed by the Eclipse IP Team. My hope is that we will get to a point where we have an 80% automatic approval rate; but we don’t have enough data to make a call yet.

Our current implementation has the following licenses in the white list:

  • Apache License 2.0
  • Apache License 1.0
  • Apache License 1.1
  • BSD 2 Clause
  • BSD 3 Clause
  • BSD 4 Clause
  • Eclipse Public License 1.0
  • Eclipse Distribution License 1.0
  • MIT License
  • ISC License
  • NTP License
  • OpenSSL License
  • Public Domain
  • SIL OPEN FONT LICENSE
  • W3C Software and Notice License
  • zlib license

We need to find a home for this. This list will grow.

We’re using Bug 496959 to track our work to update our processes and documentation regarding the Eclipse IP Process.

Posted in Eclipse 101, Intellectual Property, Uncategorized | Leave a comment

Devoxx4Kids Ottawa June 2017

We all had such a great time at the Devoxx4Kids session in San Jose this past March that we’ve decided to try running a session here in Ottawa.

The goals and mission of Devoxx4Kids is to:

  1. Teach children Computer Programming while having fun and introduce them to concepts of robotics, electronics and generally being creative with these kind of devices.
  2. Inspire not only children but also the classical education system, so they too can start including computer science in their curriculum.
  3. Demystify programming for girls and introduce them to computer science in order to improve gender equality in that field.

The full manifesto is on the Devoxx4Kids website. There’s also all sorts of information about the programme, including links to the workshops.

20170319_130428

Don’t let this picture fool you. Plenty of young women attended the session in San Jose, but we were so caught up in the fun that we didn’t take all that many pictures…

For this first attempt, we’re going to keep it simple and run only two workshops (they ran eight in four parallel streams in San Jose). Since we’re new at this, we’re going to stick to coding workshops with a plan to branch out and maybe try some of the hardware workshops in a future session (these workshops require that we acquire some supplies and equipment that we don’t have readily at hand).

For this first run, the good people at Carleton University have offered up some space. Registration will open at 9:00 am on Saturday, June 3, 2017; we’ll be in room 5345 of the Herzberg Physics building.

5345 Herzberg Physics
Carleton University
1125 Colonel By Dr
Ottawa, ON K1S 5B6

The target age range for attendees is between ten and fourteen years of age (close counts). We’ll post more information, including how to register, on our event page. Registration includes lunch. We’re charging a modest fee of $30 to cover our expenses. Attendees will need to bring their own laptop computer to complete the exercises (we may be able to bring a few spares).

If you’re interested in helping to mentor the session, please send us a note at emo@eclipse.org. We’ll get the mentors together in late May to go through the exercises and make sure that everybody is ready to hit the ground running.

The first workshop will focus on a simple game written in Javascript and HTML using a game engine called Phaser. Participants are shown some basic JavaScript expressions and are then invited to use their new knowledge to modify the game. The beautiful thing about this exercise is that it requires virtually no set-up: the code is all self-contained, any text editor (including Notepad) can be used for modifications, and it all runs in a browser. Further, it can be run successfully without requiring an Internet connection.

The second workshop is concerned with Minecraft Modding using Forge for Minecraft and Eclipse IDE as the development environment. This workshop has a few more moving parts than the first and so will require a bit more effort to set up and most certainly does require a stable Internet connection to at least assemble the initial development environment via a Gradle build. There’s certainly a lot of opportunities in this workshop to explain all sorts of interesting concepts without getting bogged down in too many details (which will be good if we end up having attendees with prior experience).

Screenshot from 2017-05-12 15-36-17

We’ll send out setup instructions a week or so ahead of the session; we can hit the ground running faster if everybody has the software that we’re going to need already downloaded.

Posted in Announcements, Devoxx4Kids, Other | Leave a comment

Service Releases of Third Party Content in the Eclipse IP Due Diligence Process

Some time ago, the Eclipse Foundation’s Board of Directors passed the following resolution.

RESOLVED, that previously approved dependencies of Eclipse projects can be
reviewed and approved by the EMO as follows:
a) Service releases (e.g. x.y., bug fixes, security fixes) will require no review.
b) Minor revisions (e.g. x..) will require a reduced review by the EMO.
c) Major revisions (e.g. ..) will require a full review by the EMO.

At the time the resolution was passed, it was decided that project teams would still be required to register the use of service releases for third party content with the Eclipse Intellectual Property (IP) team (i.e. create a Contribution Questionnaire); it was decided that the resolution really only impacted how the IP Team would process the content: at least in theory, the IP Team would rubber stamp requests for service releases. I say in theory, because the IP Team would still eyeball these requests and sometimes invest some modest effort to ensure that significant new IP hadn’t been introduced.

We’ve reconsidered this position.

Project teams are not required to engage with the Eclipse IP Team to review service releases for third party content, provided that the service release is based on a previously-approved release. This assumes that the providers of the third party content regard service releases in the manner described by Semantic Versioning (i.e. a patch of backwards-compatible bug fixes) and that the service release does not include significant new IP.  Of course, if a project team isn’t sure, they can always just submit the content for review anyway.

We envision a scenario where project teams will take advantage of this for milestone builds, but then get full approval for final versions of their third party content. This isn’t required, but it is an option that’s available for project teams that feel that it’s necessary.

For major and minor releases, the manner in which the the project team interacts with the Eclipse IP Team does not change. Note that it is implied that the reduced review for minor releases follows an approved full review for a corresponding major release and that any service release follows an approved major or minor release.

For more information, to add your thoughts and concerns, or to track our progress with regard to updating our documentation, add yourself in copy to Bug 512465.

Posted in Intellectual Property | Leave a comment

Run Eclipse IDE on One Version of Java, but Target Another

The Eclipse IDE for Java™ Developers (and the other Java developer variants) is itself a Java application that’s used to build Java applications. That relationship can be a bit weird to wrap your brain around.

Written almost entirely in Java, the Eclipse IDE requires a Java Runtime Environment (JRE) to run. A JRE provides just the runtime platform: it doesn’t include the source code and Javadoc for any of the base Java libraries, or any of the development tools that are included in the Java Development Kit (JDK). An Eclipse IDE runs just fine on a JRE.

If you’re building Java applications, however, you really need to have access to a JDK. By default, an Eclipse IDE will configure itself to build applications against the JRE that it was launched on. If that JRE is part of a JDK, then you’ll get access to all the goodies that you need to get useful content assist, documentation, debugging support, etc. If the runtime platform is just a JRE, then a lot of that valuable goodness will be missing (but compiling still works because the Java development tools include the Eclipse Compiler for Java)

Here’s where it gets a bit weird. You can run an Eclipse IDE on a JRE from one version of Java and build applications that target one or more different versions of Java. You can, for example, run your Eclipse IDE on Java 8, but use it to build applications based on basically any earlier version of Java. You can select the default Java version for your workspace in the preferences (on the Java > Compiler page), or individually in the properties for each Java Project (preferred).

JDK Compliance settings in the Preferences (Java > Compiler)

In order to actually build applications on a different version of Java, you need to connect your Eclipse IDE with the corresponding JDK. To do this, first install the JDK, and then tell the Eclipse IDE where to find it via the Java > Installed JREs page in the workspace preferences. With additional JDKs installed, you can configure individual projects to use specific versions of the compiler and runtime.

All of this is a long way of saying that you can configure your Eclipse IDE, Oxygen Edition milestone build to run on a Java 9 JRE, (download a JDK from the JDK 9 Early Access site) but use it to build applications that target earlier versions of Java (i.e. keep doing your day job). Even doing just this and providing feedback will be very helpful to the Eclipse projects involved in the Eclipse IDE. If you actually want to build Java 9 applications, you’ll need to install the Java 9 Support (BETA) for Oxygen from the Eclipse Marketplace and provide feedback to the team.

Note that the JDT product in the Eclipse Foundation’s Bugzilla instance is specifically for reporting bugs that are directly related to the Java development tools. Use the EGit product to report issues with the Git integration, the m2e product to report issues with the Maven integration, the Buildship product to report issues with the Gradle integration, the Platform product for issues with regard to the basic IDE framework, the Web Tools product for issues with enterprise Java and web development, or the EPP (Eclipse Packaging Project) product if you’re not sure.

Many committers from the various Eclipse projects that contribute to the Eclipse IDE, including at least a couple of committers from the Java development tools project in particular, will be at Devoxx US. If you want to learn more about Java 9 support in the Eclipse IDE, you’ll be able to find them at the Eclipse Foundation’s booth (or we’ll be able to help you find them).

I’ll also be doing a demonstration of Test First Java Development using the Eclipse IDE at the booth. Come by and see if I can keep myself within the twenty minute limit…

If you want to learn more about the great features available in the Eclipse IDE, follow @EclipseJavaIDE on Twitter (follow me while you’re at it).

devoxx_black_transparent400

Posted in Community, Conferences, Eclipse 101, Java, Screenshots | Leave a comment

Eclipse IDE, Oxygen Edition; and Java 9

I’ll admit that I dropped the ball for a while, but I’m back to testing the Eclipse IDE with Java 9. Java 9 includes some pretty major changes, especially in the way that it restricts access to internal code, and so there’s a real risk that Java-based applications are going to break. Just confirming that the Eclipse IDE runs on Java 9 is a critical task (even before we talk about leveraging actual Java 9 features).

Today, I downloaded the Java 9 Early Access Build 158 (March 1/2017) and reconfigured my working installation of the Eclipse IDE for RCP and RAP Developers, Oxygen Edition (M5) to use it. I’ve added a few extra features to my installation, including the PHP Development Tools, Data Tools SQL Designer, Mylyn WikiText, TM Terminal, and a handy regular expression helper/tester that I found in the Eclipse Marketplace.

Configuration is relatively straight forward. The nice thing about the early access builds is that you can just decompress them into a directory on your system without installing them (which will have a impact on your system’s configuration). The downside is that you have to configure your Eclipse IDE to find it. Actually, this isn’t really much of a downside in my opinion: I like to have some degree of control over what Java  runtime I’m using to run the Eclipse IDE rather than just grabbing the system default.

I decompressed the Java build and updated my eclipse.ini file to point point to it:

...
-vm
/home/apps/jigsaw-jdk-9-ea+158_linux-x64_bin/jdk-9/bin/
-vmargs
--add-modules=java.se.ee
...

Note that you need to add the --add-modules option to tell Java 9 to load some modules that it wouldn’t normally load by default. I’m hopeful that we’ll have an update to the launcher to automatically add this option in the M6 builds (see Bug 493761); with this launching the Eclipse IDE will just work if you happen to have a Java 9 JVM installed as your system default.

As a sanity check, I opened the About Eclipse dialog and reviewed the Configuration in the Installation Details to confirm that I’m actually running on Java 9. The next step is to actually start writing some code that leverages Java 9 features; for that I’ll need to install the Java 9 Support (BETA) for Oxygen from the Eclipse Marketplace.

I’m looking forward to learning a lot more about Java 9 at Devoxx US, including these sessions:

See you at Devoxx!
devoxx_black_transparent400

Posted in Conferences, Java | 5 Comments