On Mon, Dec 7, 2020 at 12:12 PM Johan Compagner <jcompagner@xxxxxxxxxx 
<mailto:jcompagner@xxxxxxxxxx>> wrote:
    [...]
    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:
    servoy-eclipse/pom.xml at master · Servoy/servoy-eclipse
    (github.com)
    <https://github.com/Servoy/servoy-eclipse/blob/master/pom.xml#L44>
    <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.
    servoy-eclipse/com.servoy.eclipse.target.target at master ·
    Servoy/servoy-eclipse (github.com)
    <https://github.com/Servoy/servoy-eclipse/blob/master/launch_targets/com.servoy.eclipse.target.target#L16>
    <https://github.com/Servoy/servoy-eclipse/blob/master/launch_targets/com.servoy.eclipse.target.target#L16>(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 ;)
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user