My Open-Source Experience

About the Project

Over the past few months, I’ve been part of CodeDay’s Open Source Contributors Program, where I worked on solving issues and submitting pull requests for Eclipse PDE (Plug-in Development Environment).

Eclipse PDE is a specialized toolset within the Eclipse IDE that simplifies the development of Eclipse plug-ins, RCP (Rich Client Platform) applications, and OSGi (Open Services Gateway initiative) bundles.

Eclipse is widely used due to its open-source nature, extensibility, and large ecosystem of plug-ins. It’s especially popular in Java development but supports multiple languages and frameworks. Its modular structure enables developers to create custom solutions tailored to specific project needs.

By contributing to Eclipse PDE, I’ve gained valuable experience in open-source collaboration, issue resolution, and working within a large-scale codebase.

The Issue

Issue #1218 If a constructor is used for injection that is package protected Felix SCR complains. If the constructor is not public, then the constructor must not be considered. PDE should emit an error in this case to the user.

Looking back, I realize we took a harder path. we searched the codebase and deduced where to make changes based on the issue description without reproducing the problem. While I eventually found the right spot, I admit we could’ve approached it more efficiently.

Once we found the location it was only a matter of finding a way to apply a patch. Noticing how other errors are thrown using a problemReporter we quickly began investigating. One item found in the parameter is called a Message which gives us the type of message that must be displayed for that error. Using that lead we quickly found our next location of interest.

We found a file called Messages.properties where we can display a message to our user when the error pops up. But in order for this to work we also needed to find a bridge between our .properties file and our .java file. This bridge was the Messages.java

Once we created a static String for our constructor injection error, the code was complete, and the desired error was triggered as intended. By building a version of Eclipse within Eclipse, we reproduced the issue by creating a Java class without a valid constructor and confirmed our error message was displayed correctly.

Solving this issue would streamline the debugging process for developers using Eclipse by preventing accidental creation of non-public injectable constructors without a default public constructor. This would provide early feedback, reducing runtime errors and improving development efficiency.

Issue #1426 Currently if one exports a package Using a Quickfix or Manifest editor. PDE adds the export without a version. Unversioned packages have the drawback that one can not reliably reference them with a proper import range. Upon Export via Quickfix or Manifest editor there should be a version default of 1.0.0.

As a team we didn't get to solve this issue just yet as of the writing of the article however I plan to work over winter break with the goal of getting this issue solved soon. I already have a few decent leads.

Solving this issue would help users with inconsistent exporting of their projects where unversioned files may appear. Getting rid of unversioned files on export in eclipse could help reduce package version inconsistencies.

Codebase Overview

Java: The main language used in the Eclipse Environment. Handles all backend tasks. Java is the bread and butter for Eclipses' Plug-in Development environment and helps with RCP applications, OSGi bundles, Automation and Build Processes and more.

HTML and XML: Small markup files used for the UI of Eclipse. HTML is mainly used for rendering embedded web content within Eclipse such as the welcome screen whereas XML helps with managing UI Layouts for the Manifest files and plugin configuration files and can be found everywhere around the application itself.

Challenges

Contributing to Eclipse PDE as a first-time open-source developer came with its fair share of challenges, each offering valuable learning experiences.

Setting Up the Development Environment

One of the first hurdles I encountered was setting up the Eclipse PDE development environment. The setup process was more complex than I anticipated, given how advanced and intricate the environment is. However, once configured, I found it fascinating—and a bit paradoxical. Essentially, you use Eclipse to modify and enhance Eclipse itself. Testing bug fixes involved building a “mini Eclipse” within the main Eclipse development environment. Inside this mini Eclipse, I could create Java projects, like a simple "Hello World," for debugging and verification purposes. This recursive nature of development was both challenging and rewarding.

Navigating a Massive Codebase

Another major challenge was adapting to the sheer size and complexity of the Eclipse codebase. Coming from a college background where I mostly built projects from scratch, diving into a large, established codebase was a new experience. Initially, it felt overwhelming, but I soon realized that working in such an environment was like playing the role of a detective, piecing together clues, tracing through large portions of code, and distinguishing valid leads from red herrings. Over time, I became more comfortable navigating the code, improving my problem-solving skills, and gaining a deeper understanding of large-scale software development.

These challenges not only enhanced my technical skills but also taught me resilience, adaptability, and the value of collaboration in open-source projects.

Reflection

Participating in the CodeDay Open Source Contributors Program and working on Eclipse PDE has been an incredibly rewarding experience, both technically and personally. It gave me a glimpse into the world of open-source development, where collaboration, problem-solving, and continuous learning are at the core of progress.

Looking back I can see how much I've grown and learned due to this experience. From working with massive code bases to dealing with real industry standards and ensuring that my code is up to snuff with the Eclipse foundations standards.

I’m proud of the progress I’ve made and the impact I’ve had, even in a small way, on such a large and established project. This experience has not only enhanced my technical skills but also reinforced my passion for software development and my commitment to continuous learning. I look forward to continuing my journey in open source, building on what I’ve learned, and tackling new challenges with greater confidence.