Skip to main content

Eclipse Collections 10.1 Released

by Donald Raab at December 12, 2019 06:24 PM

This is tenth release review and the fourth year for Eclipse Collections as a project at the Eclipse Foundation.

Eclipse Collections t-shirts made by my wife with her Cricut Maker for EC Contributors and Advocates

Thank you to the contributors

First, I want to give a big shout-out and thank you to all the contributors who took time and contributed to this release. This was a minor feature release but there are some notable additions to the library and the Eclipse Collections community. We also have some new first time contributors to Eclipse Collections and OSS, and I want to say congratulations, welcome, and thank you!

New Features

  1. Implemented RichIterable.groupByAndCollect.
@Test
public void groupByAndCollect()
{
MutableList<String> list =
Lists.mutable.with("One", "Two", "Three");
    MutableMultimap<Character, String> multimap =
list.groupByAndCollect(
each -> each.charAt(0),
String::toUpperCase,
Multimaps.mutable.list.empty());
    MutableListMultimap<Character, String> expected =
Multimaps.mutable.list.with('O', "ONE", 'T', "TWO", 'T', "THREE");
    Assert.assertEquals(expected, multimap);
}

2. Implemented NoopProcedure.

@Test
public void noopProcedure()
{
MutableList<Integer> list = Lists.mutable.with(1, 2, 3);
list.forEach(Procedures.noop());

Assert.assertEquals(Lists.mutable.with(1, 2, 3), list);
}

Other Improvements

  1. Spanish Translation of the Eclipse Collections website.
  2. Updated documentation for creating/modifying Immutable Collections.
  3. Fixed variable name in Multimaps class for ImmutableSortedBagFactory.
  4. Fixed generated Eclipse features for p2 repository to ensure correct EPLv1 license is downloaded.
  5. Fixed generated Eclipse features for p2 repository to ensure correct signatures on artifacts.

Bug Fixes

  1. Fixed IntInterval.fromToBy() for same values of from and to with a negative step.
  2. Fixed IntInterval.injectInto() for same values of from and to with a negative step.

Four years at the Eclipse Foundation

This month we will celebrate the four year anniversary of Eclipse Collections as a project at the Eclipse Foundation. I am happy to report that Eclipse Collections is still going strong! We continue to grow our community of contributors, users, and advocates. Everyone I know that uses Eclipse Collections in their projects really appreciates the richness and symmetry of the API, and the productivity and performance of the library. Thank you to everyone in the Eclipse Collections community for your support!

Eclipse Collections 10.1 will also be included in the upcoming Eclipse IDE release.

Eclipse IDE 2019-12

Note: Eclipse Collections can be used in any Java project and with any Java IDE. Eclipse Collections has no runtime dependencies on any other library and does not depend on the Eclipse IDE. The library is available in Maven Central and as an OSGi Bundle.

Thank you

From all the contributors and committers… thank you for using Eclipse Collections. We hope you enjoy all of the new features and improvements in the 10.0 and 10.1 releases.

Have a safe, healthy and happy holiday season! If you like Eclipse Collections, join the other stargazers and give the repo a star on GitHub.

Eclipse Collections is open for contributions. If you like the library, you can let us know by starring it on GitHub.


Eclipse Collections 10.1 Released was originally published in Oracle Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.


by Donald Raab at December 12, 2019 06:24 PM

Announcing Eclipse Ditto Release 1.0.0

December 12, 2019 05:00 AM

Today the Eclipse Ditto is thrilled to announce the availability of Eclipse Ditto’s first major release 1.0.0.

Maturity

The initial code contribution was done in October 2017, 2 years later and 2 releases (0.8.0 and 0.9.0) later, we think its time to graduate from the Eclipse “incubation” phase and officially declare the project as mature.

Recent adoptions and contributions from our community show us that Eclipse Ditto solves problems which also other companies have. Adopters add Eclipse Ditto as a central part of their own IoT platforms.

API stability

Having reached 1.0.0, some additional promises towards “API stability” do apply:

HTTP API stability

Ditto uses schema versioning (currently schema version 1 and 2) at the HTTP API level in order to being able to evolve APIs. It is backward compatible to the prior versions 0.8.0 and 0.9.0.

JSON API stability

Ditto kept its main JSON APIs (regarding things, policies and search) backwards compatible to 0.8.0 and 0.9.0 releases. The JSON format of “connections” was changed since 0.9.0 and will from 1.0.0 on be kept backwards compatible as well.

Java API stability

The Java APIs will for the 1.x release be kept backwards compatible, so only non-breaking additions to the APIs will be done. This is enforced by a Maven tooling.

The following Java modules are treated as API for which compatibility is enforced:

  • ditto-json
  • ditto-model-*
  • ditto-signals-*
  • ditto-protocol-adapter
  • ditto-utils
  • ditto-client

Scalability

The focus on the 0.9.0 and 1.0.0 releases regarding non-functionals were laid on horizontal scalability.

With Eclipse Ditto 1.0.0 we are confident to face production grade scalability requirements being capable of handling millions of managed things.

Changelog

The main changes compared to the last release, 0.9.0, are:

  • addition of a Java and a JavaScript client SDK in separate GitHub repo
  • configurable OpenID Connect authorization servers
  • support for OpenID Connect / OAuth2.0 based authentication in Ditto Java Client
  • invoking custom foreign HTTP endpoints as a result of events/messages
  • ability to reflect Eclipse Hono’s device connection state in Ditto’s things
  • configurable throttling of max. consumed WebSocket commands / time interval
  • Addition of “definition” field in thing at model level containing the model ID a thing may follow
  • Improved connection response handling/mapping

Please have a look at the 1.0.0 release notes for a more detailed information on the release.

Artifacts

The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Docker images have been pushed to Docker Hub:



Ditto


The Eclipse Ditto team


December 12, 2019 05:00 AM

The Eclipse Foundation Launches the Edge Native Working Group to Deliver Production-Grade Code for Open Source Edge Computing

December 10, 2019 02:30 PM

The Eclipse Foundation today announced the launch of the Edge Native Working Group, a vendor-neutral and code-first industry collaboration that will drive the evolution and broad adoption of open source software for edge computing.

December 10, 2019 02:30 PM

Close to the Edge

by Mike Milinkovich at December 10, 2019 12:00 PM

Today we are launching our new Edge Native Working Group to help drive the industry platform for edge computing. The new group has hit the ground running with everything needed to accelerate adoption of enterprise applications at the edge: a mature code base that’s already widely deployed in production environments, strong endorsements and participation from industry heavyweights, strong collaborations with other industry organizations such as the CNCF, and a deep understanding of the key challenges ahead.

But before turning to the details of the announcement, let’s talk a little about how edge computing differs from related technologies such as cloud and IoT.

To me, edge computing differs from IoT in that IoT is historically a bottom up approach. The people who talk about IoT are likely coming from an embedded systems or industrial automation background, and are looking for new, open stacks to connect their OT systems to modern cloud infrastructure.

Edge computing is more of a top down approach where people are looking for how they can take the new generation of cloud infrastructure and use it to solve problems at the edge of the network. Edge computing does not necessarily differ from cloud computing in terms of compute power (multiprocessor 64-bit x86 or ARM with gigabytes of RAM) or software stack (containers, Kubernetes, and microservices). The single most important differentiator between cloud compute and edge compute is simply “do you know (or care) where the resources are located”? If the answer to that is yes, then you are in the realm of edge computing. In addition, the requirement to deal with the transparent orchestration of microservices from cloud to edge is key.

Edge Accelerates Applications

Artificial intelligence (AI) and autonomous vehicle applications are two great examples of why there is massive interest in edge computing. Pushing applications out to the edge of the network is the only way to efficiently transfer and analyze the massive amounts of data AI applications rely on. And, it’s the only way to achieve the sub-one-millisecond latency autonomous vehicle applications require.

With the Edge Native Working Group, the global community can collaborate to evolve the commercial-grade, production-ready code base we already have in Eclipse ​ioFog​, Eclipse ​fog05​, and other projects to address technical issues that are specific to the edge:

  • Running applications on a wider variety of hardware than you would find in a data center
  • Dealing with the fact that at the edge, the physical location of your resources matters
  • Maintaining communications when you’re forced to rely on low-bandwidth, intermittent network connections while also scaling to scenarios that rely on 5G and other high bandwidth technologies
  • Ensuring the security of edge devices that are often installed in easily accessible locations (read the Edge Security Challenges whitepaper published by the Kubernetes IoT Edge working group)

Resolving these challenges will allow the Edge Native Working Group to bring EdgeOps — DevOps for the edge — to the world so developers can write software and can deploy, run, and manage it where it needs to, whether that’s on an MRI machine in a hospital, a motion-activated camera in a farmer’s field, or a fleet of vehicles.

The Market for Edge Computing Is Here and It’s Huge

Interest in resolving edge-specific issues is extremely high. Our founding member list is an impressive group of industry leaders, such as ADLINK, Bosch, Edgeworx, Eurotech, Kynetics, Huawei, Intel, and Siemens. We’re also actively engaged in discussions with other influential global players and expect to share news about additional working group members in the near future.

The stature and breadth of companies joining the Edge Native Working Group confirms the need for an open source industry group with edge code that’s ready to be used in serious deployments. According to a 2019 Allied Market Research report, edge computing is forecast to generate a market worth $16.5 billion within the next five years.

The business potential at the edge is as varied as the companies joining the working group. For a chip developer, the Edge Native Working Group offers access to an industry ecosystem that can showcase the speed of their products in AI and data analytics applications at the edge. A global telecom player can ensure its products are aligned with edge computing standards to enable 5G applications at the edge.

And on it goes, with the potential for companies in any industry to leverage the open platforms the Edge Native Working Group is developing to build customized edge applications for their specific markets and opportunities.

Get Closer to the Edge at the Eclipse Foundation

Critical new initiatives, such as the creation of the Edge Native Working Group, can only happen when Eclipse Foundation community members come together to drive them forward. I want to sincerely thank everyone involved in getting the Edge Native Working Group off the ground for their dedication and meaningful contributions. The tremendous interest and success we’ve experienced so far is a true testament to the value of the time and effort this very devoted team has committed to the project.

With the incredibly broad and bright future the Eclipse Edge Native Working Group offers, I encourage everyone to visit http://edgenative.eclipse.org/, review the ​charter​ and the ​Edge Native Working Group Participation Agreement (WPGA), or email us at membership@eclipse.org for more information. You can also join the working group’s mailing list to receive progress updates.

If you’ll be attending Edge Computing World on Dec 9-12 in San Jose, California, be sure to attend the Eclipse Edge Tools developer workshop on Tuesday, December 10 at 11:30 AM local time. Also, drop by and see us at our table in the main foyer on the second floor of the Computer History Museum, where we’ll be showcasing the ioFog, ​fog05​, and the Edge Native Working Group.

 


by Mike Milinkovich at December 10, 2019 12:00 PM

The Eclipse Theia IDE vs. VS Code

by Jonas Helming and Maximilian Koegel at December 06, 2019 11:55 AM

In this article, we compare the Eclipse Theia IDE with VS Code. We focus on the scenario of using these technologies...

The post The Eclipse Theia IDE vs. VS Code appeared first on EclipseSource.


by Jonas Helming and Maximilian Koegel at December 06, 2019 11:55 AM

Xtext 2.20 Release

by Karsten Thoms (thoms@itemis.de) at December 03, 2019 02:38 PM

Right on time for the Eclipse 2019-12 Simultaneous Release, we have shipped Xtext 2.20. This time we focussed more on maintenance work than on features. As with each release, the world around us is spinning fast, and keeping the whole technology stack up-to-date and testing against it is quite time consuming.

Let’s talk about Xtend

For a long time, the Java language missed some features that could make a developer’s life easier. This was one of the reasons that a broad range of languages running on the Java Virtual Machine (JVM) became popular, Xtend being one of them. With its powerful lambda expressions, extension methods, and template support, Xtend had some sweet spots back in 2013, which Java did not have. And even with the availability of lambdas with Java 8, it took some years for projects to catch up with that. Xtend provided this for years, while still being able to produce Java 1.6-compliant code.

Now the (Java) world has changed, and some nice language features have been added to Java, making the gap to Xtend smaller. Back in 2013, we claimed Xtend to be the “Java 10 of today”. We are realistic enough to state that Xtend is not and will not be the “Java 17 of today”. However, there are still areas where we see Xtend as beneficial over other Java and other JVM languages. To be more specific, we still think that Xtend is the most powerful language supporting template expressions. The most common use case for this are code generators. Besides that, writing unit tests with Xtend feels much cleaner than with Java.

However, we decided to encourage to use Xtend only for these areas, and not as the primary general-purpose language. And we start doing this with the “New Project” wizard. The configuration that this wizard creates for a new Xtext project, will now use Java as the language for generated skeleton classes, so that newly-created projects (and especially new users) are using Java by default. This is just a changed default for the generated MWE2 workflow, and users, who still prefer to use Xtend for the generated artifacts, can simply modify the workflow file. We expect that those users are advanced anyway. Xtend will stay the default language for the code generator and unit test fragments.

Additionally, we have started to clean up the code base and to refactor some of the Xtend code to Java. As Xtend already is compiled into Java, this basically means that we take those sources and clean them up. This will be an ongoing maintenance work. If you like to contribute to Xtext, this would be a good starting point for refactoring contributions.

New Xtend features

After that being said, there is some good news about some features that have been added to Xtend’s Eclipse integration. We are very happy about some useful contributions from Vivien Jovet in this area.

A new refactoring has been implemented that allows the user to refactor a call to a static method either as static import or as a static extension. This allows the user to produce more readable and fluent code.

EMBED:

Xtext_Release_2_20_refactoring_import_static_method

 

The testing support for Xtend has been improved:

  • An Xtend unit test can now be triggered within the Eclipse IDE when the cursor is located around the test class definition.
  • As known from JDT’s JUnit integration, Xtend now also provides quickfixes if the JUnit library is missing on the classpath. By using the quickfix, the library can be added for either JUnit 4 or 5.

It’s time to get rid off old generator workflows

Already back in 2015, we changed to new Xtend-based generator fragments and deprecated the old Xpand-based language generator. If you still use an old generator workflow based on the org.eclipse.xtext.generator bundle (the new bundle is org.eclipse.xtext.xtext.generator, please note the duplicated .xtext segment), then it is time for you to finally take action!

The old generator is based on the Xpand language, which is dormant for a while. We are refactoring Xtext to avoid any dependency on Xpand, except for the deprecated generator bundle. Also, we do not change the old generator templates anymore, so we strongly recommend to use the maintained new generator infrastructure. Although it is not scheduled yet, dropping the whole old generator completely is just a matter of time. So, please, if you still have any anciently-structured Xtext projects, migrate them to the recommended infrastructure! If you need help on this, get in contact with us. We have enough experience to help you quickly on that.

Create new projects and files from the toolbar

If you want to allow creation of projects and files for your DSL from the toolbar, then this is good news for you: The fragments for generating the infrastructure for wizards have been extended by an option called generateToolbarButton. As the name already suggests, the generator fragments will generate the button to the toolbar, if this option is enabled in the fragment’s configuration in your generator workflow.

Making our maintenance work easier

With 4 releases per year and 3 milestone releases towards any release, it is quite some effort to make these releases. As we finished our hopefully last build infrastructure change to Eclipse JIRO with the previous release, we were able to invest a bit of time into enhancing our build pipelines again.

As a result, initiating a milestone or final release is mostly triggering a parameterized build job now and then waiting several hours until everything has been build. Actually, while I’m writing this article, the final Xtext release is being build for you, which has been triggered 3.5 hours before. Yes, it still builds that long. And it is still painful to orchestrate the build over all Xtext repositories. There are still some steps that require manual action (releasing to Maven Central, updating Eclipse Marketplace, sending notifications to the communication channels), but we slowly add all automatable tasks to the pipelines.

Also, we interacted with the Eclipse infrastructure staff to get us in the position that our technical build user is able to raise pull requests on GitHub automatically. This enabled us to create a bot update pipeline that lets us automate some frequently occurring update changes. This is, for example, updating the version, versions to use (like Tycho), the Orbit URL, etc. The job raises pull requests for us, so we can safely verify that nothing is missing and that everything is properly built. It is very much like these dependency update bots like Dependabot that are coming up more and more, but tightly tailored to the very specific needs of the Xtext project. We are still at the beginning here. Some first pull requests merged for 2.20 have been created by the bot job. We expect that the bot will be triggered automatically in the future and that the bot user will become one of the most active Xtext contributors then.

Conclusion

Xtext 2.20 is a maintenance release. For users of a recent Xtext version it will be a drop-in replacement. Users of old versions and project structures are recommended to upgrade their projects, in order to keep their projects compatible.

The Xtext project started to discourage the usage of Xtend where the latter’s language features do not have a significant benefit over Java. And internally, the project started to refactor the codebase to follow this recommendation.

For build and release engineering, the project improved towards more automated tasks and benefits from reduced manual maintenance tasks.

The project team is happy about receiving contributions. We are especially grateful about new feature ideas that are actively developed by contributors.

Do you want to know more? Have a look at the release notes for Xtext & Xtend.


by Karsten Thoms (thoms@itemis.de) at December 03, 2019 02:38 PM

Yearly Release Reviews for Eclipse Projects

by waynebeaton at December 02, 2019 03:02 PM

One of the key roles of he Eclipse Architecture Council is to maintain the Eclipse Development Process (EDP). Maintenance usually takes the form of an update every year or so. Updates to the EDP are approved by the Eclipse Board of Directors. The Architecture Council records issues that need to be addressed and tracks the work in the Community/Architecture component in the Eclipse Foundation’s Bugzilla instance.

The update to the EDP in late 2018 changed the way that we engage in release reviews. Project teams only need to engage in a release review for releases that occur more than one year after their last successful release review. For most project teams (i.e., active projects making regular releases), this means that they only need to engage in a release review once every year.

Project teams still need to create a release record, but do not have to engage with the Eclipse Management Organization (EMO) or their Project Management Committee (PMC), and don’t need to submit their IP Log for review. Project leads must still take care to ensure that the intellectual property included in all releases has been fully vetted by the IP due diligence process (in practical terms, this means that all CQs for content included in a release must be resolved, and the license compatibility of all third party content must be established before making the release official).

Eclipse open source project teams who aren’t sure whether or not they’re ready to release, can check with the EMO or can submit their IP Log for a sanity check.


by waynebeaton at December 02, 2019 03:02 PM

Obeo Cloud Platform

December 02, 2019 10:00 AM

TLDR; This is almost the story of my first CTO pregnancy experience, organizational stuff inside.

It’s been almost 2 years since I started operating as Obeo’s CTO, 2 years since I accepted the challenge to take the lead of our R&D. As part of this, almost 1 year ago I started to organize the development of our new generation modeling tool solution. And for the past 9 months my team has been busy working full time on this new product.

When you become pregnant a product manager, you are basically a story trigger for everyone around you: people love to tell their failure-project and their stupid-leader story. It is scary to be at the place where you are the one who decides. It is even more frightening when you are at the point where you redesign your products with a completely different technological layer. This is where I was one year ago. At Obeo, we have been developing for years modeling workbenches based on the Eclipse Platform. Today our customers want more and asked us to modernize the modeling stack by making it cloud compliant. So how do we go from this statement to a first software release?

If you’re a product manager or affiliate, you’re probably aware that the first nine months of a new software product are always a big adventure. CTOs-to-be may have a lot of questions about what they can expect and the changes they’ll go through. Do you know when to expect to feel your product move? When to look for a UI/UX designer or a continuous deployment pipeline? Customer interest on what you are developing? Is that the signs of preterm labor?

1st month - Your imagination has no limit

The beginning of a new product is not easy. Where should we start? Should we rely on the prototypes we already have? Should we built a completely new project? How will you build your team? Who will be in? When? What will be the first scenario that will be supported in your software? How should you be organized? These are all the first questions you will come across.

What I will remember from that first month is that at some point you have to take decision: that is why you are here, that’s your job, and that will remind you why there is a C in CTO. You have the power of choice. There is not a unique good solution for everything. When every other person has a piece of advice for you, you start to understand that not everything works for everyone. I found what I believe works best for me. Of course, what works for me may not work for you: it depends on your company technological background but also on how you want to get your collaborators engaged as well. Each project, team and context is different.

Take the time to discuss this with others in your company, take the time to find what they need but also what are they dreaming about this new product. I developed my product vision for example by asking people to fill in a survey with questions such as in 1, 2, 5 years what is the final goal, the business needs, the users expectations, the success factor, etc. See the product vision template available on my github for details.

Product Vision Template

Write a summary of all this. And in the end, find your own voice in the ocean of opinions. Build your team, define your first scenario, share with everyone what you decided and do not hesitate to fail! Your first organisation might not be the best one: try, learn, update, reorganize, try something else… You are not alone in this task, this is a collective effort. The entire team cares about its organization and discusses it regularly by making retrospectives, having a dedicated moment during regular meetings, defining process to improve their collaboration, selecting tools…

The questional period you just went through, your team will go through the same. Which technical bricks will they rely on? Which part of our existing code will integrate this new project? Should we start by building the simplest scenario, this without taking into account the whole complexity of the end product you are trying to build? What should in the end be the software architecture?

Important point, give some time to your team to discuss all those things. But ask them to produce something even during that period. In our case, we wrote documents (AsciiDoc rocks!) and decided to keep a trace of all our decisions. For that, we used ADR - Architectural Decision Record: it is like reading the pocket reference of your project. After several months of use, it has turned out to be really useful. It helps people who are working part time on the project to get what we decided and why and help remember why we took a given decision. It forces us to discuss and validate all the important decisions together. You also need to stop this questioning period by just pushing your team to contribute code and not just loosing them in the limbs of the imaginative product.

Mid months - Scared! Believe! Realize!

Pregnancy, giving software birth and the first 3 months is such an emotional roller coaster with so many changes. As you move forward on your development journey, it is amazing to discover all the things your sweety-software can do before he’s born. We went through different themes during these months: Persistence, CRUD, Diagram, Properties views, Edition, Concurrence, Authentication… Then everything is on track, you are organized as a team, code is being produced, your scenarios are more and more rich. And at some point, we realized we were actually growing life within us. It did not come right when we started the project.

I felt it in 3 specific moments —

  • When we chose the name - Obeo Cloud Platform,
  • When I had a first ultrasound scan preview of the UI - fortunately we have a Design team to work with,
  • And when he kicked for the first time - I mean his first public live demo.

We will also never forget our baby shower celebration at EclipseCon Europe! This was an amazing moment for us. We were so happy to present our new work to the Sirius community. That day I was feeling the kicks in my belly. As Steve Jobs puts it, “A lot of times, people don’t know what they want until you show it to them.” That’s why we decided to give a preview of our new product even before it is polished, and why we launched a beta testing team. The idea is to give them a preview access and organize live remote testing sessions to grow the feedback river with real end-users. Join us now and share your needs!

8-9th months - You are (almost) releasing!

Today, I do not even realise it is already the last months of pregnancy: we are getting closer and closer to our due date. I have this mixed feeling of excitement and nervousness and want our software product to come as soon as possible.

Our product is getting ready for birth, and the whole Obeo family is preparing to welcome a new member. You are also invited to join us, stay tuned for the upcoming SiriusCon Live Q1 2020.

At the end of this year, on his first days, our software product will be tiny and little. It will know only a few things but will do them well. Next we will continue to feed him: baby bottles first and then we will go through the diversification phase introducing new kind of food. My team will help him to grow, you, our users, our customers will be part of its education. We have many projects and plans, but we need you to turn true customers problems into product features.

Sometimes it’s important to stop and look back. It really made me appreciate and comprehend what an amazing experience I and my company went through ❤ and still are.

Hope you had a good read.


December 02, 2019 10:00 AM

Learn to Kata and Kata to Learn

by Donald Raab at November 28, 2019 06:51 PM

Every Java developer needs to learn new skills and keep their existing skills sharp. The Java ecosystem is enormous and continues to evolve. With so much to learn, the prospect of keeping up may seem daunting. We can help each other keep up in this rapidly changing space if we work together as a community, sharing knowledge and practice. Taking, creating, and sharing code katas is one of the ways we can do this.

A code kata is a hands-on programming exercise that helps you hone specific skills through practice. Some code katas will provide you structure to validate a skill has been acquired by getting unit tests to pass. Code katas are a great way for developers to share practice exercises with their future selves and other developers to learn from.

How to create your first code kata:

  1. Select a topic you want to learn.
  2. Write a passing unit test that demonstrates some piece of knowledge.
  3. Refactor the code repeatedly until you are satisfied with a final solution. Make sure the test passes after each refactoring.
  4. Delete the solution in the exercise and leave a failing test.
  5. Commit the failing test with supporting code and build artifacts to a VCS.
  6. Open source the code to share with others.

Now I will follow the first four steps to create a small kata.

Step 1

Topic: Learn how to join strings in a List.

Step 2

Write a passing JUnit test that shows how to join strings in a List.

@Test
public void joinStrings()
{
List<String> names = Arrays.asList("Sally", "Ted", "Mary");
StringBuilder builder = new StringBuilder();
for (int i = 0; i < names.size(); i++)
{
if (i > 0)
{
builder.append(", ");
}
builder.append(names.get(i));
}
String joined = builder.toString();
Assert.assertEquals("Sally, Ted, Mary", joined);
}

Step 3

Refactor the code to use StringJoiner in Java 8. Re-run the test.

StringJoiner joiner = new StringJoiner(", ");
for (String name : names)
{
joiner.add(name);
}
String joined = joiner.toString();

Refactor the code to use Java 8 Streams. Re-run the test.

String joined = names.stream().collect(Collectors.joining(", "));

Refactor the code to use String.join. Re-run the test.

String joined = String.join(", ", names);

Step 4

Delete the solution and leave a failing test with a comment.

@Test
public void joinStrings()
{
List<String> names = Arrays.asList("Sally", "Ted", "Mary");
// Join the names and separate them by ", "
String joined = null;
Assert.assertEquals("Sally, Ted, Mary", joined);
}

Pay it forward — I will leave steps 5 and 6 as an exercise for the reader.

This example should be simple enough to illustrate how to create your own katas of varying complexity, leveraging unit tests to provide the structure necessary to build confidence and understanding.

Value your own learning and knowledge. When you learn something useful, write it down. Saving practice exercises to recall how things work can be quite helpful. Capture your knowledge and exploration in code katas. Katas you have used to sharpen your own skills may also be valuable to others.

We all have things to learn and that we can teach. When we share what we learn with others, we improve the whole Java community. This is vitally important to helping ourselves and our fellow Java developers collectively improve our coding skills.


Learn to Kata and Kata to Learn was originally published in 97 Things on Medium, where people are continuing the conversation by highlighting and responding to this story.


by Donald Raab at November 28, 2019 06:51 PM

Eclipse Committer and Contributor Paperwork

by waynebeaton at November 28, 2019 12:03 AM

The Eclipse Foundation has several agreements that we use to ensure that contributors understand the terms by which they make their contributions and, especially, to give them an opportunity to assert that they have the necessary rights to make those contributions under the terms of the corresponding project license.

The Eclipse Contributor Agreement (ECA) must be signed by anybody who wants to contribute to an Eclipse open source software or specification project. When a contributor has signed the ECA, a committer will be able to merge a contributor’s pull requests. Another way of looking at it is that a committer cannot merge a pull request when the contributor has not signed the ECA.

The Eclipse Individual Committer Agreement (ICA) is signed by folks who do not work for an Eclipse Foundation member company when they become a committer. For those developers who do work for an Eclipse Foundation member company, the company representative can complete an Eclipse Member Committer and Contributor Agreement (MCCA) which covers all of that member company’s employees.

Acquiring committer status starts with an election started by an Eclipse project team. Upon successful completion of that election, the nominee is prompted to provide the necessary paperwork. Completing that paperwork is the last step in the process, granting a developer the ability to commit (i.e., push their own content or merge pull requests from others). When a new committer signs the ICA (or their employer signs the MCCA) they also sign the ECA, and so gains the ability to contribute (but not directly push or merge) to any other Eclipse open source software or specification project.

When a developer is elected as a committer to another Eclipse project, they will not have to complete any additional paperwork. Committer status is specific to a particular Eclipse project; paperwork is not project specific.

Note that contributors retain ownership of their contributions; the ECA, for example, states in part (highlighting is mine):

This ECA, and the license(s) associated with the particular Eclipse Foundation projects You are contributing to, provides a license to Your Contributions to the Eclipse Foundation and downstream consumers, but You still own Your Contributions, and except for the licenses provided for in this ECA, You reserve all right, title and interest in Your Contributions. 

That is, the contributor owns their contributions, but grants a license to the Eclipse Foundation and downstream consumers to use them under the terms of the project license.


by waynebeaton at November 28, 2019 12:03 AM

Eclipse Vert.x 3.8.4

by vietj at November 28, 2019 12:00 AM

We have just released Vert.x 3.8.4, a bug fix release of Vert.x 3.8.x.

Since the release of Vert.x 3.8.4, quite a few bugs have been reported. We would like to thank you all for reporting these issues.

Vert.x 3.8.4 release notes

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

You can bootstrap a Vert.x 3.8.4 project using https://start.vertx.io.

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.

Happy coding and see you soon on our user or dev channels.


by vietj at November 28, 2019 12:00 AM

Eclipse m2e: How to use a WORKSPACE Maven installation

by kthoms at November 27, 2019 09:39 AM

Today a colleague of me asked me about the Maven Installations preference page in Eclipse. There is an entry WORKSPACE there, which is disabled and shows NOT AVAILABLE. He wanted to know how to enable a workspace installation of Maven.

Since we both did not find the documentation of the feature I digged into the m2e sources and found class MavenWorkspaceRuntime. The relevant snippets are the method getMavenDistribution() and the MAVEN_DISTRIBUTION constant:

private static final ArtifactKey MAVEN_DISTRIBUTION = new ArtifactKey(
      "org.apache.maven", "apache-maven", "[3.0,)", null); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$

...

protected IMavenProjectFacade getMavenDistribution() {
  try {
    VersionRange range = VersionRange.createFromVersionSpec(getDistributionArtifactKey().getVersion());
    for(IMavenProjectFacade facade : projectManager.getProjects()) {
      ArtifactKey artifactKey = facade.getArtifactKey();
      if(getDistributionArtifactKey().getGroupId().equals(artifactKey.getGroupId()) //
          && getDistributionArtifactKey().getArtifactId().equals(artifactKey.getArtifactId())//
          && range.containsVersion(new DefaultArtifactVersion(artifactKey.getVersion()))) {
        return facade;
      }
    }
  } catch(InvalidVersionSpecificationException e) {
    // can't happen
  }
  return null;
}

From here you can see that m2e tries to look for workspace (Maven) projects and to find one the has the coordinates org.apache.maven:apache-maven:[3.0,).

So the answer how to enable a WORKSPACE Maven installation is: Import the project apache-maven into the workspace. And here is how to do it:

  1. Clone Apache Maven from https://github.com/apache/maven.git
  2. Optionally: check out a release tag
    git checkout maven-3.6.3
  3. Perform File / Import / Existing Maven Projects
  4. As Root Directory select the apache-maven subfolder in your Maven clone location

Now you will have the project that m2e searches for in your workspace:

And the Maven Installations preference page lets you now select this distribution:


by kthoms at November 27, 2019 09:39 AM

Release 4.0

November 24, 2019 12:00 AM

New version 4.0 released.

Release of Type B

Features

  • Major change for API to v4
  • Destination API v4 with Managed Destination Provider
  • Mail API v4
  • Workspace API v4

Fixes

  • Migration related fixes
  • User Interface related fixes
  • Git pull with Gitlab
  • Minor fixes

Statistics

  • 4300+ Downloads
  • 11K+ Docker Pulls
  • 5.5K+ Trial Users
  • 62K+ Sessions
  • 179 Countries
  • 356 Repositories in DirigibleLabs

Operational

Enjoy!


November 24, 2019 12:00 AM

How to create/develop an Eclipse Theia IDE extension

by Jonas Helming and Maximilian Koegel at November 21, 2019 09:05 AM

In this article, we provide an overview on how to extend the Eclipse Theia IDE with custom extensions. We will show...

The post How to create/develop an Eclipse Theia IDE extension appeared first on EclipseSource.


by Jonas Helming and Maximilian Koegel at November 21, 2019 09:05 AM

Modernizing our GitHub Sync Toolset

November 19, 2019 08:10 PM

I am happy to announce that my team is ready to deploy a new version of our GitHub Sync Toolset on November 26, 2019 from 10:00 to 11:00 am EST.

We are not expecting any disruption of service but it’s possible that some committers may lose write access to their Eclipse project GitHub repositories during this 1 hour maintenance window.

This toolset is responsible for syncronizing Eclipse committers accross all our GitHub repositories and on top of that, this new release will start syncronizing contributors.

In this context, a contributor is a GitHub user with read access to the project GitHub repositories. This new feature will allow committers to assign issues to contributors who currently don’t have write access to the repository. This feature was requested in 2015 via Bug 483563 - Allow assignment of GitHub issues to contributors.

Eclipse Committers are reponsible for maintaining a list of GitHub contributors from their project page on the Eclipse Project Management Infrastructure (PMI).

To become an Eclipse contributor on a GitHub for a project, please make sure to tell us your GitHub Username in your Eclipse account.


November 19, 2019 08:10 PM

Jakarta EE Community Update November 2019

by Tanja Obradovic at November 19, 2019 06:52 PM

Now that Jakarta EE 8 has been available for a couple of months, I want to share news about some of the great committee work that’s been happening. I also want to tell you about our latest Jakarta EE-compatible product, and make sure you have links to the recordings of our Jakarta EE community calls and presentations.

 Due to the timing of this update, I’ve included news about activities in the first half of November as well as October.

 

Another Jakarta EE-Compatible Product

I’m very pleased to tell you that Payara Server is now fully certified as a Jakarta EE 8-compatible implementation. If you’re not familiar with Payara Server, take a few minutes to learn more about this innovative, cloud native application server.

 The Payara team told us they found the compatibility process smooth and easy. To learn more about the benefits of being certified as a Jakarta EE-compatible product and the process to get listed, click here.

 

Jakarta EE 8 Feedback Will Drive Improvements

The Jakarta EE Steering Committee started a community retrospective on the Jakarta EE 8 release, sharing this document to drive the process.

You’ll also see retrospectives from each of the other Jakarta EE Working Group committees as they look to gather community input on improvements for the next release. Once all of the input is collected, we’ll summarize and publish the findings.

 

Jakarta EE 9 Delivery Plan to Be Ready December 9

Jakarta EE 9 planning is underway, and the Steering Committee has published a resolution requesting Jakarta EE Platform Project leaders to deliver a Jakarta EE 9 Delivery Plan, including a release date, to the Steering Committee no later than December 9, 2019.

 According to the resolution, the Jakarta EE 9 Delivery Plan should:

  • Implement the “big bang”
  • Include an explicit means to identify and enable specifications that are unnecessary or unwanted to be deprecated or removed 
  • Move all remaining specification APIs to the Jakarta namespace
  • Add no new specifications, apart from those pruned from Java SE 8 where appropriate, unless those specifications will not impact the target delivery date

The resolution is now with the Jakarta EE Platform Project team, which is actively looking into the Steering Committee requests. The Platform Project team will put a higher priority on meeting the Steering Committee resolution requests as soon as possible rather than adding more functionality to the release.

 You can read the minutes of the Jakarta EE Platform Project team meetings here.

 

New Chair for the Jakarta EE Specification Committee

We welcome Paul Buck as the non-voting Chair of the Jakarta EE Specification Committee. Paul is Vice President of Community Development at the Eclipse Foundation, and was unanimously elected to his new role.

 

Jakarta EE 8 Restructuring Continues

In the push to complete Jakarta EE 8, a number of planned improvements were deferred. Here’s a brief summary of the improvements the Jakarta EE Specification Committee is currently discussing:

  • Updating project ids and technical namespaces. For example:
    • ee4j.jms becomes ee4j.messaging
    • https://github.com/eclipse-ee4j/jms-api becomes https://github.com/eclipse-ee4j/messaging-api
    • javax.jms becomes jakarta.messaging
  • Updating project names. For example:
    • Jakarta Server Faces becomes Jakarta Faces
  • Whether top-level projects should be changed to include both specifications and compatible implementations as subpages
  • How to address the decision to rename TCK files from “eclipse-” to “jakarta-”

 

Time to Jakartify More Specifications

When Jakarta EE 8 was released, we provided specifications for the Jakarta EE Full Profile and Jakarta EE Web Profile. Now that we’ve acquired the copyright for additional specifications, it’s time for the community to Jakartify them so they can be contributed to Jakarta EE.

 

To help you get started:

And, here’s the list of specifications that are ready for the community to "Jakartify":

•    Jakarta Annotations

•    Jakarta Enterprise Beans

•    Jakarta Expression Language

•    Jakarta Security

•    Jakarta Server Faces

•    Jakarta Interceptors

•    Jakarta Authorization

•    Jakarta Activation

•    Jakarta Managed Beans

 

•    Jakarta Deployment

•    Jakarta XML RPC

•    Jakarta Authentication

•    Jakarta Mail

•    Jakarta XML Binding

•    Jakarta RESTful Web Services

•    Jakarta Web Services Metadata

•    Jakarta XML Web Services

•    Jakarta Connectors

 

•    Jakarta Persistence

•    Jakarta JSON Binding

•    Jakarta JSON Processing

•    Jakarta Debugging Support for Other Languages

•    Jakarta Server Pages

•    Jakarta Transactions

•    Jakarta WebSocket

 

 

On a related note, the Specification Committee is also working to further define compatibility testing requirements for the full platform and web profile specifications for subsequent releases of Jakarta EE-compatible products.

 

Jakarta EE Marketing Plan Nearly Finalized

We expect the Jakarta EE 2020 marketing plan and budget to be approved by the end of November.

The Marketing Committee is also looking to choose a Committee Chair very soon. In the meantime, the Eclipse Foundation will be actively participating in KubeCon, NA. If you’re there, be sure to drop by booth S5 to talk to our technical experts and check out the demos on the cloud native Java projects.

 

Join Community Update Calls

Every month, the Jakarta EE community holds a Community Call for everyone in the Jakarta EE community. For upcoming dates and connection details, see the Jakarta EE Community Calendar.

 We know it’s not always possible to join calls in real time, so here are links to the recordings and presentations:

 

A Look Back at October Events

October was another busy month for Jakarta EE and cloud native Java events as we participated in. Beside EclipseCon Europe 2019, we were present at Trondheim Developer Conference in Norway, Open Source Summit EU in France, SpringOne Platform, Think London - UK and Joker<?> - Russia.

In addition to many reports and blogs you may find on the participation, I would like to point out the ECE 2019 Community Day collaboration between IoT and Cloud Native Java teams. Even though it was just a starting point attempt to work on the solution by both teams, it was great seeing two Eclipse Foundation communities working together! I am looking for more of these collaborations in the future. Please look for blog from Jens Reimann (@ctron) from Red Hat on this. 

 

Stay Connected With the Jakarta EE Community

The Jakarta EE community is very active and there are a number of channels to help you stay up to date with all of the latest and greatest news and information. Tanja Obradovic’s blog summarizes the community engagement plan, which includes:

•      Social media: Twitter, Facebook, LinkedIn Group

•      Mailing lists: jakarta.ee-community@eclipse.org and jakarta.ee-wg@eclipse.org

•      Newsletters, blogs, and emails: Eclipse newsletter, Jakarta EE blogs, monthly update emails to jakarta.ee-community@eclipse.org, and community blogs on “how are you involved with Jakarta EE”

•      Meetings: Jakarta Tech Talks, Jakarta EE Update, Jakarta Town Hall, and Eclipse Foundation events and conferences

 

Subscribe to your preferred channels today. And, get involved in the Jakarta EE Working Group to help shape the future of open source, cloud native Java.

 

To learn more about Jakarta EE-related plans and check the date for the next Jakarta Tech Talk, be sure to bookmark the Jakarta EE Community Calendar.


by Tanja Obradovic at November 19, 2019 06:52 PM

Jakarta Microprofile REST Client in Eclipse

by Christian Pontesegger (noreply@blogger.com) at November 18, 2019 11:19 AM

Today we are going to implement a simple REST client for an Eclipse RCP application. Now with Jakarta @ Eclipse and all these nice Microprofile implementations this should be a piece of cake, right? Now lets see...

Source code for this tutorial is available on github as a single zip archive, as a Team Project Set or you can browse the files online.

Step 1: Dependencies

The Eclipse Microprofile REST Client repository is a good place to get started. It points to several implementations (at the bottom of the readme). Unfortunately these implementations do not host any kind of p2 sites which we could use directly. So our next stop is Eclipse Orbit, but same situation there. This means we need to collect our dependencies manually.

For my example I used RESTEasy, simply as it was the only one I could get working within reasonable time. To fetch dependencies, download the latest version of RESTEasy. As the RESTEasy download package does not contain the REST client API, we need to fetch that from another source. I found it in the Apache CXF project, so download the latest version too. If you know a better source, please let me know in the comments.

Now create a new Plug-in from Existing JAR Archives. Click on Add External... and add all jars from resteasy-jaxrs-x.y.z.Final/lib/*.jar. Further add apache-cxf-x.y.z/lib/jakarta.ws.rs-api-x.y.z.jar.
This plug-in now contains all dependencies we need for our client. Unfortunately also a lot of other stuff we probably do not need, but we leave the cleanup for later.

Step 2: Define the REST service

For our example we will build a client for the Petstore Service, which can be used for testing purposes. Further it provides a swagger interface to test the REST calls online. I recommend to check out the API and play with some commands online and with curl.

Lets write a simple client for the store with its 4 commands. The simplest seems to be the inventory command, so we will start there. Create a new Java interface:
package com.codeandme.restclient.resteasy;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;

public interface IStoreService {

@GET
@Path("/v2/store/inventory")
@Produces(MediaType.APPLICATION_JSON)
Response getInventory();
}
Everything necessary for RESTEasy is provided via annotations:

  • @Path defines the path for the command of the REST service
  • @GET defines that we have to use a GET command (there exist annotations for POST, DELETE, PUT)
  • @Produces finally defines the type of data we do get in response from the server.
Step 3: Create an instance of the service

Create a new class StoreServiceFactory:
package com.codeandme.restclient.resteasy;

import java.net.URI;
import java.net.URISyntaxException;

import org.jboss.resteasy.client.jaxrs.ResteasyClient;
import org.jboss.resteasy.client.jaxrs.ResteasyWebTarget;
import org.jboss.resteasy.client.jaxrs.internal.ResteasyClientBuilderImpl;

public class StoreServiceFactory {

public static IStoreService createStoreService() throws URISyntaxException {
ResteasyClient client = new ResteasyClientBuilderImpl().build();
ResteasyWebTarget target = client.target(new URI("https://petstore.swagger.io/"));
return target.proxy(IStoreService.class);
}
}

This is the programmatic way to create a client instance. There also exists another method called CDI, which I did not try out in Eclipse.

The service is ready and usable, so give it a try. The result object returned does contain some valuable information:

  • getStatus() provides the HTTP response status. 200 is expected for a successful getInventory()
  • getEntity() provides an InputStream which contains the JSON encoded response data from the server
Step 4: Response decoding

Our response is encoded as JSON collection of properties. In Java terms this basically reflects to a Map<String, String>. Instead of decoding the data manually, we let the framework do it for us:

Change the IStoreService to:

 Map<String, String> getInventory();
Anything else is done by the framework. Now how easy was that?

Step 5: POST request

To place an order we need order parameters. Best we encapsulate them in a dedicated Order class. From the definition of the order REST call we can see that we need following class properties: id, petId, quantity, shipDate, status, complete. Add these parameters as fields to the Order class and create getters/setters for them.

Now we can extend our IStoreService with the fileOrder() call:


@Path("/v2/store")
public interface IStoreService {

@GET
@Path("inventory")
@Produces(MediaType.APPLICATION_JSON)
Map<String, String> getInventory();

@POST
@Path("order")
@Consumes(MediaType.APPLICATION_JSON)
void fileOrder(Order order);
}

The Order automatically gets encoded as JSON object. No need for us to do the coding manually!

As parts of the path are the same for both calls, I moved the common component to the class level.

Step 6: Path parameters

To fetch an order we need to put the orderId in the request path. Coding of such parameters is put in curly braces. The parameter on the java call then gets annotated so the framework knows which parameter value to put into the path:

 @GET
@Path("order/{orderId}")
@Produces(MediaType.APPLICATION_JSON)
Order getOrder(@PathParam("orderId") int orderId);

Again the framework takes care of the decoding of the JSON data.

Step 7: DELETE an Order

Deleting needs the orderId as before:

 @DELETE
@Path("order/{orderId}")
void deleteOrder(@PathParam("orderId") int orderId);

The REST API does not provide a useful JSON response to the delete call. One option is to leave the response type to void. In case the command fails, an exception will be thrown (eg when the orderId is not found and the server returns 404).

Another option is to set the return type to javax.ws.rs.core.Response. Now we do get everything the server sends back and no execption is thrown anymore. Sometimes we might only be interested in the status code. This can be fetched when setting the return type to Response.Status. Again, no exception will be thrown on a 404.

Optional: Only have required RESTEasy dependencies

Looking at all these jars I could not figure out a good way to get rid of the ones unused by the REST client. So I provided unit tests for all my calls and then removed dependencies step by step until I found the minimal set of required jars.




by Christian Pontesegger (noreply@blogger.com) at November 18, 2019 11:19 AM

Show Your Support for Open Source IoT at the Eclipse Foundation

November 14, 2019 04:35 PM

The Eclipse IoT working group is launching a campaign to identify the adopters of Eclipse IoT open source projects. Companies — whether or not they are working group members — can be listed as adopters.

Adopters are organizations that voluntarily show their support for the Eclipse IoT projects they have adopted (i.e. shipping commercial products based on the projects and/or using the projects for non-commercial or internal reasons).

You can add your organization logo to our list of adopters by submitting a pull request or by creating an issue. You can attach files to an issue by dragging and dropping them in the text editor of the form.

If you plan on submitting a pull request, you will need to make the following changes to the website codebase:

  1. Add a colored and a white organization logo to static/assets/images/adoptors. We expect that all submitted logos to be transparent svg.
  2. Update the adopter data file: data/adopters.yml If your organization wishes to express support for multiple projects, you will need to add your organization’s YAML definition to the adopters list of each of the relevant project nodes.

Your participation in this initiative will publicly show your support for open source innovation.

List Eclipse IoT adopters on an Eclipse project website

Eclipse projects can showcase the logos of their adopters on their project websites. We built a JavaScript plugin to make this process easier. If you are a project committer, here are quick instructions on how to use the eclipsefdn-adopters.js on your Eclipse project website:

Usage

Include the plugin’s JS in the section of the page:

<script src="//iot.eclipse.org/assets/js/eclipsefdn.adopters.js"></script>

Load the plugin:

<script>
eclipseFdnAdopters.getList({
project_id: "[project_id]"
});
</script>

Create an HTML element containing the chosen selector:

<div class="eclipsefdn-adopters"></div>
  • By default, the selector’s value is eclipsefdn-adopters.

Options

<script>
eclipseFdnAdopters.getList({
project_id: "[project_id]",
selector: ".eclipsefdn-adopters",
ul_classes: "list-inline",
logo_white: false
});
</script>
Attribute Type Default Description
project_id String Required: Select adopters from a specific project ID.
selector String .eclipsefdn-adopters Define the selector that the plugin will insert adopters into.
ul_classes String Define classes that will be assigned to the ul element.
logo_white Boolean false Whether or not we use the white version of the logo.

November 14, 2019 04:35 PM

New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09

by Jeff Maury at November 11, 2019 07:30 AM

JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 for Eclipse 2019-09 are here and waiting for you. In this article, I’ll cover the highlights of the new releases and show how to get started.

Installation

Red Hat CodeReady Studio (previously known as Red Hat Developer Studio) comes with everything pre-bundled in its installer. Simply download it from our Red Hat CodeReady Studio product page and run it like this:

java -jar codereadystudio-<installername>.jar

JBoss Tools or Bring-Your-Own-Eclipse (BYOE) CodeReady Studio requires a bit more.

This release requires at least Eclipse 4.13 (2019-09), but we recommend using the latest Eclipse 4.13 2019-09 JEE Bundle because then you get most of the dependencies pre-installed.

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

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

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

What’s new?

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

Red Hat OpenShift

OpenShift Container Platform 4.2 support

With the new OpenShift Container Platform (OCP) 4.2 now available (see the announcement), even if this is a major shift compared to OCP 3, Red Hat CodeReady Studio and JBoss Tools are compatible with this major release in a transparent way. Just define your connection to your OCP 4.2 based cluster as you did before for an OCP 3 cluster, and use the tooling!

CodeReady Containers 1.0 Server Adapter

A new server adapter has been added to support the next generation of CodeReady Containers 1.0. Although the server adapter itself has limited functionality, it is able to start and stop the CodeReady Containers virtual machine via its crc binary. Simply hit Ctrl+3 (Cmd+3 on OSX) and type new server, which will bring up a command to set up a new server.

crc server adapter

Enter crc in the filter textbox.

You should see the Red Hat CodeReady Containers 1.0 server adapter.

Select Red Hat CodeReady Containers 1.0 and click Next.

All you have to do is set the location of the CodeReady Containers crc binary file and the pull secret file location, which can be downloaded from https://cloud.redhat.com/openshift/install/crc/installer-provisioned.

Once you’re finished, a new CodeReady Containers server adapter will then be created and visible in the Servers view.

Once the server is started, a new OpenShift connection should appear in the OpenShift Explorer view, allowing the user to quickly create a new Openshift application and begin developing their AwesomeApp in a highly replicatable environment.

Server tools

Wildfly 18 Server Adapter

A server adapter has been added to work with Wildfly 18. It adds support for Java EE 8 and Jakarta EE 8.

EAP 7.3 Beta Server Adapter

A server adapter has been added to work with EAP 7.3 Beta.

Hibernate Tools

Hibernate Runtime Provider Updates

A number of additions and updates have been performed on the available Hibernate runtime providers.

The Hibernate 5.4 runtime provider now incorporates Hibernate Core version 5.4.7.Final and Hibernate Tools version 5.4.7.Final.

The Hibernate 5.3 runtime provider now incorporates Hibernate Core version 5.3.13.Final and Hibernate Tools version 5.3.13.Final.

Platform

Views, Dialogs and Toolbar

The new Quick Search dialog provides a convenient, simple and fast way to run a textual search across your workspace and jump to matches in your code. The dialog provides a quick overview showing matching lines of text at a glance. It updates as quickly as you can type and allows for quick navigation using only the keyboard. A typical workflow starts by pressing the keyboard shortcut Ctrl+Alt+Shift+L (or Cmd+Alt+Shift+L on Mac). Typing a few letters updates the search result as you type. Use Up-Down arrow keys to select a match, then hit Enter to open it in an editor.

Save editor when Project Explorer has focus

You can now save the active editor even when the Project Explorer has focus. In cases where an extension contributes Saveables to the Project Explorer, the extension is honored and the save action on the Project Explorer will save the provided saveable item instead of the active editor.

“Show In” context menu available for normal resources

The Show In context menu is now available for an element inside a resource project on the Project Explorer.

Show colors for additions and deletions in Compare viewer

In simple cases such as a two-way comparison or a three-way comparison with no merges and conflicts, the Compare viewer now shows different colors, depending on whether text has been added, removed, or modified. The default colors are green, red, and black, respectively.

The colors can be customized through usual theme customization approaches, including using related entries in the Colors and Fonts preference page.

Editor status line shows more selection details

The status line for Text Editors now shows the cursor position, and when the editor has something selected, it shows the number of characters in the selection as well. This also works in the block selection mode.

These two new additions to the status line can be disabled via the General > Editors > Text Editors preference page.

Shorter dialog text

Several dialog texts have been shortened. This allows you to capture important information faster.

Previously:

Now:

Close project via middle-click

In the Project Explorer, you can now close a project using middle-click.

Debug

Improved usability of Environment tab in Launch Configurations

In the Environment tab of the Launch Configuration dialog, you can now double-click on an environment variable name or value and start editing it directly from the table.

Right-clicking on the environment variable table now opens a context menu, allowing for quick addition, removal, copying, and pasting of environment variables.

Show Command Line for external program launch

The External Tools Configuration dialog for launching an external program now supports the Show Command Line button.

Preferences

Close editors automatically when reaching 99 open editors

The preference to close editors automatically is now enabled by default. It will be triggered when you have opened 99 files. If you continue to open editors, old editors will be closed to protect you from performance problems. You can modify this setting in the Preferences dialog via the General > Editors > Close editors automatically preference.

In-table color previews for Text Editor appearance color options

You can now see all the colors currently being used in Text Editors from the Appearance color options table, located in the Preferences > General > Editors > Text Editor page.

Automatic detection of UI freezes in the Eclipse SDK

The Eclipse SDK has been configured to show stack traces for UI freezes in the Error Log view by default for new workspaces. You can use this information to identify and report slow parts of the Eclipse IDE.

You can disable the monitoring or tweak its settings via the options in the General > UI Responsiveness Monitoring preference page as shown below.

Themes and Styling

Start automatically in dark theme based on OS theme

On Linux and Mac, Eclipse can now start automatically in dark theme when the OS theme is dark. This works by default, that is on a new workspace or when the user has not explicitly set or changed the theme in Eclipse.

Display of Help content respects OS theme

More and more operating systems provide a system-wide dark theme. Eclipse now respects this system-wide theme setting when the Eclipse help content is displayed in an external browser. A prerequisite for this is a browser that supports the prefers-color-scheme CSS media query.

As of the time of writing, the following browser versions support it:

  • Firefox version 67
  • Chrome version 76
  • Safari version 12.1

Help content uses high-resolution icons.

The Help System, as well as the help content of the Eclipse Platform, the Java Development Tooling, and the Plug-in Development Environment, now uses high-resolution icons. They are now crisp on high-resolution displays and also look much better in the dark theme.

Improved dark theme on Windows

Labels, Sections, Checkboxes, Radio Buttons, FormTexts, and Sashes on forms now use the correct background color in the dark mode on windows.

General Updates

Interactive performance

Interactive performance has been further improved in this release and several UI freezes have been fixed.

Show key bindings when command is invoked

For presentations, screencasts, and learning purposes, it is very helpful to show the corresponding key binding when a command is invoked. When the command is invoked (via a key binding or menu interaction) the key binding, the command’s name and description are shown on the screen.

You can activate this in the Preferences dialog via the Show key binding when command is invoked checkbox on the General > Keys preference page. To toggle this setting quickly, you can use the Toggle Whether to Show Key Binding command (e.g., via the quick access).

Java Developement Tools (JDT)

Java 13 Support

Java 13 is out, and Eclipse JDT supports Java 13 for 4.13 via Marketplace.

The release notably includes the following Java 13 features:

  • JEP 354: Switch Expressions (Preview).
  • JEP 355: Text Blocks (Preview).

Please note that these are preview language features; hence, the enable preview option should be on. For an informal introduction of the support, please refer to Java 13 Examples wiki.

Java Views and Dialogs

Synchronize standard and error output in console

The Eclipse Console view currently can not ensure that mixed standard and error output is shown in the same order as it is produced by the running process. For Java applications, the launch configuration Common tab now provides an option to merge standard and error output. This ensures that standard and error output is shown in the same order it was produced but also disables the individual coloring of error output.

Java Editor

Convert to enhanced ‘for’ loop using Collections

The Java quickfix/cleanup Convert to enhanced ‘for’ loop is now offered on for loops that are iterating through Collections. The loop must reference the size method as part of the condition and if accessing elements in the body, must use the get method. All other Collection methods other than isEmpty invalidate the quickfix being offered.

Initialize ‘final’ fields

A Java quickfix is now offered to initialize an uninitialized final field in the class constructor. The fix will initialize a String to the empty string, a numeric base type to 0, and, for class fields, it initializes them using their default constructor if available or null if no default constructor exists.

Autoboxing and Unboxing

Use Autoboxing and Unboxing when possible. These features are enabled only for Java 5 and higher.

Improved redundant modifier removal

The Remove redundant modifier now also removes useless abstract modifier on the interfaces.

For the given code:

You get this:

Javadoc comment generation for module

Adding a Javadoc comment to a Java module (module-info.java) will result in automatic annotations being added per the new module comment preferences.

The $(tags) directive will add @uses and @provides tags for all uses and provides module statements.

Chain Completion Code Assist

Code assist for “Chain Template Proposals” will be available. These will traverse reachable local variables, fields, and methods, to produce a chain whose return type is compatible with the expected type in a particular context.

The preference to enable the feature can be found in the Advanced sub-menu of the Content Assist menu group (Preferences > Java > Editor > Content Assist > Advanced).

Java Formatter

Remove excess blank lines

All the settings in the Blank lines section can now be configured to remove excess blank lines, effectively taking precedence over the Number of empty lines to preserve setting. Each setting has its own button to turn the feature on, right next to its number control. The button is enabled only if the selected number of lines is smaller than the Number of empty lines to preserve; otherwise, any excess lines are removed anyway.

Changes in blank lines settings

There’s quite a lot of changes in the Blank lines section of the formatter profile.

Some of the existing subsections and settings are now phrased differently to better express their function:

  • The Blank lines within class declarations subsection is now Blank lines within type declaration.
  • Before first declaration is now Before first member declaration.
  • Before declarations of the same kind is now Between member declarations of different kind.
  • Before member class declarations is now Between member type declarations.
  • Before field declarations is now Between field declarations.
  • Before method declarations is now Between method/constructor declarations.

More importantly, a few new settings have been added to support more places where the number of empty lines can be controlled:

  • After last member declaration in a type (to complement previously existing Before first member declaration setting).
  • Between abstract method declarations in a type (these cases were previously handled by Between method/constructor declarations).
  • At end of method/constructor body (to complement previously existing At beginning of method/constructor body setting).
  • At beginning of code block and At end of code block.
  • Before statement with code block and After statement with code block.
  • Between statement groups in ‘switch.’

Most of the new settings have been put in a new subsection Blank lines within method/constructor declarations.

JUnit

JUnit 5.5.1

JUnit 5.5.1 is here and Eclipse JDT has been updated to use this version.

Debug

Enhanced support for –patch-module during launch

The Java Launch Configuration now supports patching of different modules by different sources during the launch. This can be verified in the Override Dependencies…​ dialog in the Dependencies tab in a Java Launch Configuration.

Java Build

Full build on JDT core preferences change

Manually changing the settings file .settings/org.eclipse.jdt.core.prefs of a project will result in a full project build, if the workspace auto-build is on. For example, pulling different settings from a git repository or generating the settings with a tool will now trigger a build. Note that this includes timestamp changes, even if actual settings file contents were not changed.

For the 4.13 release, it is possible to disable this new behavior with the VM property: -Dorg.eclipse.disableAutoBuildOnSettingsChange=true. It is planned to remove this VM property in a future release.

And more…​

You can find more noteworthy updates in on this page.

What is next?

Having JBoss Tools 4.13.0 and Red Hat CodeReady Studio 12.13 out we are already working on the next release for Eclipse 2019-12.

Share

The post New features in Red Hat CodeReady Studio 12.13.0.GA and JBoss Tools 4.13.0.Final for Eclipse 2019-09 appeared first on Red Hat Developer.


by Jeff Maury at November 11, 2019 07:30 AM

Getting to the Source

by Ed Merks (noreply@blogger.com) at November 08, 2019 09:04 AM

As a Java developer using JDT, no doubt you are intimately familiar with Ctrl-Shift-T to launch the Open Type dialog.  You might not even realize this is a shortcut accessible via the Navigate menu.  So you probably will not have noticed that this menu also contains Open Discovered Type:


Eclipse has a huge variety of open source projects maintained in a bewildering collection of Git repositories.  Many are hosted at Eclipse:
https://git.eclipse.org/c/
Others are hosted at Github:
https://github.com/eclipse/

Finding the Git repository that contains a particular Java class is like finding a needle in a haystack.  This is where Open Discovered Type comes to the rescue.  Once a week, Oomph indexes every *.java file in every Git repository hosted by git.eclipse.org and github.com/eclipse.  The Open Discovered Type dialog loads this information to populate a tree view of all these packages and classes.


Please read the help information the first time you use it.  It was written to help you get the most out of this dialog.  Also be patient the first time you launch the dialog; there's a lot of information to download.

Suffice to say, you can use the dialog much like you do Open Type.  So here we search for JavaCore and discover all the classes with that name:


We can select any one of them and discover all the Git repositories containing that class and we can use the context menu for each link for each repository or for the specific file in that repository to open the link where we want it opened.  From that link, you can of course see the full history of the repository or specific file.

As a bonus, if this repository provides an Oomph setup, you can easily use that Oomph setup to import the sources for this project into your workspace. If there is no Oomph setup, you'll have to do that manually.

In any case, contributing to Eclipse open source projects has never been easier.

by Ed Merks (noreply@blogger.com) at November 08, 2019 09:04 AM

Eclipse startup up time improved

November 05, 2019 12:00 AM

I’m happy to report that the Eclipse SDK integration builds starts in less than 5 seconds (~4900 ms) on my machine into an empty workspace. IIRC this used to be around 9 seconds 2 years ago. 4.13 (which was already quite a bit improved used around 5800ms (6887ms with EGit and Marketplace). For recent improvements in this release see https://bugs.eclipse.org/bugs/show_bug.cgi?id=550136 Thanks to everyone who contributed.

November 05, 2019 12:00 AM

Announcing Ditto Milestone 1.0.0-M2

November 04, 2019 05:00 AM

The second and last milestone of the upcoming release 1.0.0 was released today.

Have a look at the Milestone 1.0.0-M2 release notes for what changed in detail.

The main changes and new features since the last release 1.0.0-M1a release notes are

  • invoking custom foreign HTTP endpoints as a result of events/messages
  • ability to reflect Eclipse Hono’s device connection state in Ditto’s things
  • support for OpenID Connect / OAuth2.0 based authentication in Ditto Java Client
  • configurbale throttling of max. consumed WebSocket commands / time interval

Artifacts

The new Java artifacts have been published at the Eclipse Maven repository as well as Maven central.

The Docker images have been pushed to Docker Hub:



Ditto


The Eclipse Ditto team


November 04, 2019 05:00 AM

Setup a Github Triggered Build Machine for an Eclipse Project

by Jens v.P. (noreply@blogger.com) at October 29, 2019 12:55 PM

Disclaimer 1: This blog post literally is a "web log", i.e., it is my log about setting up a Jenkins machine with a job that is triggered on a Github pull request. A lot of parts have been described elsewhere, and I link to the sources I used here. I also know that nowadays (e.g., new Eclipse build infrastructure) you usually do that via docker -- but then you need to configure docker, in which

by Jens v.P. (noreply@blogger.com) at October 29, 2019 12:55 PM

LiClipse 6.0.0 released

by Fabio Zadrozny (noreply@blogger.com) at October 25, 2019 06:59 PM

LiClipse 6.0.0 is now out.

The main changes is that many dependencies have been updated:

- it's now based on Eclipse 4.13 (2019-09), which is a pretty nice upgrade (in my day-to-day use I find it appears smoother than previous versions, although I know this sounds pretty subjective).

- PyDev was updated to 7.4.0, so, Python 3.8 (which was just released) is now already supported.

Enjoy!

by Fabio Zadrozny (noreply@blogger.com) at October 25, 2019 06:59 PM

Running a CI system is hard? It doesn't have to be.

by Denis Roy at October 23, 2019 09:44 AM

At EclipseCon Europe 2019 I attended a very interesting talk entitled "CI systems need care, too! Here's how we improved ours over the years". It was an eye opener! Here's what I gathered.

  • New developer comes to a Company
  • Company sells a software product built by a CI system
  • The CI system is a cobbled hack
  • Developer raises awareness that
    • CI is important
    • Fast CI feedback loop is important
    • CI is on the criticali path to profit (delivering the product)
  • Developer becomes an IT sysadmin and a Release Engineer to fix the CI, thus distracted from the actual task of improving the product.

The Eclipse CBI project (Common Build Infra) has been solving these problems for over 12 years. If you can relate to the unfortunate scenario above, here's what I can suggest:

  • Host your code at the Eclipse Foundation.
    • With IT and Release Engineers on staff, you can focus on code, not the build.
    • With Best Practices, we can help with your build so you can focus on code.
  • If you must fix your CI system yourself:
    • Come to EclipseCon. Seriously, we'll save you so much more than the price of admission.
    • Check out the Eclipse CBI project
    • Browse the Foundation's YouTube channel, there are a number of CBI talks that can be beneficial.

 

We've all been guilty of reinventing the wheel. Let's not do that. We're here to help (slides to come).


by Denis Roy at October 23, 2019 09:44 AM

Qt World Summit 2019 Berlin – Secrets of Successful Mobile Business Apps

by ekkescorner at October 22, 2019 12:39 PM

Qt World Summit 2019

Meet me at Qt World Summit 2019 in Berlin

QtWS19_globe

I’ll speak about development of mobile business apps with

  • Qt 5.13.1+ (Qt Quick Controls 2)
    • Android
    • iOS
    • Windows 10

ekkes_session_qtws19

Qt World Summit 2019 Conference App

As a little appetizer I developed a conference app. HowTo download from Google Play Store or Apple and some more screenshots see here.

02_sessions_android

sources at GitHub

cu in Berlin


by ekkescorner at October 22, 2019 12:39 PM

Send web requests and assert results with vertx-junit5-web-client

by slinkydeveloper at October 22, 2019 12:00 AM

In last Vert.x 3.8 release we added a new module called vertx-junit5-web-client, that brings Vert.x Web Client injection into tests and provides an API called TestRequest to simplify the creation and assertions on WebClient requests:

import static io.vertx.junit5.web.TestRequest.*;

@ExtendWith({
  VertxExtension.class, // VertxExtension MUST be configured before VertxWebClientExtension
  VertxWebClientExtension.class
})
public class TestRequestExample {

  @Test
  public void test1(WebClient client, VertxTestContext testContext) {
    testRequest(client, HttpMethod.GET, "/hello") // Build the request
      .with(
        queryParam("name", "francesco"), // Add query param
        requestHeader("x-my", "foo") // Add request header
      )
      .expect(
        // Assert that response is a JSON with a specific body
        jsonBodyResponse(new JsonObject().put("value", "Hello Francesco!")),
        // Assert that response contains a particular header
        responseHeader("x-my", "bar")
      )
      .send(testContext); // Complete (or fail) the VertxTestContext
  }

}

testRequest() will use Vert.x Web Client to send the request. When the response is received, It succeds the test or it correctly propagates assertion failures, if any.

You can also send multiple requests using Checkpoint:

import static io.vertx.junit5.web.TestRequest.*;

@ExtendWith({
  VertxExtension.class, // VertxExtension MUST be configured before VertxWebClientExtension
  VertxWebClientExtension.class
})
public class MultiTestRequestExample {

  @Test
  public void test2(WebClient client, VertxTestContext testContext) {
    Checkpoint checkpoint = testContext.checkpoint(2); // Create the Checkpoint to flag when request succeds

    testRequest(
        client    // Create the test request using WebClient APIs
          .get("/hello")
          .addQueryParam("name", "francesco")
          .putHeader("x-my", "foo")
      )
      .expect(
        jsonBodyResponse(new JsonObject().put("value", "Hello Francesco!")),
        responseHeader("x-my", "bar")
      )
      .send(testContext, checkpoint); // Pass the checkpoint to flag

    testRequest(
        client
          .get("/hello")
          .addQueryParam("name", "julien")
          .putHeader("x-my", "foo")
      )
      .expect(
        jsonBodyResponse(new JsonObject().put("value", "Hello Julien!")),
        responseHeader("x-my", "bar")
      )
      .send(testContext, checkpoint);
  }

}

Look at Vert.x JUnit 5 Web Client documentation for more details


by slinkydeveloper at October 22, 2019 12:00 AM

A nicer icon for Quick Access / Find Actions

October 20, 2019 12:00 AM

Finally we use a decent icon for Quick Access / Find Actions. This is now a button in the toolbar which allows you to trigger arbitrary commands in the Eclipse IDE.

October 20, 2019 12:00 AM

A Tool for Jakarta EE Package Renaming in Binaries

by BJ Hargrave (noreply@blogger.com) at October 17, 2019 09:26 PM

In a previous post, I laid out my thinking on how to approach the package renaming problem which the Jakarta EE community now faces. Regardless of whether the community chooses big bang or incremental, there are still existing artifacts in the world using the Java EE package names that the community will need to use together with the new Jakarta EE package names.

Tools are always important to take the drudgery away from developers. So I have put together a tool prototype which can be used to transform binaries such as individual class files and complete JARs and WARs to rename uses of the Java EE package names to their new Jakarta EE package names.

The tools is rule driven which is nice since the Jakarta EE community still needs to define the actual package renames for Jakarta EE 9. The rules also allow the users to control which class files in a JAR/WAR are transformed. Different users may want different rules depending upon their specific needs. And the tool can be used for any package renaming challenge, not just the specific Jakarta EE package renames.

The tools provides an API allowing it to be embedded in a runtime to dynamically transform class files during the class loader definition process. The API also supports transforming JAR files. A CLI is also provided to allow use from the command line. Ultimately, the tool can be packaged as Gradle and Maven plugins to incorporate in a broader tool chain.

Given that the tool is prototype, and there is much work to be done in the Jakarta EE community regarding the package renames, I have started a list of TODOs in the project' issues for known work items.

Please try out the tool and let me know what you think. I am hoping that tooling such as this will ease the community cost of dealing with the package renames in Jakarta EE.

PS. Package renaming in source code is also something the community will need to deal with. But most IDEs are pretty good at this sort of thing, so I think there is probably sufficient tooling in existence for handling the package renames in source code.

by BJ Hargrave (noreply@blogger.com) at October 17, 2019 09:26 PM

I’ll never forget that first EclipseCon meeting with you guys and Disney characters all around and…

by Doug Schaefer at October 16, 2019 01:18 AM

I’ll never forget that first EclipseCon meeting with you guys and Disney characters all around and the music. And all the late nights in the Santa Clara bar and summits and meetings talking until no one else was left. Great times indeed. Until we meet again Michael!


by Doug Schaefer at October 16, 2019 01:18 AM

Missing ECE already? Bring back a little of it - take the survey!

by Anonymous at October 15, 2019 09:22 PM

We hope you enjoyed the 2019 version of EclipseCon Europe and OSGi Community Event as much as we did.

Please share your thoughts and feedback by completing the short attendee survey. We read all responses, and we will use them to improve next year's event.

Speakers, please upload your slides to your session page. Attendees really appreciate this!


by Anonymous at October 15, 2019 09:22 PM

Participate in the 2019 IoT Commercial Adoption Survey!!

October 10, 2019 03:30 PM

According to McKinsey, the Internet of Things (IoT) will have a total potential economic impact of up to $11.1 trillion a year by 2025.

October 10, 2019 03:30 PM

A Committer’s View of Our New ECD Tools Working Group

by Thabang Mashologu at October 10, 2019 01:48 PM

When you look at the very impressive list of founding members for our new Eclipse Cloud Development (ECD) Tools Working Group, it’s clear that world-leading technology companies strongly believe that open source, cloud native development tools are needed. Our Eclipse Foundation developer community has also enthusiastically embraced the initiative.

To get an insider’s view of why the ECD Tools Working Group initiative is so important, I recently talked to Carlos Andres De La Rosa, an active Eclipse Foundation committer, about why he is getting involved in the Working Group. Here’s an edited version of our conversation.

 

Q. How did you first become involved in the open source communities at the Eclipse Foundation?

 A. I was looking for something interesting from which I could learn something new related to cloud technologies. I found the Eclipse MicroProfile project about two years ago. That was a very interesting topic for me, especially the fault tolerance spec. I added my email address to the mailing list and started joining weekly calls. After a while, I started to contribute to the spec with different things, like improving the spec testing, adding and modifying documentation, and also debating about how to evolve the spec. I became a committer and an entire technological world opened up for me. Jakarta EE was another interesting project that got my attention, so then I became involved with the Jakarta EE community.

I like the fact that Eclipse projects are from the people, for the people, so anyone can learn and contribute to solve problems that can help a lot of developers around the world. It’s shared knowledge and that’s the most important thing for me.

 

Q. Why did you expand your involvement to include the ECD Tools Working Group?

 A. When you’re part of the community, you have access to beta versions of the specifications and projects. I was looking around and I learned about this new project for cloud development tools. I saw the charter and what people were trying to achieve and I knew I wanted to be part of it. It was that simple.

I think cloud technologies will be the biggest and most important topic for the next 10 years. Everything is moving to the cloud, so every day we have more applications, from banking to AI medical analysis services. And, people have easy access to all this thanks to the cloud. I want to be there at the forefront and be working for the community when cloud really starts to grow.

 

Q. What benefits do you expect to gain from your participation in the ECD Tools Working Group?

A. It’s a huge opportunity to learn from the best engineers in the world because there are a lot of great professionals at the Eclipse Foundation and they have a lot of experience driving technology forward. If you’re new to this field and you’re trying to learn new things, this is a big chance to do it. Also, I’m currently working as a cloud consultant and this project is very related to my day-to-day job, so I can use what I learn in this project to improve my consultancy services.

 

Q. What impact do you think the ECD Tools Working Group will have on open source, cloud native development?

A. I think the impact will be huge because this group will deliver all of the tools that will be used every day in cloud development. From deploy, scale, debug, and manage, to Cloud Foundry applications, everything is integrated with the Eclipse IDE making the job of developers more productive.

 

Q. How does your participation in the ECD Tools Working Group fit with the other cloud-related projects you’re involved with at the Eclipse Foundation?

A. Everything is related. MicroProfile provides implementations and specs for capabilities such as fault tolerance that are needed in a microservices architecture to make it easier for developers to create microservices. And the Jakarta EE specs are basically the foundation for the MicroProfile framework because MicroProfile depends on the Java enterprise specs. The Eclipse Cloud Development Tools is a complementary project that helps to complete the framework for cloud native applications. So, they are all part of the cloud ecosystem. 

I really think that MicroProfile, Jakarta EE, and now the Eclipse Cloud Development Tools Working Group are the three most important projects at the Eclipse Foundation right now. They will drive the future of cloud technologies and everything that is handled and developed by the community.

 

Q. What would you say to people who are considering joining the ECD Tools Working Group?

A. I would say “join now!” The most important thing I can tell people is get involved if you want to learn about a cutting-edge technology that will be driving peoples’ lives for a long time. And contribute to help create something meaningful. It’s a community, so it’s for everyone.


by Thabang Mashologu at October 10, 2019 01:48 PM

Jakarta EE Community Update October 2019

by Tanja Obradovic at October 09, 2019 05:07 PM

Welcome to the latest Jakarta EE community update. In this edition, we highlight key opportunities to participate in upcoming community events, explore the Jakarta EE 8 release, and learn more about the very bright future of cloud native Java.

EclipseCon Europe 2019: Register for Community Day

Community Day, which will be held Monday, October 21 at EclipseCon Europe, is a must for everyone who’s interested in our cloud native projects. The day is dedicated to community-organized meetings to discuss projects and technologies, provide workshops and coding sessions, hold working group gatherings, and more. Lunch and breaks are included, and the day ends with a casual reception.

There’s already a gathering planned for anyone interested in Jakarta EE, MicroProfile, Eclipse Jemo, Eclipse Che, Eclipse Codewind, and other cloud-related topics. To see the agenda so far, and add your ideas for discussion topics, check the EclipseCon Europe Community Day wiki.

 And, don’t forget to attend our new event this year — Community Evening on Tuesday, October 22. This is your opportunity to participate in more casual, interactive events and enjoy a beverage with your community colleagues. A bar offering beer, wine, water, and juice will be available. 

To register for EclipseCon Europe and for Community Day, click here.

__________________________

 JakartaOne Livestream Wrap-Up

The first-ever JakartaOne Livestream event was a huge success with more than 1,400 registered attendees. The online conference, held September 10, marked the release of the first vendor-neutral, Java EE 8-compatible release of Jakarta EE following the new Jakarta EE Specification Process.

We first knew this event would be bigger than expected when several well-respected leaders in the Java EE community graciously and enthusiastically agreed to join the JakartaOne Livestream Program Committee. Led by Committee Chair, Reza Rahman, committee members Adam Bien, Ivar Grimstad, Arun Gupta, Josh Juneau, along with Tanja Obradovic from the Eclipse Foundation, put in a huge effort to plan the conference.

One of the committees’ toughest jobs was selecting 16 conference papers for presentation from among the more than 50 high-quality submissions. Participants enjoyed a great mixture of introductory and overview sessions, including sessions on particular specifications, cloud native topics, keynotes from Mike Milinkovich and James Gosling, as well as industry keynotes from Jakarta EE Working Group Steering Committee members IBM, Fujitsu, Oracle, Payara, Red Hat, and Tomitribe. Demos, panel discussions, and Q&A sessions rounded out the 18 hours of program material that were delivered.

To see a list of the topics presented and access the session recordings, visit jakartaone.org.    

__________________________

Jakarta EE 8 Release Highlights

The Jakarta EE 8 release is now available with 43 projects, more than 60 million lines of code, and full compatibility with Java EE 8.

 With the delivery of the Jakarta EE 8 Platform, the entire ecosystem — from software vendors to developers and enterprises — has all of the pieces needed to shape the future of cloud native Java and meet the modern enterprise’s need for cloud-based applications that resolve key business challenges.

To ensure that cloud native Java applications are portable, secure, stable, and resilient, product compatibility certifications are underway. We already have three products that are certified as compatible with the full Jakarta EE 8 platform:

·      Eclipse GlassFish application server, version 5.1

·      IBM Open Liberty server runtime, version 19.0

·      Red Hat WildFly application server, version 17.0

Eclipse GlassFish and Open Liberty are also certified as Jakarta EE 8 web profile-compatible products.

Almost three dozen Jakarta EE specifications are also available. Jakarta projects are listed here and are included in our main project repository. It’s time for everyone to get involved in the cloud native Java community and engage in turning the huge potential for cloud native Java into reality.

__________________________

Our Free Cloud Native Java E-Book Is Now Available

To mark the significance of the Jakarta EE 8 release, we also released a free e-book, Fulfilling the Vision for Open Source, Cloud Native Java, on September 10. The e-book includes insights from some of the leading voices in enterprise Java and the Jakarta EE Working Group. It explores:

·      Why the world needs open source, cloud native Java

·      The common vision for cloud native Java that has emerged

·      The many benefits of cloud native Java for software vendors, developers, and enterprises

·      Why it’s time for all Java stakeholders to get involved in the Jakarta EE Working Group

·      Priorities for evolving cloud native Java in the short- and long-term

·      The vital role of the Eclipse Foundation in supporting cloud native Java evolution

 Download the e-book today.

__________________________

A Look Back at September Events

September was a busy month for Jakarta EE and cloud native Java events as we participated in the JakartaOne Livestream event, described earlier, as well as Oracle Code One and HeapCon. Check out the blogs about Oracle Code One by Payara and Tomitribe.

 A quick note about Oracle Code One: Everyone at the Eclipse Foundation was extremely proud when our executive director, Mike Milinkovich, accepted the Duke’s Choice Award on behalf of the Jakarta EE community at the conference.

__________________________

Stay Connected With the Jakarta EE Community

The Jakarta EE community promises to be very active and there are a number of channels to help you stay up to date with all of the latest and greatest news and information. Tanja Obradovic’s blog offers a sneak peek at the community engagement plan, which includes:

·      Social media: Twitter, Facebook, LinkedIn Group

·      Mailing lists: jakarta.ee-community@eclipse.org and jakarta.ee-wg@eclipse.org

·      Newsletters, blogs, and emails: Eclipse newsletter, Jakarta EE blogs, monthly update emails to jakarta.ee-community@eclipse.org, and community blogs on “how are you involved with Jakarta EE”

·      Meetings: Jakarta Tech Talks, Jakarta EE Update, Jakarta Town Hall, and Eclipse Foundation events and conferences, such as EclipseCon Europe

Subscribe to your preferred channels today. And, get involved in the Jakarta EE Working Group to help shape the future of open source, cloud native Java. To learn more about Jakarta EE-related plans and check the date for the next Jakarta Tech Talk, be sure to bookmark the Jakarta EE Community Calendar.


by Tanja Obradovic at October 09, 2019 05:07 PM

Open Source Gerrymandering

by Chris Aniszczyk at October 08, 2019 06:20 PM

Over the years, I have spent a lot of time thinking about and working on open source communities… from bootstrapping projects out of corporations (or broken communities), to starting brand new open source foundations.

I was recently having a conversation with an old colleague about bringing an open source project out of a company into the wild and how to setup the project for success. A key part of that discussion involved setting up the governance for the project and what that means. There was also discussion how neutral and open governance under a nonprofit foundation can be good for certain projects as research has shown that neutral foundations can promote growth and community better than other approaches. Also the conversation led to a funny side discussion on the concept of gerrymandering and open source.

For those who aren’t familiar with the term, it’s become popular in the US political lexicon as a “practice intended to establish a political advantage for a particular party or group by manipulating district boundaries.� A practical example of this is from my town of Austin TX which is in district 35 which snakes all the way from Austin to San Antonio for some reason.

The same concept of gerrymandering can apply to open source communities as open source projects can act like mini political institutions (or bigger ones in the case of Kubernetes). I shared some of my favorite examples with my friend so I figured I’d write this down for future reference and share it with folks as you really need to read the “fine print� to find these at times.

Apache Cassandra

The Apache Software Foundation (ASF) is a fantastic open source organization that has been around for a long time (they celebrated their 20th anniversary) and has had a lot of impact across the world. The way projects are governed in the ASF are through the Apache Way, which places a lot of emphasis on “community over code� amongst some other principles which are great practices for open source projects to follow.

There have been some interesting governance issues and lessons learned over the years in the ASF, in particular it can be challenging when you have a strong single vendor associated with a project as was with the case with Cassandra awhile ago:

As the ASF board noted in the minutes from its meeting with DataStax representatives, “The Board expressed continuing concern that the PMC was not acting independently and that one company had undue influence over the project.” There was some interesting press around the time this happened:

“Jagielski told me in an interview, echoing what he’d said on the Cassandra mailing list, that undue influence conflicts with project leadership obligations established by the ASF. As he suggested, the ASF tried many times to get a DataStax-heavy Project Management Committee (PMC) to pay attention to alleged trademark and other violations, to no avail. Whatever DataStax’s positive influence on the development of the project—in other words—it failed to exercise equivalent influence on governing the project in ASF fashion.â€�

The ASF basically forced a reorganization of the Cassandra PMC to be in more in lines with its values and then caused the primary vendor behind the project to pull engineers off the open source project.

Containerd

The containerd project is an industry-standard container runtime with an emphasis on simplicity, robustness and portability. The history of the project comes from being born at Docker where their open source projects had a governance policy essentially aligned with the BDFL philosophy with one of their project founders.

In CNCF, (which containered is a project of), project governance documents aren’t considered static and evolve over time to meet the needs of their community. For example, when containerd joined the CNCF their governance was geared towards a BDFL approach but over time evolved to a more neutral approach that spread authority across maintainers.

Cloud Foundry

Cloud Foundry is an open source community that has a large and mature ecosystem of PaaS focused projects. In the Cloud Foundry Foundation (CFF), they have a unique governance clauses in regards to how affiliates are treated and voting.

Pivotal Platinum Director Voting Power. The Platinum Director appointed by Pivotal (“Pivotal Director�) shall have five (5) votes on any matter submitted to a vote of the Board. (i) On a date one (1) year after the incorporation date set forth in the Certificate, the number of Pivotal Director’s votes will be reduced to three (3). (ii) On a date two (2) years after the incorporation date set forth in the Certificate, the number of Pivotal Director’s votes will be reduced to one (1)

To bootstrap the foundation, the originating company wanted a little bit of control for a couple of years, which can make sense in some situations as the beginning of a foundation can be a tumultuous time. In my opinion, it’s great to see the extra vote clause expire after 2 years, however, it’s still very unfair to the early potential members of the organization.

Another example of open source gerrymandering can be how votes are represented by member companies that are owned by a single entity:

At no time may a Member and its Affiliates have more than one Director who is an employee, officer, director, or consultant of that Member, except that Pivotal, EMC, and VMware, though Affiliates, shall each have one (1) Director on the Board).

This is an interesting tidbit given that Dell owns Pivotal, EMC and VMWare. In some organizations, usually there is legal language that collapses owned entities into one vote.

I personally I’m not the biggest fan of this approach as it makes things unfair from the beginning and can be an impediment to wide adoption across the industry. There can definitely be reasons of why you need to do this in the formation phase but it should be done with caution. If you saw the recent news that Pivotal was being spun back into VMWare and their woes with adoption, it shouldn’t come as a surprise in my opinion as one company was bearing too much of the burden in my opinion and not building a diverse community of contributors.

Cloud Native Computing Foundation (CNCF)

If you remember the early days of the container and orchestration wars, there was a lot different technologies, approaches and corporate politics. When CNCF was founded, the original charter included a clause that upgraded certain startup members from Silver to Platinum that were important in the ever evolving cloud native ecosystem.

“The Governing Board may extend a Platinum membership at the Silver Membership Scale rates on a year-by-year basis for up to 5 years to startup companies with revenues less than $50 million that are deemed strategic technology contributors by the Governing Board.�

In my opinion, that particular piece in the charter was important in bringing together all the relevant startups to the table along with the big established companies at the time.

In terms of projects, the CNCF Technical Oversight Committee (TOC) defines a set of principles to steward the technical community. The most important principle is around a minimum viable governance that enables projects to be self-governing. TOC members are available to provide guidance to the projects but do not control them. 

Unlike Apache and the Apache Way, CNCF does not require its hosted projects to follow any specific governance model. Instead, CNCF specifies that graduated projects need to “explicitly define a project governance and committer process.� So in reality, CNCF operates under the principle of subsidiarity, encouraging decisions to be made at the lowest project level consistent with their resolution.

GitLab

GitLab is a fantastic open source project AND company that I admire deeply for their transparency. The way the GitLab project is structured is that it’s wholly owned by the GitLab company (they also own the trademark). To the credit of GitLab, they make this clear via their stewardship principles online and discuss what they consider enterprise product work versus project work.

I’d love for them in the future to separate the branding from the company, project and the product as I believe it’s confusing and dilutes the messaging, but that’s just my opinion 🙂

Istio

Istio is a popular service mesh project originated at Google. It has documented its governance model publicly: https://github.com/istio/community/blob/master/STEERING-COMMITTEE.md

However, as you can see, it’s heavily tilted towards Google and there seems to be no limits on the number of spots on the steering committee from one company which is a common tactic in open governance approaches to keep things fair. On top of that, Google owns the trademark, domains and other project assets so I’d consider Istio to be heavily gerrymandered in Google’s versus the community’s interest.

JCP

I had the pleasure of serving on the Java Community Process (JCP) Executive Committee for a few years while I was at Twitter. It’s a great organization that drives standardization across the Java ecosystem, some of the fine print is interesting though:

“The EC is composed of 25 Java Community Process Members whose seats are allocated as follows: 16 Ratified Seats, 6 Elected Seats, and 2 Associate Seats, plus one permanent seat held by Oracle. (Oracle’s representative must not be a member of the PMO.) The EC is led by a non-voting Chair from the PMO.â€�

This essentially gives Oracle a permanent seat on the Executive Committee.

Here’s another fun clause:

Ballots to approve Umbrella JSRs that define the initial version of a new Platform Edition Specification or JSRs that propose changes to the Java language are approved if (a) at least a two-thirds majority of the votes cast are “yes” votes, (b) a minimum of 5 “yes” votes are cast, and (c) Oracle casts one of the “yes” votes. Ballots are otherwise rejected.

This essentially gives Oracle a veto vote on any JSR.

Note: The coolest thing the JCP has done is contribute the EE specification work to the Eclipse Foundation and form the Jakarta project over there to steward things in an open way.

Knative

Knative, like Istio mentioned above, is an open source project that was born at Google and controlled by Google. There have been a lot of discussion lately about this as Google recently decided to not openly govern the project and move it to a neutral foundation:

Kubernetes

Kubernetes operates under the auspices of the CNCF and openly governed by the Kubernetes Steering Committee (KSC). The Kubernetes project has grown significantly over time, but has done a great job of keeping things openly governed and inclusive in my opinion, especially compared to its project size these days. The KSC governs the project along with a variety of sub working groups. Also, the Kubernetes trademark is neutrally owned by the CNCF and openly governed via the Conformance Working Group which decides how certification works for the community, which there are nearly 100 certified solutions out there!

Spinnaker

The Spinnaker project was originally born at Netflix and recently spun out into the Continuous Delivery Foundation (CDF) as an openly governed project. The project assets, from domains to github to trademarks are all neutrally owned by the community through the CDF.

Vault

Vault is a fantastic and widely used secrets management tool from Hashicorp. It’s a single vendor controlled open source project that has an open core model with an open source and enterprise versions (see matrix). What this essentially means is that the buck stops at the single vendor on what features/fixes end up in the open source version, most likely that won’t include things that they sell in their enterprise offering.

Conclusion

I hope you learned something new about open source projects, foundations and communities as these things can be a little bit more complicated as you dig into the details. It’s really important to note that there is a difference between open source and open governance and you should always be skeptical of a project that claims it’s truly open if only one for profit company owns all the assets and control. While there’s nothing wrong with this approach at all, most organizations don’t set expectations up front which can lead to frustrations down the road. Note, there’s nothing wrong with single vendor controlled open source projects, I think they are great but I think they need to be upfront, similar to what GitLab stewardship principles on what they will put in open source versus their enterprise version.

In conclusion, as with anything in life, you should always read the fine print of an open source communities charter or legal paperwork to understand how it works. The lesson here is that every organization or project has its own rules and governance and it’s important that you understand how decisions are made and who has ownership of project assets like trademarks.


by Chris Aniszczyk at October 08, 2019 06:20 PM

JShell in Eclipse

by Jens v.P. (noreply@blogger.com) at October 08, 2019 12:16 PM

Java 9 introduced a new command line tool: JShell. This is a read–eval–print loop (REPL) for Java with some really nice features. For programmers I would assume writing a test is the preferred choice, but for demonstrating something (in a class room for example) this is a perfect tool if you are not using a special IDE such as BlueJ (which comes with its own REPL). The interesting thing about

by Jens v.P. (noreply@blogger.com) at October 08, 2019 12:16 PM

Re-Defining Cloud Development Tools

by Mike Milinkovich at October 08, 2019 10:30 AM

The Eclipse community is seriously on a roll these days. Hot on the heels of the Eclipse Che 7 release, we just announced the Eclipse Cloud Development (ECD) Tools Working Group, a vendor-neutral, open source collaboration that will focus on the evolution of development tools for, and in, the cloud.

I haven’t seen an initiative with the potential impact on the development tools industry since the founding of the Eclipse Foundation back in 2004, when we hosted around 12 projects related to the Eclipse IDE.

When the first Eclipse IDE was launched, it fulfilled the need for a vendor-neutral development environment that would help developers adapt to rapidly changing middleware technologies and business priorities including enterprise Java and Web services. Those were the megatrends at the time. And the impact of the Eclipse IDE was massive, as it drove a decade of enormous adoption and industry consolidation around developer tools.

While the Eclipse IDE is still extremely relevant, better than ever, and is actively used by more than four million developers, today the megatrend is cloud development. And, the world needs open source technologies and tools to drive the development of cloud native applications. The purpose of the ECD Tools group is to deliver modern, extensible, web-based developer tool platforms that can be used by everyone to enable their own cloud enablement strategies.

Huge Demand for Open Source Cloud Development Technologies

We know from the responses to our developer surveys and the enthusiastic responses to our recent Jakarta EE 8 release that there’s huge demand for open source cloud development technologies. More than 80 percent of the Java developers we surveyed earlier this year told us they either are already or plan to create cloud native applications within the next 12-18 months.

However, many developers are well beyond the planning stage. The growth and explosion of the Kubernetes container orchestration platform confirms the urgency to deliver open source cloud development technologies is very real today.

Che 7 is the world’s first Kubernetes-native IDE that’s built from the ground up for cloud native application development. It simplifies and accelerates cloud development by allowing developers who are not Kubernetes experts to immediately contribute to cloud native application development efforts. In turn, Che 7 relies upon Eclipse Theia, which provides a highly modular and extensible IDE platform built on modern web technologies that runs on both your desktop or in your browser.

Accelerating Open Source, Cloud Native Development

The ECD Tools Working Group takes our open source cloud development initiatives to the next level.

The Working Group will drive the evolution and widespread adoption of emerging standards for cloud-based developer tools, including language support, extensions, and developer workspace definition. These efforts will accelerate adoption of a Cloud IDE and container-based workspace management.

With such a broad scope, it will come as no surprise to learn that the ECD Tools Working Group encompasses a wide range of open source cloud development projects, including Eclipse Che, Eclipse Theia, Eclipse CodeWind, Eclipse Dirigible, Eclipse Sprotty, and others.

Big-Name Support and Involvement

We could not create a working group of this magnitude and with this potential without the incredible level of support we’ve received from the founding members of this group.

When companies such as Broadcom, EclipseSource, Ericsson, IBM, Intel, Red Hat, SAP, Software AG, Typefox, and others support an initiative so strongly from its earliest days, you get a sense of just how important it is considered to be. Every one of our founders is a respected leader in their space, and we have a mix of large corporations and smaller companies, which is always great to see.

Unstoppable Momentum

I want to thank everyone who has helped us create and launch the ECD Tools Working Group. With the incredible groundswell of interest, engagement, and participation we’re seeing from both world-leading corporations and passionate developers, I truly believe we are standing on the doorstep of a very exciting open source future for cloud development tools. And, I have no doubt this community will continue to grow and thrive.

To learn more about getting involved with the ECD Tools Working Group, view the Charter and ECD Tools Working Group Participation Agreement (WPGA), or email us at membership@eclipse.org. You can also join the ECD Tools mailing list and follow @ECDTools on Twitter.

 


by Mike Milinkovich at October 08, 2019 10:30 AM

Participate in the 2019 IoT Commercial Adoption Survey!

by Thabang Mashologu at October 07, 2019 06:26 PM

According to McKinsey, the Internet of Things (IoT) will have a total potential economic impact of up to $11.1 trillion a year by 2025. 

What are the leading industrial IoT use cases that will contribute to that impact? You tell us!

The Eclipse IoT Working Group has launched the 2019 IoT Commercial Adoption Survey to help IoT ecosystem stakeholders get a better understanding of the IoT industry landscape and gain insights into the requirements, priorities, and challenges faced by organizations who are deploying and using commercial IoT solutions.

Take just a few minutes to complete the survey. Survey responses will be collected until November 29, 2019 and the results will be published in January. 

Thank you in advance for your participation!

Take the survey now!


by Thabang Mashologu at October 07, 2019 06:26 PM

Removing “Contact Us

by tevirselrahc at October 07, 2019 02:17 PM

Unfortunately, because of the larger amount of spam, I now have to remove off the “Contact Us” page.

If you want to contact us, I would recommend you go through our twitter account.


by tevirselrahc at October 07, 2019 02:17 PM

Instanceof Type Guards in N4JS

by n4js dev (noreply@blogger.com) at September 30, 2019 08:06 AM

Statically typed languages like Java use instanceof checks to determine the type of an object at runtime. After a successful check, a type cast needs to be done explicitly in most of those languages. In this post we present how N4JS introduced type guards to perform these type casts implicitly. 

No error due to implicit cast in successful instanceof type guard

The example above shows that strict type rules on the any instance a causes errors to show up when accessing the unknown property pX. However, after asserting that a is an instance of X, the property pX can be accessed without errors. A separate type cast is unnecessary, since type inference now also considers instanceof type guard information.


Hover information on variable access of a shows the inferred type

The resulting type is the intersection type of the original type (which is here any) and of all type guards that must hold on a specific variable access (which is here only type X). Keeping the original types any or Object is not necessary and could be optimised later. In case the original type is different, it is necessary to include it in the resulting intersection type. The reason is that the type guard could check for an interface only. If so, property accesses to properties of the original types would cause errors.


Re-definition of a type guarded variable

Two distinct differences between type guards and type declarations are (1) their data flow nature and (2) their read-only effects. Firstly, when redefining (in the sense of the data flow) a variable, the type guard information gets lost. Consequently, subsequent accesses to the variable will no longer benefit from the type guard, since the type guard was invalidated by the re-definition. Secondly, only the original type information is considered for a redefinition. That means that the type guard does not change the expected type and, hence, does not limit the set of types that can be assigned to a type guarded variable.


Further examples for instanceof type guards in N4JS

Data flow analysis is essential for type guards and has been presented in a previous post. Based upon this information, type information for each variable access is computed. Since also complicated data flows are handled correctly, such as in for loops or short circuit evaluation, type guard information is already available in composed condition expressions (see function f3 and f5 above). Aside from being able to nest instanceof type guards (see function f4 above), they also can be used as a filter at the beginning of a function (see function f6 above) or inside a loop: Negating a type guard and then exiting the function or block leaves helpful valid type guard information on all the remaining control flow paths.

by Marcus Mews

by n4js dev (noreply@blogger.com) at September 30, 2019 08:06 AM

Team Sports for Developers! Edge Computing Mini-Hackathon

by Anonymous at September 26, 2019 09:21 PM

Do you like to build gadgets and/or hack? Then get a team together for the Edge Computing Mini-Hackathon, organized by Edgeworx.

Teams will be challenged to integrate at least one other Eclipse IoT project with Eclipse ioFog and showcase what they were able to accomplish. Representatives from all Eclipse projects are welcome to come help guide, coach, and influence participants to make use of their projects. There will be prizes for the standouts, plus giveaways (and fun) for all!

The event is part of Community Night on Tuesday, October 22, from 19:30 - 22:00 in the Theater Stage room at the Forum.


by Anonymous at September 26, 2019 09:21 PM

How Does Eclipse Dirigible Contribute to Eclipse Che 7?

by Dragomir Anachkov at September 25, 2019 12:00 AM

Eclipse Che unites a wide range of different frameworks, programming languages, and development tools, and helps developers design and create next-level services on the Cloud. Eclipse Che provides you with a default Web IDE. However, Eclipse Che also allows you to plug in other IDEs, because the default IDE may not be able to cover your use case.

For example, we work on Eclipse Dirigible – an open-source cloud development platform that comes with its own Web IDE. You can directly integrate the Eclipse Dirigible Web IDE in Eclipse Che. This means that you can create a workspace in Eclipse Chе using the Eclipse Dirigible Web IDE instead of the default Eclipse Theia IDE.

Fiori-UI-Theme

What is so cool about that?

Developers can run Eclipse Dirigible on whatever platform Eclipse Che 7 is deployed. The most notable example is the OpenShift platform offered by Red Hat. That way, the Eclipse Dirigible portfolio of services and features for business application development becomes available to the entire Che community.

What does Eclipse Dirigible have to offer?

Now, let us take a look at what this portfolio currently consists of. Eclipse Dirigible puts an emphasis on low-code/no-code tools for developing business applications. As of version 3.4, Eclipse Dirigible provides the following tools:

Why use JavaScript as a business application language?

At Dirigible, we have decided to focus on JavaScript, because it has a small learning curve, and it is a well-known programming language that has proven itself in the context of web development throughout the years.

For business application development, which is our case, JavaScript is just a tool, which lets you consume the standardized set of Enterprise APIs that we provide. Additionally, Dirigible allows you to set the default server-side JavaScript execution as synchronous, so you could develop your service in a callback-free way. For example, some of the most popular Enterprise APIs that you can use are:

Are there any alternatives to Eclipse Dirigible?

There are alternatives to Eclipse Dirigible and these are platforms such as Mendix and Force.com by Salesforce. However, you have to purchase the corresponding licenses to start using them.

In the open-source world though, there are no alternatives to this day. There are other open-source platforms such as Eclipse Theia and Jupyter, but they are not competing directly with Eclipse Dirigible, because they specialize in other areas. For example, Eclipse Theia focuses on general-purpose code editing using the VSCode platform while Jupyter, on the other hand, is the right choice when it comes to big data analysis and data mining.

However, none of these platforms provide what Eclipse Dirigible has to offer in terms of low-code/no-code tools for developing business applications. At least for now.

Conclusions

Thanks to the great collaboration with the Eclipse Che team, Eclipse Dirigible is on the right way of achieving its ultimate goal, which is to provide developers of business applications with the fastest turnaround time in the Cloud and a unique user experience at the same time.

So why don’t you give it a try?

If there is something that you don’t like, or you think it can be improved, don’t hesitate to share your feedback. The Eclipse Dirigible team will definitely appreciate it. That is one of the best things about the open-source community that we are all part of!

Resources

How to Run Eclipse Dirigible on Eclipse Che 7


by Dragomir Anachkov at September 25, 2019 12:00 AM

Blocked by an Eclipse Wizard?

by Wim at September 24, 2019 08:53 AM

Tuesday, September 24, 2019
There is a small but very useful patch in Eclipse 4.12 for people that do not want the UI to be blocked by wizards. There are many cases where it is desired that the underlying window can be reached WHILE the user is finishing the wizard. That's why it's strange that the Eclipse Wizard demands from us to always have full and utter attention.

Read more


by Wim at September 24, 2019 08:53 AM

How to Render a (Hierarchical) Tree in Asciidoctor

by Niko Stotz at September 21, 2019 03:16 PM

Showing a hierarchical tree, like a file system directory tree, in Asciidoctor is surprisingly hard. We use PlantUML to render the tree on all common platforms.

Example of rendered hierarchical tree

This tree is rendered from the following code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[plantuml, format=svg, opts="inline"]
----
skinparam Legend {
    BackgroundColor transparent
    BorderColor transparent
    FontName "Noto Serif", "DejaVu Serif", serif
    FontSize 17
}
legend
Root
|_ Element 1
  |_ Element 1.1
  |_ Element 1.2
|_ Element 2
  |_ Element 2.1
end legend
----

It works on all Asciidoctor implementations that support asciidoctor-diagram and renders well in both HTML and PDF. Readers can select the text (i.e. it’s not an image), and we don’t need to ship additional files.

We might want to externalize the boilerplate:

1
2
3
4
5
6
7
8
9
10
11
12
[plantuml, format=svg, opts="inline"]
----
!include asciidoctor-style.iuml
legend
Root
|_ Element 1
  |_ Element 1.1
  |_ Element 1.2
|_ Element 2
  |_ Element 2.1
end legend
----
asciidoctor-style.iuml
1
2
3
4
5
6
skinparam Legend {
    BackgroundColor transparent
    BorderColor transparent
    FontName "Noto Serif", "DejaVu Serif", serif
    FontSize 17
}

Thanks to PlantUML’s impressive reaction time, we soon won’t even need Graphviz installed.

Please find all details in the example repository and example HTML / example PDF rendering.


by Niko Stotz at September 21, 2019 03:16 PM

Let's Do It! Obeo loves The SeaCleaners

by Cédric Brun (cedric.brun@obeo.fr) at September 20, 2019 12:00 AM

I am deeply convinced a company is not only an economical actor. It has a much wider responsibility as any decision also has social, environmental or even political implications.

Looking at our environment state, its recent evolution and how it is forecasted to evolve indeed the task in front of us is huge. It would be easy to dismiss this as a problem our governments and big organizations should step up to, and indeed those in power have the responsibility, the ability and leverage to act and maybe bend those charts.

But I have a motto to “Focus on what you can control, then you can act” and so do I.

Obeo participates and hosts quite a few events each year and we are often struck by the nonsensical nature of the “goodies” industry and what global model they promote: built at the cheapest price, moved across the globe, distributed at the event and then pretty quickly to the bin.

Starting now, you won’t get any more goodies from us at conferences or events, but instead we will gladly discuss how we try to do our part, as a company, in this global challenge.

In relation to this initiative to stop producing waste we do not deem necessary: Obeo is partnering with The SeaCleaners organization to reduce plastic waste. The SeaCleaners is building a giant multihull boat designed to retrieve the plastic waste in the Ocean: The MANTA. The organization vision is that the preservation of the oceans is a global, long-term and worldwide matter that integrates economic, social, human, educational and scientific perspectives. They do that in a dynamic and solidarity-based project. You can learn more about this initiative on Obeo’s website.

The "Manta"

Furthermore, all the designs and blueprints of the Manta boat will be Open-Source and that enable enhancements and duplication at a global scale, a principle clearly aligned with our values and what we do within the Eclipse community.

The "Manta" boat technical data

That being said, it is just one step on a very specific part of our activity, but a step starting a journey with more to do to improve the way Obeo operates regarding its environmental responsibility. When you start building awareness of our impact on all the ins and outs of what we do, you realize even a non-industrial, software company can contribute.

Let's Do It! Obeo loves The SeaCleaners was originally published by Cédric Brun at CEO @ Obeo on September 20, 2019.


by Cédric Brun (cedric.brun@obeo.fr) at September 20, 2019 12:00 AM

WTP 3.15 Released!

September 19, 2019 02:14 PM

The Eclipse Web Tools Platform 3.15 has been released! Installation and updates can be performed using the Eclipse IDE 2019-09 Update Site or through the Eclipse Marketplace . Release 3.15 is included in the 2019-09 Eclipse IDE for Enterprise Java Developers , with selected portions also included in several other packages . Adopters can download the R3.15 build directly and combine it with the necessary dependencies.

More news


September 19, 2019 02:14 PM

Eclipse Foundation Proposes Vulnerability Assessment Tool

by Erik Costlow at September 14, 2019 05:12 AM

The Eclipse Foundation is evaluating a proposal to incorporate a Vulnerability Assessment Tool that would help identify libraries with known security issues. The possible result would help inform developers when their application faces a downstream risk from using vulnerable components.

By Erik Costlow

by Erik Costlow at September 14, 2019 05:12 AM

Language-Workbench für Testsprachen

by Arne Deutsch (adeutsch@itemis.de) at September 13, 2019 02:12 PM

Kennen Sie das? Das Gefühl, all das schon einmal erlebt zu haben? Ein Déjà-vu? Selbiges beschlich mich vergangene Woche bei einem ersten Gespräch mit einem Automobilhersteller über das Tooling seiner hauseigenen Testsprache.

Language Workbench für Testsprachen

Das Problem ist jedes Mal dasselbe. Schon vor Jahren ist die Erkenntnis gereift, dass es nicht sinnvoll ist, die riesige Menge an Testfällen gegen fast jährlich neue Modelle immer wieder neu zu entwickeln. Jedes Mal wieder Unmengen an Zeit und Geld in die Programmierung zu stecken für Arbeiten, die doch eigentlich schon zig Mal erledigt wurden. Nur eben „ein klein wenig anders“.

Auch die Lösung dieses Problems war grundsätzlich die Richtige: eine eigene, kleine Programmiersprache, um Testfälle zu spezifizieren. Der eigentliche Testcode in C wird dann daraus generiert.

Auf diese Weise können sinnvolle Abstraktionen geschaffen werden, welche für verschiedene Modellserien anpassbar und parametrisierbar sind, ohne sich mit technischen Aspekten wie Zeigerarithmetik und Speicherverletzungen herumzuschlagen.

Doch nach einiger Zeit wurden die Schattenseiten dieses Ansatzes deutlich. Während das Tooling für gängige Programmiersprachen exzellent und ausgereift ist und die Entwickler mit mächtigen Werkzeugen zum Editieren des Codes verwöhnt werden, stellt sich die Situation für die neue Testsprache anders dar.

Natürlich liefert der Compiler mehr oder weniger hilfreiche Fehlermeldungen, und immerhin wurde ein einfaches Eclipse-Plugin entwickelt, um zumindest Schlüsselwörter hervorzuheben, aber von einer echten Toolunterstützung kann keine Rede sein. Es gibt keine Codevervollständigung, keine automatische Formatierung, und auch die Integration mit den anderen Tools ist minimalistisch.

Erste Abschätzungen deuten auf mehrere Personenjahre an Entwicklungsaufwand hin, um hier auch nur annähernd dahin zu kommen, wo die Entwicklung mit Java oder C schon lange ist. Und gemacht hat das auch noch keiner im Unternehmen.

Ein hoher Aufwand und ein hohes Risiko, welche in keinem Verhältnis zum Nutzen stehen.

Also war die eigene Sprache ein Irrweg? Oder muss man mit dem schlechten Tooling leben?

Mitnichten!

Es handelt sich hier um ein gelöstes Problem. Die Idee, domänenspezifische Sprachen mit Language-Workbenches zu entwickeln, existiert seit Jahrzehnten. Der Begriff wurde vor 14 Jahren geprägt. Doch während es sich damals noch um Experimente handelte, die noch nicht wirklich produktionstaugilch waren, sind diese Tools mittlerweile ausgereift und verkürzen die Entwicklung von Werkzeugen für DSLs um den Faktor 10 und mehr.

Mit wenigen Wochen Aufwand können bereits beeindruckende Ergebnisse erzielt werden; mit noch etwas mehr Mühe kommt man nahe an das Tooling heran, welches man von Java gewöhnt ist.

Insbesondere im Open-Source-Umfeld um Eclipse herum existiert mit Xtext eine Lösung, die exakt diesen Anwendungsfall optimal unterstützt, eine existierende Sprache mit wenig Aufwand um hervorragendes Tooling zu erweitern. Warum Zeit und Geld verschwenden, um das Rad mal wieder neu zu erfinden, wenn man einfach auf die Arbeit von anderen aufbauen kann? Du hast ein ähnliches Problem?

Schreibe uns gerne deine Erfahrungen in die Kommentare oder sprich uns an!

P.S.: Langweilig wird mir das nicht … auch wenn ich meine, das alles schon einmal erlebt zu haben. Hat ja manchmal auch Vorteile.


by Arne Deutsch (adeutsch@itemis.de) at September 13, 2019 02:12 PM

From building blocks to IoT solutions

by Jens Reimann at September 10, 2019 07:07 AM

Eclipse IoT

The Eclipse IoT ecosystem consists of around 40 different projects, ranging from embedded devices, to IoT gateways and up to cloud scale solutions. Many of those projects stand alone as “building blocks”, rather than ready to run solutions. And there is a good reason for that: you can take these building blocks, and incorporate them into your own solution, rather than adopting a complete, pre-built solution.

This approach however comes with a downside. Most people will understand the purpose of building blocks, like “Paho” (an MQTT protocol library) and “Milo” (an OPC UA protocol library) and can easily integrate them into their solution. But on the cloud side of things, building blocks become much more complex to integrate, and harder to understand.

Of course, the “getting started” experience is extremely important. You can simply download an Eclipse IDE package, tailored towards your context (Java, Modelling, Rust, …), and are up and running within minutes. We don’t want you to design your deployment descriptors first, and then let you figure out how to start up your distributed cluster. Otherwise “getting started” will become a week long task. And a rather frustrating one.

Getting started. Quickly!

Eclipse IoT building blocks

During the Eclipse IoT face-to-face meeting in Berlin, early this year, the Eclipse IoT working group discussed various ideas. How can we enable interested parties to get started, with as little effort as possible. And still, give you full control. Not only with a single component, which doesn’t provide much benefit on its own. But get you started with a complete solution, which solves actual IoT related problems.

The goal was simple. Take an IoT use case, which is easy to understand by IoT related people. And provide some form of deployment, which gets people up and running in less than 15 minutes. With as little as possible external requirements. At best, run everything on your local laptop. Still, create everything in a close-to-production style of deployment. Not something completely stripped down. But use a way of deployment, that you could actually use as a basis for extending it further.

Kubernetes & Helm

We quickly agreed on Kubernetes as the runtime platform, and Helm as the way to perform the actual deployments. With Kubernetes being available even on a local machine (using minikube on Linux, Windows and Mac) and being available, at the same time, in several enterprise ready environments, it seemed like an ideal choice. Helm charts seemed like an ideal choice as well. Helm designed directly for Kubernetes. And it also allows you to generate YAML files, from the Helm charts. So that the deployment only requires you to deploy a bunch of YAML files. Maintaining the charts, is still way easier than directly authoring YAML files.

Challenges, moving towards an IoT solution

A much tougher question was: how do we structure this, from a project perspective. During the meeting, it soon turned out, there would be two good initial candidates for “stacks” or “groups of projects”, which we would like to create.

It also turned out that we would need some “glue” components for a package like that. Even though it may only be a script here, or a “readme” file there. Some artifacts just don’t fit into either of those projects. And what about “in development” versions of the projects? How can you point people towards a stable deployment, only using a stable (released) group of projects, when scripts and readme’s are spread all over the place, in different branches.

A combination of “Hono, Ditto & Hawkbit” seemed like an ideal IoT solution to start with. People from various companies already work across those three projects, using them in combination for their own purpose. So, why not build on that?

But in addition to all those technical challenges, the governance of this effort is an aspect to consider. We did not want to exclude other Eclipse IoT projects, simply by starting out with “Hono, Ditto, and Hawkbit”. We only wanted to create “an” Eclipse IoT solution, and not “the” Eclipse IoT solution. The whole Eclipse IoT ecosystem is much too diverse, to force our initial idea on everyone else. So what if someone comes up with an additional group of Eclipse IoT projects? Or what if someone would like to add a new project to an existing deployment?

A home for everyone

Luckily, creating an Eclipse Foundation project solves all those issues. And the Eclipse Packaging project already proves that this approach works. We played with the idea, to create some kind of a “meta” project. Not a real project in the sense of having a huge code base. But more a project, which makes use of the Eclipse Foundations governance framework. Allowing multiple, even competing companies, to work upstream in a joint effort. And giving all the bits and pieces, which are specific to the integration of the projects, a dedicated home.

A home, not only for the package of “Hono, Ditto and Hawkbit”, but hopefully for other packages as well. If other projects would like to present their IoT solution, by combining multiple Eclipse IoT projects, this is their chance. You can easily become a contributor to this new project, and publish your scripts, documentation and walk-throughs, alongside the other packages.

Of course everything will be open source, licensed under the EPL. So go ahead and fork it, add your custom application on top of it. Or replace an existing component with something, you think is even better than what we put it. We want to enable you to deploy what we provide in a few minutes. Offer you an explanation, what to expect from it, and what this IoT solution can do for you. And encourage you to play around with it. And enable you to extend it, and build something bigger.

Let’s get started

EclipseCon Europe 2019

We created a new project proposal for the Eclipse IoT packages project. The project is currently in the community review phase. Once we pass the creation review, we will start publishing the content for the first package we have.

The Eclipse IoT working group will also meet at the IoT community day of EclipseCon Europe 2019. Our goal is to present an initial version of the initial package. Ready to run!

But even more important, we would like to continue our discussions around this effort. All contributions are welcome: code, documentation, additional packages … your ideas, thoughts, and feedback!

The post From building blocks to IoT solutions appeared first on ctron's blog.


by Jens Reimann at September 10, 2019 07:07 AM

The Rising Adoption of Capella

by Cédric Brun (cedric.brun@obeo.fr) at September 04, 2019 12:00 AM

Witnessing an OSS technology getting together with a wide group of users is something I find exhilarating, I have experienced it with Acceleo, EMF Compare and Eclipse Sirius along the years, each time in different contexts and at different scales but discovering what is being done by others with a technology is always a source of excitement to me.

Capella was contributed by Thales to the Eclipse communities a few years ago already and fueled by the growing need to design Systems in a better way, by the interest in Model Based System Engineering and the qualities of the product in itself we can clearly see an acceleration in the last few months.

If you are wondering what is Capella and what it’s used for, here is a 2-minute video we prepared for you:

Worldwide awareness of this solution grows and adoption rises, organizations from Europe, North America and Asia are now using Capella and experiencing the benefits of using a tool which implements a method (coined “Arcadia”) and not only a language.

Capella Forum Activity

Looking at the numbers, just for this summer : more than 1200 downloads each month, a forum actvity which has been growing with a nice looking curve and monthly stats on YouTube reaching more than 2000 views: considering the size of the target audience this is a significant acceleration and that is without counting the deployment of System Modeling Workbench provided by Siemens which includes the technology.

Adopters not only use it but speak about it and as with any other tool having an opportunity to understanding how others are using it is highly valuable.

Rolls Royce, ArianeGroup or the Singapore University: they all have shared valuable information through the recent webinars :

More are coming and many already available through the Resources Page! BTW we can’t always get the authorization to keep them available online so your safest option is to register and attend.

Munich (Germany)

We also make sure to setup « in Real Life » opportunities to discuss Capella and MBSE. Occasions to talk with the team behind Capella and the experts arounds the world. Next up is Capella Day Munich 2019 in a couple of weeks (the 16th of September) organized by Thales and Obeo in conjunction with the Models Conference 2019. Here is a glimpse of the program :

The agenda is filled with general presentations, feedback by industrial users about their Capella deployment or specific add-ons/integration.

The program of Capella Day Munich 2019

You might want to hurry as we are almost sold out and such occasions are pretty unique!

I sincerely hope you’ll enjoy it, we are working hard to make it a success :-), if you can’t make it this time then know there are more occasions to come: AOSEC in Bangalore, EclipseCon in Germany (again!) where there might be a workshop focused on “MBSE at Eclipse” (Please add your name and interest on the corresponding wiki page )

The Rising Adoption of Capella was originally published by Cédric Brun at CEO @ Obeo on September 04, 2019.


by Cédric Brun (cedric.brun@obeo.fr) at September 04, 2019 12:00 AM

Time for Change

by Doug Schaefer at September 03, 2019 02:56 PM

First, let me get straight to the point. I have left BlackBerry/QNX and will be starting a new job in Ottawa next week. It’s a great opportunity to work on something new for a great company with a bunch of former colleagues I admire. As much as I’m looking forward to that much needed change, it sadly will take me away from the Eclipse community. This message is a goodbye and thank you.

Thinking back all the way to the beginning, I’m quickly overwhelmed by how many great people I have had the opportunity to work with thanks to the Eclipse CDT project. At the very beginning was Sky Matthews and John Prokopenko who let me weasel my way on as Rational’s technical lead on the project just as it was starting out in 2002 also at a time when I needed a change. Of course, I had a great team of developers at Rational with me that made it fun and easy. Not to mention the original team at QNX who were welcoming and made it easy to get involved. I have a special mention for Sebastien Marineau, CDT’s first project lead, who let me take a leadership role on the project and eventually hired me on at QNX to take over.

Then there was the early years on the CDT where we made our mark. Those early CDT Summits were so fun and really helped built up a team atmosphere. We had about a dozen companies sending contributors, a few of them competitors in the spirit of co-opetition, and we made it work. Then over the years we started getting independent contributors who just did it for the passion of building great C++ tooling they wanted to use themselves. It’s been a great mix and I am so lucky and proud to have been a part of it.

And of course, it was all topped off with our yearly EclipseCons. I am proud to have attended every one of the EclipseCon North America ones and was able to attend quite a few of the EclipseCon Europes in Germany. I have to thank Anne and Mike and Ralph and Wayne and Sharon and Perri and Donald and Ian and Lynn and all the Eclipse Foundation staff past and present for making me feel a part of the family. I always looked forward to the EclipseCon Express flights out of and return to Ottawa with many of them.

My fellow attendees at these conferences were amazing, from the first one at Disneyland where we had an overflow crowd at the CDT BOF and where I gave my first of many CDT talks, to all the friends I met at the bar or ran into at sessions, many of whom had nothing to do with CDT but made me feel so much a part of the bigger community. I will never forget the late nights in the bars chatting with friends like Michael Scharf and Ian Bull and Eric Cloninger and Gilles and Adrian and Jonah and Tom and so many others. As it turns out, last year in Ludwigsburg was a perfect finale where we had such a great time at the Nestor on Wednesday night. I will never forget you all.

I’m incredibly proud of what we built for the CDT. It still has the best indexer in the business, thanks to the parser we built back at Rational and the database I built at QNX and then with so many hands continually making it better and adjusting to the now ever changing C++ language spec. The Launch Bar achieved what I wanted by simplifying the Eclipse launch experience. CDT’s new Core Build fits naturally with the Launch Bar and makes it much simpler to integrate external build systems like CMake. And we have just started a GDB debug adapter using the debug adapter protocol which will pave the way to simplify integrating debuggers with the CDT.

The current set of active committers on the CDT have lately been pulling almost all the weight evolving it and getting releases out the door. Their great work has made my transition easier and will keep the CDT rolling along for years to come. And hopefully vendors will come back too and help provide funding for all this activity. We have an action plan to transition the project lead role. Follow the cdt-dev mailing list to find out more.

It’s sad to leave and the memories and friendships will be forever. I will keep my cdtdoug personal gmail account as a reminder of where I came from. But my new role will give me some much needed energy to keep things going for the next decade. I once questioned why you hardly see any retired engineers helping with open source projects or sharing their passion with the next generation. I promise you this, you will see me again.

Take care, and thank you.


by Doug Schaefer at September 03, 2019 02:56 PM

OSGi Remote Services with Apache Dubbo

by Scott Lewis (noreply@blogger.com) at August 31, 2019 05:37 PM

ECF's implementation of OSGi R7 Remote Services allows for replacing the underlying distribution system (repsonsible for the object serialization, transport, and other things). 

This makes it relatively easy to replace one kind of distribution (e.g. Jersey, ActiveMQ) with other/new distribution systems. 

Apache Dubbo has recently been contributed to Apache, and we've created a distribution provider based upon Apache Dubbo.

Here's a list of open ECF Remote Service distribution providers.   If you would like Remote Services support for a particular transport, or you've created your own distribution (or discovery) based upon some other transport and wish to make it available to others please let us know.



by Scott Lewis (noreply@blogger.com) at August 31, 2019 05:37 PM

Eclipse Module on F30 Addendum

by Mat Booth at August 30, 2019 11:30 AM

Additional information about installing the Eclipse IDE module on F30.


by Mat Booth at August 30, 2019 11:30 AM

Redux App Development and Testing in N4JS (Chess Game Part 2)

by n4js dev (noreply@blogger.com) at August 29, 2019 04:04 PM

In large applications, Redux - an implementation of Flux architecture created by Facebook - is often used to organise application code by using a strict data flow in one direction only. Redux is UI agnostic, and can be used in conjunction with any UI library. As a continuation of our chess game tutorial with React, we show how to extract the entire program state out of React components, store it with Redux, and test it with N4JS. The full tutorial is available at eclipse.org/n4js and the sources can be found at github.com/Eclipse/n4js-tutorials.


The first part of the chess game tutorial discussed how to develop a chess game app with React and JSX in N4JS. We have stored the program state - which for instance contains information about the locations of all chess pieces - in the state of the React components directly. As applications become larger, however, the mix of program state and UI makes the application hard to comprehend and difficult to test. To address these issues, we extract the program state from the UI components in the second part of the tutorial.

When using React with Redux, we store the application state in Redux store instead of the state of React components. As a result, React components become stateless UI elements and simply render the UI using the data retrieved from the Redux store. In a Redux architecture, data flows strictly in one direction. The diagram below graphically depicts the action/data flow in a React/Redux app.

Strict data flow of flux architecture application


The action/data flow in the diagram can be roughly understood as follows:
  • When a user interaction is triggered on the React component (e.g. button clicked, text field edited etc.), an action is created. The action describes the changes needed to be updated in the application state. For instance, when a text field is edited, the action created may contain the new string of the text field.
  • Then the action is dispatched to the Redux store whereby the Redux store stores the application state, usually as a hierarchical tree of state.
  • The reducers take the action and the current application state and create an updated application state.
  • If the changes in the application state are to a certain React component, they are forwarded into the component in form of props. The change in props causes the component to re-render.

In the second part of the tutorial we further elaborate on the interaction of React and Redux and migrate the original chess non-Redux app. The tutorial explains the role of the reducer, and how the game state is stored and maintained in the Redux store. Based on storing the game using Redux, the tutorial shows how to test the game application with the N4JS test library Mangelhaft, by for instance checking that valid move destination squares are updated after a chess piece was selected.

Note that the way of testing the game logics is completely UI-agnostic and no React components are involved at all. This is thanks to the decoupling of game logics from UI with the help of Redux.


by Minh Quang Tran

by n4js dev (noreply@blogger.com) at August 29, 2019 04:04 PM

And Now for Something Completely Different

by Ed Merks (noreply@blogger.com) at August 29, 2019 09:23 AM

It's been 5 years since I last blogged, so I had to delete 500 SPAM posts when getting started again.  Much has happened over the past years, some of them not so great. When you start to get old like me, you must deal with the older generation gradually passing on and health problems, such as coronary re-plumbing, can become an ugly fact of life.


I've been working with itemis for the past 11 years, but that now draws to a close.  I wish to thank them for their generous support over all these years.  Many of you might thank them as well because much of what I've contributed is thanks to their funding.  Though admittedly I have the nasty habit of working like a maniac, beyond any reasonable number of working hours, regardless of whether or not there is financial reward.  Cool things are just so compelling. But the worst habit then is not bothering to document or advertise all these cool new features as they become available, but rather to dive into the next obsession because somehow that's more compelling.  Compulsion is a bit of a Merks' family trait, e.g., my sister has more than 20 dogs, though it's easy to lose count...

In any case, most of my obsession over the last year has been related to working with Airbus.  I don't normally talk about my customers, but given they were gracious enough to allow me to demo at last year's EclipseCon the software being developed at Airbus, it's common knowledge anyway.  My goodness but that was a creative and cool project! Unfortunately that too has, as is the case for all good things, come to an end.

I immediately dove into generating a quality report for the Eclipse SimRel p2 repository; there's no rest for the wicked nor for the compelled.  I used EMF's Java Emitter Templates (JET) for implementing that, just as I did for generating the full site information for  EMF's Update Sites  as part of migrating the build to Maven/Tycho.

Speaking of which, did you know that you can make it trivially easy for your contributors to set up a development environment? Just have a look at EMF' build page.  Also, did you know that there exists such a thing for the complete Eclipse Platform SDK as well? Of course not, because I never bothered to tell you!

What's really supergeil (yes, I live in Germany and speak fluent Denglish) about the installing an environment with the full Platform SDK, or some subset there of, is that you can easily see all the Git history of each source file, so you can see what exactly has changed and evolved.  Also, when developing new applications, you can easily search for how the Platform implements those things; then you can snarf and barf out your own solutions, with all due respect for the EPL of course.  You can even find out all the places that a constant is actually used; you cannot do that against binaries because constants get in-lined.  Also, if you see some label in the IDE, you can search for where it comes from, some *.properties file somewhere no doubt, and then you will know the name of that property and can easily find where that's defined and how that's used in the code.  You might even contribute fixes via Gerrit commits!

But I digress.  I was using JET to generate a nice helpful web page with information about all the problems in the SimRel repo, or in any arbitrary repo actually, i.e., invalid licenses, unsigned content, missing pack200 files, duplicate bundles, inappropriate providers, and so on. But then I got frustrated that JET templates eventually get really hard to read, especially as they become more complicated.  Then, when you need it the most, all the nice features of JDT are missing while editing the scriplets and expressions in that template. So as I am wont to do, I digressed further and spent the better part of the last two months working on a rich editor for JET.  I'm sorry (not!) that I had to violate a few API rules to do so, but alas, API rights activists is a topic for another blog because that's a long digression.  The good thing is that the JET editor is finished now; it will be in 2019-09's M3.  Here's a sneak preview:


Yes, that's content assist, just is if were in a real Java editor! Not only that, this time I wrote documentation for it in EMF's doc bundle. And, to top that off with icing, this time I blog about it.  Perhaps only three people in the world will ever use it, but I am one of those three people and I love it and I need it even for working with EMF's code generation templates too. So now I can pop this off my digression stack and go back to generating that p2 repo quality report.  I've been doing that for the past week, and it's almost ready for prime-time.

But then at this point, I must ask myself, where is the financial gain in all this?  My local neighborhood fox, I've named him Fergus,  might be trying to tell me something.



Perhaps you should be a little more sly.  Perhaps the endless free goodness too must come to an end...

by Ed Merks (noreply@blogger.com) at August 29, 2019 09:23 AM

Eclipse is Now a Module on Fedora 30

by Mat Booth at August 21, 2019 01:30 PM

How to install the Eclipse IDE module on Fedora 30!


by Mat Booth at August 21, 2019 01:30 PM

GSoC 2019 Summary: Dart support for the Eclipse IDE

August 19, 2019 12:00 AM

Summary of my Summer of Code 2019

This post is a summary of my Summer of Code 2019. My project was to bring Dart development support to the Eclipse IDE. To do so I created a plugin that consumes the Dart analysis server using LSP4E. It also provides syntax highlighting using TM4E and many more features listed below.

Features

The following list showcases the most significant features of the plugin I (and other contributors) added during GSoC 2019.

  • Running Dart programs directly from Eclipse - eclipse/dartboard#1

    • Standard & error output in a dedicated console
    • Support for multiple Launch configurations
    • Running single files from the context menu
  • Dart preference page - eclipse/dartboard#10

    • Set the location for the Dart SDK that should be used for all actions
    • Choose whether to automatically synchronize the dependencies of project
  • First class Pub support - eclipse/dartboard#107

    • Automatic synchronization of Pub dependencies when changing the pubspec.yaml file
    • Shortcut for running $ pub get manually
  • Creating new Dart projects and files - eclipse/dartboard#115

    • Stagehand templates are also supported
  • Usage of the Dart logo - eclipse/dartboard@a23fc1f

  • Import existing Dart projects directly into the workspace (+ automatic dependency synchronization) - eclipse/dartboard#116

Upstream Bug Fixes

During development I encountered many issues with the libraries and tools I was using. As I was already aware I took the time to fix them directly and provide a patch or PR for the corresponding library.

Things Left to do

I have completed all of my goals I set in the initial proposal for GSoC. However a few things and features have come up during development that I plan on taking care of in the near future.

  • Flutter support - Flutter apps need to be run using the special $ flutter command suite, instead of the default SDK

Other things that could be enhanced include:

  • Pub console - Currently there is now way to see the output of the pub commands
  • Webdev support - Dart apps that should be run on the browser need to be run using the $ webdev command line tools

I hope to be able to work on them but community contributions are always welcome.


A full list of commits and issues can be found on the project's GitHub repository. Installation instructions can also be found there.

Appreciation

In the early days, Lakshminarayana Nekkanti has joined the project as a committer. He has been extremely helpful since by fixing bugs in the Eclipse platform that have been open for years (Bug 513034) and contributing a lot of features and knowledge to the plugin. Thank you, Lakshminarayana!

I would also like to thank Lars Vogel who has been my Mentor and helped tremendously when I was unsure what to do.


August 19, 2019 12:00 AM

Back to the top