Extend the uptodate checks of the tasks provided by the eclipsebuild
package to also respect changes to
the extension element that they makes use of. Use convention mappings to solve this problem.
All tasks must properly participate in the uptodate checks.
Make use of the NamedDomainObjectContainer
approach to define the target platforms in the root project.
The current DSL to define the target platforms in the BuildDefinitionPlugin
in the root Gradle build file
is not the typical way of doing it in Gradle.
Only declare the Eclipse plugin dependencies in the MANIFEST.MF file and have the build.gradle file read the dependency information described in the MANIFEST.MF file.
Avoid the redundancy between the declaration of Eclipse plugin dependencies in build.gradle and in MANIFEST.MF.
Only declare the target definitions in the .target files and have the build file of the Gradle root project read the target platform information described in the .target definition files.
Avoid the redundancy between the declaration of target platforms in the .target definition files and the build file of the Gradle root project.
Upload each daily snapshot of Buildship to the eclipse.org downloads area via SFTP.
We want to offer the latest snapshot of Buildship to our users in an automated manner.
Currently, all Eclipse plugin dependencies are declared with wildcard versions. Thus, each repository registered in the build is queried to find the latest version for a given Eclipse plugin dependency. Avoid this broad lookup of the Eclipse plugin dependencies:
- Use fixed dependency versions (provide a map with dependency versions per target platform).
- Limit the lookup to the mavenized repository for all groups named eclipse.
- Provide an even deeper integration into Gradle dependency management.
The current behavior adds significantly to the build time and it increases the need to be online when building.