Contribution - de-jcup/eclipse-bash-editor GitHub Wiki
This area is about code contribution = Initial
Ensure you got access to a Java 8 JDK. Please use this. It’s the minimum requirement for the plugin. Of course you can use a newer JDK but you must ensure you build for Java 8.
There is no need for any installation of gradle because we will use gradle wrapper (gradlew) which
will automatically download or reuse defined gradle version.
Also no special gradle settings are necessary (except when you are behind a proxy…).
After checkout please configure (local):
git config branch.autosetuprebase always git config branch.master.rebase true git config core.autocrlf input git config color.ui auto git config push.default simple git config --add remote.origin.fetch +refs/tags/*:refs/tags/*
Execute a ./gradlew eclipse - this will create project setup for non plugin projects.
After this just do a normal Import existings projects in eclipse or use EGradle or use Buildship (never tested).
At https://youtu.be/9_AQouAvehY you find a video showing the full import and launch process. It does also show some warnings appearing with usage of JDK 11 as launch environment. There was an an issue with JDK 11 and RCP development, see 117
Most example codes you will find online are written for eclipse 3.x plugins. The newer 4.x approach is model based and separates application meta information and code by using a graphical model and was designed for RCP programming. With 2018-xx RCP eclipse it seems to become more convenient to develop 4.x plugins. Having more experience and better tool support for 3.x development this plugin was developed as a 3.x plugin.
Just create a new launch Configuration for eclipse and start with all plugins. This will create a runtime workspace and launch another eclipse with plugin inside. For more information look at : http://www.vogella.com/tutorials/EclipsePlugin/article.html
Currently it’s not possible to build the project complete by gradle. I have also tried tycho maven approaches but was not happy with it.
So I did following: - src/main/java and src/test/java will contain parts having no dependency to eclipse - src/main/java-eclipse and src/test/java-eclipse contain eclipse specific parts
Gradle setup is configured without eclipse parts. So doing a
./gradlew build
in root folder will execute all tests specified in src/test/java.
I know this is not the smartest approach - but it works. Also it does force developers to separate their logic from eclipse parts and so many parts will be independent and reusable - e.g. for a command line tool or for developing plugins for another IDE and reusing code.
Currently the build is done in oldschool way which means the Eclipse RCP tools are used to build the plugin site.
We use github milestones for release planning. A milestone represents always a version. A release will always have a link to corresponding milestone and its closed issues. So its automatically the release letter…
For example look at : https://github.com/de-jcup/eclipse-bash-editor/releases/tag/v1.5.3
Deployment to eclipse marketplace is done by de-jcup