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 i can tell Tycho that
Its not a problem for me that Tycho doesn't do that by default, as long as i can tell
<cacheOffline>true</cacheOffline>
in my pom file in the configuration area besides the target
that that is then a hint to tycho that it can use it offline
Its not that it needs to be offline!
because it seems that that is the case of maven offline, you first need to run something else again
Thats what i want to avoid, that makes everything more complex again because i do need to run stuff.
I just like that a tool does that for me, that i don't really see it i only can configure it.
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.
yes that would be very nice, as i said no need for this to be default
Its just that if you know the target file is or must be fixed, set in stone, that we give tycho a hint use offline cache as much as possible if you can
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.
as i said above i don't like that offline mode of maven, because that seems to me like an all in
everything needs to be offline. That really would mean for us all kind of extra jenkins jobs over the different branches that needs to do stuff
I don't care that it needs to download stuff if it is not local. i care about that it does this also when it already has everything local. it does not need to check and download "content.jar or artfacts.jar" of any update site in the target file if it already did that for that specific target file (based on the contents)
(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.
its just an example
its just the network is not always reliable and we have a lot of different things (eclipse, our own s3 based, 3rd party, orbit)
any of them could potentially fail with a network connection
IF that happens the first time, then yeah nothing we can do about that
but i really don't like that it can fail after that if it already could just build it...
not directly related. but also the signing tsa servers are horrible, i am constantly switching between them
because a server bombs out again now and then
Also there i guess tycho could help, the signing should have a config <retry>3</retry>
so that if signing fails tycho tries 3 more times (maybe with some delay between)
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.
Tycho does this just fine..
our target file is static so the build tool as you say is doing this currently for us just nicely
ofcourse besides that you have all kinds of version in your plugins or features but those are mostly "from" not "fixed"
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.
no again
tycho works perfectly for that it does exactly do what i want
i say to tycho you can now download new stuff and build against that
I just update the target file with a new url and or new version of the plugins/features i want to include
and that way i already tell tycho that it can download new stuff
Thats not the problem i describe here.. That works already just nicely and fine
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.
for me thats horrible
that just means that your builds that can just be triggered without any change in the build can suddenly be something completely different.
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 ;)
i am all for 1 as mvn --offline will not help me really, will make it all more complex.
_______________________________________________
tycho-user mailing list
tycho-user@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/tycho-user
