Summer Open Source Project - Eclipse PDE

About the project

Eclipse PDE is a development environment for creating Eclipse plug-ins and stand-alone RCP applications, enabling both contributors and enterprise developers to build custom tools. It has powered well-known applications like Xmind and KNIME, showing its versatility beyond just Eclipse IDE extensions. With a committed global user base in the tens of thousands, Eclipse PDE remains a key tool for modular, enterprise-grade application development.

The Issue
Eclipse PDE’s Manifest editor lacks proper UI support for the jars.extra.classpath attribute, causing many developers to mistakenly use additional.bundles, which incorrectly adds compile-only dependencies as runtime dependencies. To address this, I explored the Eclipse PDE codebase and identified key files such as BuildClasspathSection.java, DependencyManagementSection.java, pderesources.properties, and PDEUIMessages.java. The solution involves adding a new button in the Build tab (inspired by the Add Bundles button in the Dependencies tab) that allows users to directly reference bundles from the workspace or target platform as compile-only dependencies. This enhancement will align PDE with real-world workflows, reduce confusion, and improve documentation and developer experience.

Codebase Overview
The Eclipse PDE codebase is primarily built with Java, leveraging OSGi as the modular runtime for plug-in architecture and bundle management. It uses Maven with Tycho for building, packaging, and dependency management across multiple modules. For the UI, it relies on SWT (widgets like buttons and layouts) and JFace (viewers, dialogs, and higher-level abstractions). Finally, JUnit is integrated for automated testing, particularly for plug-in testing scenarios .



Comments

Post a Comment

Popular posts from this blog

CICD Pipeline - Midterm Exam of Spring 2025 DevOps Class

Image
  Introduction  This project was making CICD pipeline with Git Action, Docker, EC2, RDS, ECR, and Route53. I used my side project Jake (Social Media platform for international students) as source code. The flow of CI/CD pipeline goes like below. Source Repo contains Dockerfile and Docker-Compose.yml. It needs to run locally without any error. Infra Repo contains GitAction workflow codes. This triggers launching a temporary EC2 and fetch codes from source repo. It builds docker files and conducts smoke test. If smoke test succeeds, it pushes docker image to ECR, and it is deployed in EC2 as a QA Server. Route 53 directs IP address to domain name. The Issue  There were many issues and errors while building the CI/CD pipeline.  Source Repo Local test CORS Error : Connecting FrontEnd and BackEnd caused CORS error, which is not letting other origin use same address. To fix it, I used Reverse Proxy by Nginx, and added annotation in SpringBoot controller(@CrossOrigin)....
Read more

Open Source Project - Open Energy Dashboard

Image
  Open Source Project - Open Energy Dashboard Introduction  During last 4 weeks our CTI team (Hyunoh, Abas, Ezequiel, and Mon) worked on Open Energy Dashboard open-source project. Open Energy Dashboard(OED) is a project where it is used as an energy dashboard so that all the users can manage the energy usage of their worksite. ( link ) The Issue  We as a team coded a line group reading test case(c11) in JavaScript and TypeScript using Docker and Visual Studio Code, ensuring values are read correctly to reflect 14 days giving hourly point and middle readings. ( Link )   Test cases are important to enhance accuracy of a software. By writing and updating test case, we estimate we improved test coverage by 30% and enhanced data accuracy by 25% in a Dockerized environment, ensuring seamless integration and reliable energy value processing.  To resolve the issue, our team 1. looked up for development document,  2.starting Docker and activate web and database...
Read more

2025 Spring CS686 DevOps - Final Project

 Final Project Overview -make MSA service -use EKS -Automate -deploy blue-green strategy  -deployment flow : Nightly Build -> QA -> UAT -> Prod  Steps 1. Make MSA codes  Dismantled existing code into three services - backend1, backend2, and frontend 2. By Git Action test and deploy Made GitAction Workflow('Nightly-Build') to start temporary EC2 and test(smoke-test) the code. Used dockers to run three different services and tested if it works. 3. Deploy to QA Server Using GitAction, deployed it on QA server(single EC2 server). Now we can see it at IP address of EC2 instance.  4. Make EKS Cluster and Deploy Blue Service of UAT  Make VPC and EKS Cluster.  Make Node Group. Need to use good enough instance.  Using Git Action and yaml file from Infra repo, apply configuration to running pods on EKS.  Now your microservice is deployed on EKS and you can access it through url.  5. Switch it to Green Service of UAT  Deployment of Gr...
Read more