https://github.com/thahnen/sonarlint-eclipse-launcher
Eclipse launcher for developing SonarLint for Eclipse
https://github.com/thahnen/sonarlint-eclipse-launcher
Last synced: 10 months ago
JSON representation
Eclipse launcher for developing SonarLint for Eclipse
- Host: GitHub
- URL: https://github.com/thahnen/sonarlint-eclipse-launcher
- Owner: thahnen
- License: mit
- Created: 2023-08-18T15:13:30.000Z (almost 3 years ago)
- Default Branch: develop
- Last Pushed: 2024-11-28T10:35:49.000Z (over 1 year ago)
- Last Synced: 2025-01-21T23:32:03.536Z (over 1 year ago)
- Language: Ruby
- Size: 70.3 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# SonarLint for Eclipse: Development launcher
This repository contains common exported launchers for developing SonarLint for Eclipse.
## Ant scripts
Some Ant scripts are used for better integration of Maven projects into Eclipse. This is due Maven creating a file
named **_remote.repositories** per artifact downloaded inside the local repository. Running these scripts will remove
friction when (re-)loading target platforms
- *sonarlint-java-client-osgi.xml* (> 10.1) used for development, OSGi bundle for all client libraries (Java based IDEs)
There is one Ant script used for SonarLint to pick up Eclipse plug-in test projects as they don't necessarily follow
the Maven project structure and when the classpath files are generated by Maven/Tycho the *test* property is not always
set correctly:
- *sonarlint-test-classpath.xml* used so SonarLint issues are only raised for non-production rules on test source code
## IBM Developer for z/OS
Due to SonarLint for Eclipse being also usable in IDz via the integration plug-in provided by IBM, it makes sense from
time to time to check whether changes introduce might break the compatiblity (e.g. on changes on the extension points).
For easier testing, there are some [Homebrew casks](https://github.com/Homebrew/homebrew-cask) that can be found in the
*IBM-Developer-for-zOS* folder for installation locally (should work on macOS / Linux devices).
A local cask can be installed via
> brew install --cask {local repository directory}/IBM-Developer-for-zOS/{formulae name with file suffix} --debug
- *IDz1509.rb* for IBM IDz 15.0.9 (05.2024), the latest Java 8 based
[General Availability](https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_(GA))
- *IDz1605.rb* for IBM IDz 16.0.5 (06.2024), the latest Java 11 based
[General Availability](https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_(GA)) that
should be sufficient when testing
- *IDz1700.rb* for IBM IDz 17.0.0 (10.2024), the latest Java 17 based
[General Availability](https://en.wikipedia.org/wiki/Software_release_life_cycle#General_availability_(GA)) that
should be sufficient when testing
A local cask can be uninstalled via
> brew uninstall --force --cask {formulae name without file suffix} --debug
**INFO: Currently uninstalling these casks doesn't work correctly as the copied applications are not removed!**
## Debugging Sloop in Production
In order to debug Sloop we have to have SLCORE 10.x opened in *JetBrains IntelliJ Ultimate*. After that, we have to
start an application via one of the following scripts:
- `debug/eclipse-rcp.sh` corresponds to *Sloop in Eclipse RCP*
- `debug/eclipse-cpp.sh` corresponds to *Sloop in Eclipse CPP*
- `debug/idz-15.0.9.sh` corresponds to *IBM IDz 15.0.9*
- `debug/idz-16.0.5.sh` corresponds to *IBM IDz 16.0.5*
- `debug/idz-17.0.0.sh` corresponds to *IBM IDz 17.0.0*
After that, from within *JetBrains IntelliJ Ultimate*, we can attach to that specific process (always port 9009).
## TODOs:
There are still some things left to do:
- add Ant script for checking consistency in SLCORE versions between *pom.xml* / *commons.target* / *MANIFEST.MF*
- add target platform that can be loaded into Eclipse to run IDz instead of a default Eclipse Application