|Re: [tycho-user] How to prepare the p2-site for an offline target platform to be used in a tycho build|
Hi,On Mon, Dec 7, 2020 at 11:36 AM Johan Compagner <jcompagner@xxxxxxxxxx> wrote:Why is it if it is already builded with that on jenkins for many times already it can fail suddenly if one of the sites has a hiccup?Rebuilding from scratch is a way to ensure build portability and reproducibility in any environment. That's something that's usually desired.
Why does it want to continuously check and download the stuff?It checks the content of the remote repo for potential updates and so on, but as long as you don't clean your Maven repository, it will reuse the local artifacts that were already downloaded and not redownload them.
Why can't tycho not make a local site right from my target ?How you deal with your target and its caching seems more to be your specific build logic, not something really standard. Tycho doesn't necessarily need nor download the whole content of a .target file description, only necessary dependencies (according to dependency resolution) will be fetched. I don't think such capability to make a local p2 repo from a .target should be part of the default Tycho workflow. However, Tycho can for sure provide some utils to improve that.And there are already such utils in the ecosystem, see for example https://github.com/jbosstools/jbosstools-maven-plugins/blob/master/tycho-plugins/target-platform-utils/src/main/java/org/jboss/tools/tycho/targets/TargetToRepoMojo.java which does exactly that (take a .target and make a p2 repo from it).
For example generate a sha hash from the contents of the target fileand cache based on that hash on local disk the full resolved site.(or it fills up in that dir the stuff it needs or it encounters that is not there)Tycho already has cache in the Maven repo.
So when a full build is done everything is in that dir based on the sha hash of the contents of that target fileif that file changes it just generates a new one (i guess we need to be able to clean up stuff later )But as long as the sha hash doesn't change tycho doesn't try to contact any site it always gets everything locallyThis should speed up the builds, and we shouldn't suddenly have breaking builds because of a network problem to one of the things inside the target.There is nothing that guarantees the content of a remote p2 repository doesn't change; so there is nothing that guarantees that a .target file will resolve to the same artifacts in 2 distinct executions. Caching the results and assuming the remote repos are stable would break many use-cases of Tycho, where projects explicitly rely on mutable remote repositories to build against latest dependencies.
This is kind of currently how we work with target files in our Eclipse environmentsIn Eclipse IDE, you're supposed to hit "reload" from time to time in case your .target has refs to repo with mutable content. It's the same as what Tycho does (reload on every build).
Maybe tycho only needs to cache the contents.jar/artifacts.jar of the sites? because the plugins/features are already cached in the mvn repo. So what we cache based on a sha hash is very little.IIRC, it does already cache metadata from remote repos, but we'd still need to query the HTTP head of repo metadata to know whether something actually changed since last fetch and invalidate cache accordingly. Maybe Tycho doesn't optimize the usage of such cache. It would be interesting to dig in that direction.
Back to the top