Hi Dimitris
It is because both the server and core components are built on separate CI jobs that is causing this problem. The server build job is unable to reuse artifacts built in the core job.
Before the CI refactoring to address build times, this was not a problem since everything was built and published within the same monolithic job.
Thanks
Jon
Hi Jon,
Thanks for the detailed update and for your work on this! Would having
separate CI jobs build the Core (Eclipse update site) and Server
(headless application) features simplify things by any chance?
Cheers,
Dimitris
On Fri, 8 May 2020 at 01:29, Jonathan Co <jonathan.co@xxxxxxxxxx> wrote:
>
> Hi everyone,
>
> Earlier this week Dimitris noticed that the updatesite was not functioning correctly. Two problems were identified. The first was a leftover dependency on SVNkit which has since been removed.
>
> The second is a bit more tricky to solve. In some cases Eclipse would attempt to install conflicting versions of the same feature. The root cause was found to be our CI building and publishing the "Core" and the "Server" features separately. By default Tycho was using the build timestamp to calculate feature dependency versions. As "Server" would need to rebuild "Core" (I've been told it is not possible to share artifacts from the "Core" job to "Server), it would end depending on a different version of the "Core" feature.
>
> I've managed to fix this by having Tycho calculate version qualifiers using timestamps extracted from Git rather than the system clock. This method will give reproducible version numbers, relying only on the Git history which should be consistent. My proposed fix uses "tycho-buildtimestamp-jgit" plugin [1] and has been pushed to jc956/updatesite-versions [2].
>
> There is a caveat to this however. Versions are calculated per plugin/feature based on the timestamp of the most recent commit that touches any file within that component. i.e. The last commit to affect org.eclipse.hawk.timeaware was made at 11:41 17-04-2020 resulting in version 1.2.0.202004171141
>
> In practice this will mean one of two things:
>
> 1) Current users will have to reinstall Hawk from fresh. This is necessary as all currently published features will most likely have a higher version than that which has been recalculated
>
> 2) We could 'touch' everything to reset all version calculations.
>
> Alternatively we could possibly use the '-DforceContextQualifier' flag to supply our own version which is pulled from the latest Git commit timestamp. This did not seem the correct solution to me as it would depend on another external script rather than using what Tycho already has.
>
> Thoughts and comments?
>
> Cheers
> Jon
>
> [1] https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers
> [2] https://git.eclipse.org/c/hawk/hawk.git/log/?h=jc956/updatesite-versions
> [3] https://dentrassi.de/2015/07/28/maven-tychojgit-based-build-timestamps-and-the-target-directory/
>
> _______________________________________________
> hawk-dev mailing list
> hawk-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/hawk-dev
--
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
--
Dimitris Kolovos
Professor of Software Engineering
Department of Computer Science
University of York
http://www.cs.york.ac.uk/~dkolovos
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm
_______________________________________________
hawk-dev mailing list
hawk-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/hawk-dev
