Bugzilla – Full Text Bug Listing
| Summary: | Zipped P2 repository for eclipselink | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | DB <dominique.busser> |
| Component: | Eclipselink | Assignee: | Eric Gwin <eric.gwin> |
| Status: | ASSIGNED --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | nobody, t-oberlies, tom.ware |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
DB
What is the usecase? What advantage does it provide to make a zipped P2 repo available? EclipseLink is available directly via P2 both on a project level and as part of the simultanious eclipse repositories. It is possible. I'd just like to find out how useful to the community as a whole this would be. (In reply to comment #1) > What is the usecase? What advantage does it provide to make a zipped P2 repo > available? The use case is to get a reproducible build with dependencies to a well-defined version of EclipseLink. Therefore we would like to have the Eclipse releases (including metadata) as single artifact for download. (In reply to comment #1) > EclipseLink is available directly via P2 both on a project level and as part of > the simultanious eclipse repositories. p2 repositories that get new versions may threaten reproducibility. We obliged to be able to rebuild our deliveries with only minimal differences, and this for many years. This is why we keep archives of the used p2 repositories. We could create the archives ourselves, but this is a manual process which could introduce errors. Therefore we would appreciate if you could offer your releases as zipped up p2 repositories directly from your release builds. (In reply to comment #3) > The use case is to get a reproducible build with dependencies to a > well-defined version of EclipseLink. Therefore we would like to have > the Eclipse releases (including metadata) as single artifact for download. Sounds reasonable. We'll need to look at the impact on the size of our download area though. (In reply to comment #3) > We obliged to be able to rebuild our deliveries with only minimal > differences, and this for many years. This is why we keep archives of > the used p2 repositories. Understood. Local dependancy archives are preferable to protect build reproducablility against external changes. Our release and milestone repositories should never 'not' contain a released child, but archival is a reasonable precaution regardless. Our persistent repositories are composite repos. I can zip up each released child provide a download link for it. Would you need milestone children as well? Making just the releases available currenlty would take just under 200MB. I'm checking with the webmaster about disk quotas, but think that would be do-able. For us, it would be enough if you could provide zipped p2 repositories for all _future_ milestones and releases. So if your build produces these from now on, this would be fine; no need to manually process existing releases. And if you run out of spaces, it would probably be okay to delete the milestones again. Thanks for your help :-) Just want to ask the project owners whether there has been some progress on providing zipped p2 repository content for download. Optimally, there would be one zip file per p2 repository as offered on the composite site http://download.eclipse.org/rt/eclipselink/updates/. For instance, the content of http://download.eclipse.org/rt/eclipselink/updates/2.4.0.v20120608-r11652 might be offered as "eclipselink-updates-2.4.0.v20120608-r11652.zip". There is no need to offer "historical" released. Personally, I would like to see zips from 2.4.0 onwards. Thanks a lot! Regards, The zipped repos are created, but aren't yet available. The migration of the website from cvs to git is the next hurdle. Once I can change the release landing pages, the archives will be available for download. Am working on it now, and will report again when complete. The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |