Setting eclipse "native library location"

Hello,
in our project we use some Java libraries which need native libraries as well.
The current approach is that the native libraries are packed into jar files and stored next to the java libraries within artifactory. Via gradle dependency resolution these jars are downloaded and a gradle task extracts the native libaries
into a specific subdirectory of the build directory. The classes task depends on the extraction task to make sure the native libraries are there before test execution.
In the context of test and integrationtest the java.library.path is set to the subdirectory automatically within the build script. Everything works nice on the command line and in Jenkins.

Since we are using Eclipse we would like to execute the tests and the application itself within Eclipse as well.
Before switching to buildship we used the gradle IDE plugin from pivotal and extended the eclipse task appending the native library directory;

eclipse.classpath { containers "org.springsource.ide.eclipse.gradle.classpathcontainer" }
eclipse.classpath.file {
  withXml { xml ->
    def node = xml.asNode()
    def container = node.find { it.@path == 'org.springsource.ide.eclipse.gradle.classpathcontainer' }
   container.appendNode('attributes').appendNode('attribute', [name: 'org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY', value:"$project.name/build/natives/windows"])
  }
}

This worked partially but lead to having “Gradle dependency” and “Referenced Libraries” shown in Eclipse and we got an update problem using snapshot dependencies because Eclipse used to containers and only one got updated by the plugin.

Therefor I tried to switch to buildship hoping the problem can be dealt with in another way.
Currently I have a couple of problems:

  1. The build directory is hidden in Eclipse importing the gradle projects via buildship. Therefor I cannot set up the native libary location for the “Project and External Dependencies” container manually in Eclipse which would be an intermediate solution
  2. Using the same task shown above with “org.eclipse.buildship.core.gradleclasspathcontainer” instead of “org.springsource.ide.eclipse.gradle.classpathcontainer” has no effect. It looks like buildship is not using the eclipse plugin and its tasks or overwrites the classpath file afterwards.

Do you have any ideas how to integrate native library setup in Eclipse via gradle and buildship?
I’m also happy to change our current approach dealing with native libraries if a better way of integration is available.

Hi,
Sorry about not responding for a while. Rest assured, we’ll get back to you later, probably next week.

The build folder is hidden by a resource filter which you can remove manually. Right-click on the project, select Properties > Resource > Resource Filters, then delete the filter hiding the build folder and apply the changes. Afterwards, the build folder will be visible.

Regarding the .classpath file overwriting, the latest 1.0.5 release behaves as follows: if no .project file exists, then the .project and the .classpath files are generated. If a .project file exists, then it remains unchanged (only an extra ‘Gradle’ nature is added) and the .classpath file is overridden. This will change in the upcoming 1.0.6 release, when the import will preserve existing .classpath files too.

For the time being I’d recommend i) deleting all Eclipse descriptors from the projects ii) doing an import using Buildship’s wizard, and iii) and checking if the generated classpath fits your needs.

Hi Donat,
thank you very much for your suggestions. After deleting the build directory resource filter I was able to set the native libary location within eclipse for “Project and External Dependencies” and afterwards the native libraries are found and used.
The native library location is kept even if I refresh the gradle project but unfortunately the deleted resource filter for the build directory is replaced every time I refresh therefor the native libraries are not found until I delete the filter again.

A workaround is to unpack the native libraries outside of the build directory and to clean them up manually using the clean task.

I was wondering if the setting of the build directory filter within every gradle refresh is done by intention?
I’m using Gradle 2.8 and Buildship 1.0.5 with a multi project layout.

Best,
Oliver

Yes, we added the build folder filtering consciously. Also, we have intention to improve the behaviour. If you are interested you can subscribe to the corresponding bugzilla ticket. The implementation already exists but it needs some care before it’s ready to be merged.