Bug 507430 - Binary artifacts are not stored in the bundle pool
Summary: Binary artifacts are not stored in the bundle pool
Status: RESOLVED WORKSFORME
Alias: None
Product: Oomph
Classification: Tools
Component: P2 Management (show other bugs)
Version: 1.6.0   Edit
Hardware: PC Windows 7
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-13 04:19 EST by Ed Merks CLA
Modified: 2020-01-02 06:54 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Merks CLA 2016-11-13 04:19:58 EST 
Creating a new installation with a pool finds all artifacts in the pool except for the binary artifacts.  This results in at least an attempt to download those artifacts again.  I'm not sure where they are cached, because it does work offline, but I believe the server's timestamp is checked, so definitely this doesn't help with performance.  And when the server is unresponsive as often happens with download.eclipse.org and when the site has no mirrors (as sometimes happens when download.eclipse.org stops returning proper mirror lists) this results in installs stalling for a significant period of time.
Comment 1 Carsten Reckord CLA 2017-01-31 09:17:03 EST 
I'm not sure about the timestamp check or the general download logic in P2 for binary artifacts. 

But FWIW, those artifacts are cached not in the pool, but in the agent location, in org.eclipse.equinox.p2.core/cache, which is a valid artifact repository.
Comment 2 Ed Merks CLA 2020-01-02 06:54:18 EST 
Yes, the are indeed cached.  Most don't end up in the pool because the touch point actions do different things with them, e.g., unzip them to extract the eclipse.exe and eclipsec.exe.