How to update p2 cache when using version ranges in .target files?

[phermsdorf]

Hi,

we tried using the new version range feature in the .target files and they really very well for us. Thanks for adding this feature!

One thing we were not able to resolve is how to trigger an update for p2/the target editor to fetch new repository information for such a location from the server and set that as new target definition, eg. to consume newer SNAPSHOT builds in the IDE.

This is what we treid so far:

• changing the sequenceNumber, close and re-open .target -> no effect
• right-click in target editor, "Update IU Versions from Repository" -> updates the versions of iu's in the target file that have a concrete version, but does not seem to affect artifacts that are pulled in trough version ranges
• clicking the Update button on a repository with version ranges -> no effect
• clicking the Refresh Button -> seems like some kind of "update loop" starts with ui-freeze and popup dialogs that do something but does not really come to a defined end ...

The only thing that works so far is a Eclipse restart, after that the new SNAPSHOT versions appear in the content tab.

Is there a way to trigger re-resolution of artifacts from a remote server?

Thanks for any hints.

Bye Peter

[merks]

It might just be a p2 problem with having a cached loaded repository in memory. Not that I'm suggesting this as the solution, but does restart the IDE help?

I got so annoyed that sometimes cached files don't seem to update that I added this:

With Oomph's targlet and p2 tasks we actively clear in-memory cached p2 repositories. Under the covers this is supported by org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.flushCache() but I don't see anything in the SDK calling that.

[phermsdorf]

It might just be a p2 problem with having a cached loaded repository in memory. Not that I'm suggesting this as the solution, but does restart the IDE help?

Yes, that works.

[merks]

Yes, I kind of guessed that. But that isn't really a valid solution. Better would be some call that forces the repositories to load, even if that's slower. If you wish to open an issue with a summary (or link) of what we discussed here, that would seem reasonable...

[phermsdorf]

I've created #1514 . Thank you.

[laeubi]

changing the sequenceNumber, close and re-open .target -> no effect

Only helps if the target files content changed (e.g. the XML) but should not be needed most of the time

right-click in target editor, "Update IU Versions from Repository" -> updates the versions of iu's in the target file that have a concrete version, but does not seem to affect artifacts that are pulled in trough version ranges

This is desired as Update mean set the version to the latest from the repository (what did not help with version ranges)

clicking the Update button on a repository with version ranges -> no effect

Update is the same as above with the context menu

clicking the Refresh Button -> seems like some kind of "update loop" starts with ui-freeze and popup dialogs that do something but does not really come to a defined end ...

This is the actual button that should do the trick, if you have any (reproducible) issues with that please report them so it could be fixed.

[phermsdorf]

Wow, that was a fast response!
Thank you very much for your effort.

I tested again with the latest integration build from https://download.eclipse.org/eclipse/updates/4.35-I-builds/I20241215-1800/

My observations:

The "update loop" is still there. Meaning that at first nothing happens in the UI (no progress in the progress view, and nothing displayed in the bottom right corner). After about 30 seconds this Dialog appears:

Then after a few seconds it diasappears (without clicking anything). Then UI freeze ("Keine Rückmeldung").
That continues for about 15 minutes. After that the new artifacts are shown under the contents tab.
(We found out that there is a System Job (which is thatswhy not displayed by default) which seems to do the actual update. It is called "System: File Transport Reader")

After all it works "somehow", but the user experience is really bad.

Using the Refresh button takes about 12min for the refresh (as described under point 1).
The initial resolving of the target file takes about 1,5min.

We have about 20 repos listed in the target platform, some of them beeing composite repos. All of them are hosted on a local nexus server.

So there seems room for improvement here, since restarting eclipse is still far faster than using the refresh button.

Sorry for the bad news ...

Bye Peter

[laeubi]

@phermsdorf can you share a target file with exact operation to reproduce? I'm asking because sadly there are always different ways to trigger a certain operation on different places e.g. like this:

1. open the target file X (you can attach it as a zip file download )
2. Wait until resolved (or not?)
3. Press button X
4. I see A but want B
5. ...

[phermsdorf]

I added an example test.zip file which is somehow similar to our internal target file, just for the sake of reproducing the described problem.

1. Start Eclipse
2. Open the Progress View
3. Open test.target with Target Editor
4. wait until all is resolved (takes for e about 2 minutes)
5. press Refresh Button (if you click somewhere you see the ui is frozen)
6. i see the above described dialog, which then disappears
7. the more you click, the more you see the dialog
8. now i have this "ui freeze state" for about 4:30 minutes (i guess the repositories are resolved in the background)
9. after that the target platform is resolved again (which is shown in the Progress View)
10. all in all the refresh takes about 5min vs 2min of the initial resoving

[laeubi]

Many thanks I created

• Target Editor UI freeze / taking very long when refresh a target file #1523

and will try to take a look at it.