[...]
that will not change..
[...]
it will never change and it is not supposed to change!
Having a .target that's referencing static content is a good thing and a recommended one.
However Tycho cannot know that. There is nothing we can safely rely on to automatically know the "quality" of referenced p2 repo and change the workflow accordingly.
right but it bombs out when it can't
Please open an enhancement request about it; it could be some "forceUsingCachedMetadata" flag somewhere to just ignore remote repositories, or something else to failback to cache when remote repo is not accessible. But in reality, an inaccessible remote repository can be a major issue worth failing the build, no-one knows if things are temporary or not, so such behavior to be more tolerant to remote errors would have to be an opt-in.
and it takes quite some time to check all our stuff all the time
i rather then have an option right here:
<fixedTarget>true</fixedTarget>
and based on that tycho never checks after the initial download for that target file (check the contents not the version) that it needs to do some stuff
Please keep in mind that Tycho doesn't map a .target to a repository internally; it takes a target, the environment, the current reactor and the current artifact to resolve a set of dependencies; and then download them.
So not only your .target affects what you need to download, but also the environment (eg Java version), the other projects built simultaneously, the dependencies of the target artifacts...
That said, I think what can fit in Tycho is utility to "cache target content", taking as input a .target, this utility would fetch and cache everything in the local cache under Maven repo and next execution could run with the "--offline" flag to tell Tycho to not fetch anything.
I don't know how well/bad this "--offline" works at the moment, it's something you'd like to look at and maybe improve. Basically, testing on your project `mvn verify -DskipTest && mvn --offline verify -DskipTests` would be expected to work first. If it's not working, Tycho needs to be improved to make it work.
right so why does it bomb out if it can't find:
Failing a build in that case is desired by default (if a remote repo does disappear, we want to notice it). But an enhancement could indeed be that this doesn't bomb out and failback to local cache when some flag (eg "--offline") is passed. Please open a bugzilla issue about that.
(which happens now and then for that)
That's a bug to report to the maintainers of this repo, not something Tycho is responsible for.
right but let me decide that then
i know it is fully stable. it never want that a target file that stays the same has al kind of hard version it it (see above)
suddenly starts downloading different stuff
If that happens it should fail
i want to know that
because that means that suddenly our product builds on a different set of jars that i don't expect
and i want to be fully in control
That's not about building here, it's more about your needs in term of dependency management and more specifically to your project. I think such guards and checks should be placed on your end as the publisher or consumer of the repo, not something in the build tool itself.
i am the person that says tycho you can download new stuff, i checked it and i updated the version in the target file.
That's not how Tycho works, sorry. We can make Tycho work better for this case (tools to mirror a .target content locally, better support for --offline), but Tycho is the master of dependency management, and has many optimizations that make that your needs for a locally controlled TP is not desirable in many cases; so Tycho won't change this deep way of working.
The trick is not about you say Tycho "that changed", but more about you say Tycho "don't download" (eg --offline). It should have the same result but is way more consistent with the Tycho way.
Where is an example that does suddenly change?
Many SimRel projects to use the latest Platform I-Builds (mutable content) in their .target files to be able to consume newer features and APIs.
right thats what i kind of want i don't mind that this is an option that i need to set like i said above.
i know my target file as long as the content doesn't change is set in stone, the download will always be exactly the same, it does not need to check anything
So I think it only needs:
1. one mojo to populate Tycho cache (metadata and artifacts) with the .target file content
2. good support for --offline
As those are actionable items, next steps of the discussion should happen on Bugzilla ;)
