Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "CBI/Feb21 2012"

< CBI
(Relevant information)
(Issues)
Line 37: Line 37:
 
====Issues====
 
====Issues====
  
# Today this is done by hand via. cp/rsync, etc. Doing this by hand is inefficient and expensive and will become even more expensive as the environment grows
+
# Today this is done by hand via. cp/rsync, etc. This likely won't scale to satisfy our needs as LTS & Polarsys grow. As well, it may be increasingly error prone as we manage more and more software by hand.
 
# Finding components and navigating their dependencies makes for a barrier to those that wish to consume Eclipse software
 
# 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.
+
# 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.  
# 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.
+
# 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 a common distribution problem.
  
 
====Relevant information====
 
====Relevant information====

Revision as of 15:01, 21 February 2012

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

Andrew: I don't think a consensus was reached. Thus the format of these minutes will be informational and capture the essence of the important issues.

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

  1. Today this is done by hand via. cp/rsync, etc. This likely won't scale to satisfy our needs as LTS & Polarsys grow. As well, it may be increasingly error prone as we manage more and more software by hand.
  2. Finding components and navigating their dependencies makes for a barrier to those that wish to consume Eclipse software
  3. 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.
  4. 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 a common distribution problem.

Relevant information

  1. p2 and Maven repository formats are different and incompatible. It is believed converting from one to the other inevitably loses information.
  2. Nexus 2, under the EPL license, can import a zip file containing a p2 repository. This is just held however, and served at a URL. It doesn't enable/tie into Maven dependency calculations, etc.

Questions

  1. Should it be a requirement that eclipse builds produce maven repositories in addition to p2 repositories?
  2. What work is required to enable nexus to be a suitable platform for distributing p2 repositories? Nexus 2.0 looks like it can do most of this already.

Actions

  1. David, do you mind providing a link to the discussion about what Jetty did? You mentioned something about them creating their own repository.

Back to the top