Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CBI/Feb21 2012"
< CBI
(→Problem statement) |
(→Problem statement) |
||
| Line 31: | Line 31: | ||
===Problem statement=== | ===Problem statement=== | ||
| − | We need a system to manage 3rd party, modified 3rd party, and Eclipse-built | + | We need a system to manage 3rd party, modified 3rd party, and Eclipse-built artefacts that can support access/retention policies for the current release community, LTS, and Polarsys forges. It is likely that IWG member companies will want to establish their own company specific forge areas within the LTS & Polarsys forges. All of this would be replicated for each release every year. |
====Issues==== | ====Issues==== | ||
Revision as of 14:09, 21 February 2012
Contents
Meeting
- February 21, 2012, 10am EST
- Eclipse Conference facility
Attendees
Andrew R., Igor F., Paul W., David W.
Not on agenda, still being tracked as work left to do
a) Platform specific code swt & launchers (Bug 370704) b) Do not generate new version qualifier unless there are actual code changes (Bug 367581) c) Isolate CBI platform build from uncontrolled software sources (Bug 369002) d) unexpected contents in org.eclipse.osgi.services sources bundles(Bug 370124) e) reproducible build version qualifiers (Bug 370707) f) API Analysis g) Junit tests h) Which execution environments will CBI build & test against
Minutes
Discussed: Distribution wiki page
and Updated image w/ view of distribution
Summarizing the discussion:
Problem statement
We need a system to manage 3rd party, modified 3rd party, and Eclipse-built artefacts that can support access/retention policies for the current release community, LTS, and Polarsys forges. It is likely that IWG member companies will want to establish their own company specific forge areas within the LTS & Polarsys forges. All of this would be replicated for each release every year.
Issues
- Today this is done by hand via. cp/rsync, etc. Doing this by hand is expensive and will become even more so as the environment grows
- Finding components and navigating their dependencies makes for a barrier to those that wish to consume Eclipse software
- Today, some projects (e.g. Virgo, Stardust, possibly others) are consuming software from maven central. This is not in compliance to Eclipse's IP policy. An Eclipse Foundation controlled alternative to maven central that proxies/caches IP-approved content from maven central would be an easy way to solve this.
- Leaving this for each project to sort out on their own will inevitably result in redundancy and diverse solutions. A unifying solution lets projects focus their precious time on their project rather than distribution.
Relevant information
- p2 and Maven repository formats are different and incompatible. It is believed converting from one to the other inevitably loses information.
- Nexus 2, under the EPL license, can import a zip file containing a p2 repository. This is just held however, served at a URL, but it seems it doesn't tie into Maven dependancy calculations, etc.
Questions
- What work is required to enable nexus to be a suitable platform for managing p2 repositories?
- Are there any other alternatives that may do a good job of this and require less/no work?
Actions
- David, do you mind providing a link to the discussion about what Jetty did? You mentioned something about them creating their own repository.