Closed michaelmassee closed 4 years ago
Full working Example: clone: https://github.com/michaelmassee/Petanque-Turnier-Manager
So do I understand this correct that this is backwards compatible, but in addition to the current classpath handling it adds support for Gradle/Buildship?
If so, then I'm happy to integrate this. Although I don't understand how most of the changes are related.
No problem with updating to Java 8, but that should be a separate commit (we can have it in shortly if you need it for your code).
Why all those build system changes? Are those somehow related to the classpath handling? Will the build process still work with these changes?
So do I understand this correct that this is backwards compatible, but in addition to the current classpath handling it adds support for Gradle/Buildship?
Yes, if there is no subdir "libs" present in the project root dir, then the .classpath file is parsed for external libs.
` if (pJavaPrj.getProject().getFolder(LIBS_DIR_NAME).exists()) { return getLibsFromLibsDir(pJavaPrj); } return getLibsFromClasspath(pJavaPrj);
`
Maybe an Option in the preferences is a better Solution ???
Why all those build system changes? Are those somehow related to the classpath handling?
No, this is the Eclipse "way" to Build Projects.
Will the build process still work with these changes?
i did not change, yes should be.
No problem with updating to Java 8, but that should be a separate commit (we can have it in shortly if you need it for your code).
Yes the changes are done with Java 8 Code.
Ok so this should be 3 separate pull requests: 1) Update baseline to Java 8 2) Convert build system to eclipse 3) New classpath handling
Otherwise this is very hard to review & test, so please break this up in separate changes :)
Hi, First of all, Thanks for the great Job and your afford maintaining this Eclipse plugin.
About my changes, this es getting a bit longer. I am Building a Calc Plugin for Petanque tournament manager, on the way couple of years now :-) My issue was always the dependencies.
Not so Nice / Oldshool : When building the otx file, all (Test/Runtime) Jars/Libs got Deployed Manually update the dependencies in the .classpath
So what I tried earlier, do the same as the rest of the Developer World :-) to use Gradle and Buildship, but without any luck building the otx file.
Okay, Holiday, time to Debug and investigate … it took me a few Days to Partly understand why the otx file was not working ... arg #!?
In the Class JavaBuilder the method getLibs is collecting the dependencies from the .classpath. With Buildship there are no entrys for jars in the .claspath
My Solution:
Create a subdir “libs” in the Project root dir use a gradle task, to sync the runtime dependencies with the “libs” dir Changed JavaBuilder to collect the Jars from the libs dir, when exist. When not exist “libs” dir, try to collect the jars form the “.classpath” . (old code)
Steps to do to get this to Work
Install Buildship Import Project as Gradle project Define your Dependencies in the build.gradle Create Sync task to keep your libs dir up to date. “./gradlew copyRuntimeLibs“ Create new Eclipse builder, to call the sync task copyRuntimeLibs
see the “build_example.gradle” in the docs/gradle directory
Open Problem/Bug: When Buildship is refreshing the project, the classpathentry for the OOO_Container is removed from the .classpath
Workaround: eclipse.classpath.file hook in the build.gradle to insert the entry https://docs.gradle.org/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseClasspath.html
“./gradlew eclipseClasspath“ Create new Eclipse builder, to call the Gradle task eclipseClasspath see the “build_example.gradle” in the docs/gradle directory
Sorry for the long text …. But maybe somebody else can use this change. Please ask if you have any Questions, Feedback ?
Regards, Happy Holidays