Until now, I had simply copied the dependencies section from the Maven Central version of JDT Core. Actually, this can lead to non-repeatable builds whenever an upstream dependency gets updated within the version range. I therefore analysed the output of mvn dependency:tree and made sure to add fixed dependency versions for both direct and transitive
dependencies (minus optional ones) to a dependencyManagement section in the POM. This makes sure that we always compile against the same versions and include the same set of dependency class files into our uber JAR, which subsequently is used in AspectJ, i.e. changed class files would also bleed over into aspectjtools.jar.
The downside to this is that whenever we merge in upstream changesdepending on other versions, we have to determine and version-manage them again.
@aclement, maybe you want to merge #9 and #10 first, then I can rebase this one on the merged commit and you can cleanly fast-forward it.
Until now, I had simply copied the dependencies section from the Maven Central version of JDT Core. Actually, this can lead to non-repeatable builds whenever an upstream dependency gets updated within the version range. I therefore analysed the output of
mvn dependency:treeand made sure to add fixed dependency versions for both direct and transitive dependencies (minus optional ones) to adependencyManagementsection in the POM. This makes sure that we always compile against the same versions and include the same set of dependency class files into our uber JAR, which subsequently is used in AspectJ, i.e. changed class files would also bleed over intoaspectjtools.jar.The downside to this is that whenever we merge in upstream changesdepending on other versions, we have to determine and version-manage them again.
@aclement, maybe you want to merge #9 and #10 first, then I can rebase this one on the merged commit and you can cleanly fast-forward it.