Re: Refresh my Memory Please (External binaries and sigtest)
Hello Laszlo. Also the sigtest fails on some minor incompatibilities in the exposed > Gradle Tooling API. Kind of expected with 2 major version change jump. > But otherwise the code seems to work. What would be the recommended > procedure in this case? Shall we increment the major version of the API > this time? Shall be a lib-gradle-tooling module created instead? > We should signal to the module system that linking against Gradle API is no longer going to work. That is usually done by incrementing the major version (the one after / in module name). -jt > Thank you for your advice! > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Re: Refresh my Memory Please (External binaries and sigtest)
I'd say ideally everything on Maven Central but, especially in cases of binaries that need to be downloaded as part of the build process, the Oregon server is the place where we put them. Gj On Mon, Nov 11, 2019 at 5:07 AM Laszlo Kishalmi wrote: > Dear all, > > As Gradle 6.0 came out, I've started to upgrade the Gradle Tooling API > from 4.10.2 -> 6.0 > > For some reason our source of binaries is either from Oregon State > University or Apache Maven Central. Unfortunately I can't remember why. > Unfortunately I just realized that after implemented multi repository > support in DownloadBinaries Ant task. > > Also the sigtest fails on some minor incompatibilities in the exposed > Gradle Tooling API. Kind of expected with 2 major version change jump. > But otherwise the code seems to work. What would be the recommended > procedure in this case? Shall we increment the major version of the API > this time? Shall be a lib-gradle-tooling module created instead? > > Thank you for your advice! > > > - > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
Refresh my Memory Please (External binaries and sigtest)
Dear all, As Gradle 6.0 came out, I've started to upgrade the Gradle Tooling API from 4.10.2 -> 6.0 For some reason our source of binaries is either from Oregon State University or Apache Maven Central. Unfortunately I can't remember why. Unfortunately I just realized that after implemented multi repository support in DownloadBinaries Ant task. Also the sigtest fails on some minor incompatibilities in the exposed Gradle Tooling API. Kind of expected with 2 major version change jump. But otherwise the code seems to work. What would be the recommended procedure in this case? Shall we increment the major version of the API this time? Shall be a lib-gradle-tooling module created instead? Thank you for your advice! - To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
