I am trying to port some PDE projects from an Ant build to Gradle. I currently face this issue:
an eclipse plugin project has a static MANIFEST.MF in SCM. The manifest has defined e.g.
foo.bar.baz comes from another java project
bar and I have it defined as a compile dependency
This produces an error reported on the manifest as “Package ‘foo.bar.baz’ does not exist in this plug-in”, because it is not on classpath. I can only fix this by manually adding an entry in .classpath, e.g.
classpathentry kind="lib" path="path/to/bar.jar"/>. I thought this would be handled automatically with Buildship just by declaring the dependency on a project, but it seems the entries from the container are not used correctly or something.
I don’t even know if I am approaching this correctly, I am doing this from scratch and there are not many resources on Gradle PDE builds.
Does anyone have experience with doing similar builds?
We gave up using Gradle within Eclipse PDE development. The Eclipse PDE compiler with it’s special dependency rules is not support, because Gradle uses traditional classpath rules. There were some external efforts to support PDE by some plugins, but they were not convincing us.
So we did something somehow “dirty”: Developers use Eclipse as before with traditional Eclipse PDE, letting Gradle out of Eclipse. But building the software on the buildserver is done by Gradle - just using traditional classpath rules as dependencies.
( because this will be a dying project, we don’t care anymore)
That is unfortunate. I was thinking about combining the generated .classpath from gradle with manual entries as described above, but that is another ‘dirty’ workaround and would require developers to maintain both the build file and classpath file. Even then, I have troubles merging the generated classpath with an existing file, but that is another issue.
Adding a classpath entry outside gradle classpath container