Bug 350031 - Indigo release contains fully qualified EPP reference
Summary: Indigo release contains fully qualified EPP reference
Status: RESOLVED DUPLICATE of bug 319853
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Cross-Project (show other bugs)
Version: unspecified   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Cross-Project issues CLA
QA Contact:
URL: http://download.eclipse.org/releases/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-22 06:49 EDT by Alex Blewitt CLA
Modified: 2011-06-28 23:59 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Blewitt CLA 2011-06-22 06:49:44 EDT
The compositeContent.jar for Indigo contains a fully qualified reference back to download.eclipse.org:

  <children size="4">
  <child location="http://download.eclipse.org/technology/epp/packages/indigo/" /> 
  <child location="201105200900" /> 
  <child location="201105270900" /> 
  <child location="201106030900" /> 
  </children>

This means even if the compositeContent.jar is picked up from a mirror elsewhere, it's going to reach back to download.eclipse.org to find out the indigo children. Is there no way of referring to a local copy instead?
Comment 1 Markus Knauer CLA 2011-06-28 15:42:25 EDT
As far as I understood, p2 *always* asks download.eclipse.org for /releases/indigo/compositeContent.jar, therefore it is not a *back* reference to download.eclipse.org.

The main reason for doing it that way is that mirrors are free to choose which directory sub-tree they are serving. There may be cases where a mirror serves only some parts of the whole download.eclipse.org content and excludes /technology. That's why I think it is essential that this composite repository is specified the way it is. (BTW, you can always mirror *everything* into one local repository.)

Another reason is that (based on my own experience) relative URLs depend on the server. *If* the server can handle a relative URL '../../technology/epp/packages/indigo' it could work, but (again, based on my own experience) p2 has (had?) some problems with URLs like that.
Comment 2 David Williams CLA 2011-06-28 23:59:02 EDT
I'm closing as a dup of 319853 (which was closed as a "won't fix") since similar (same?) issue had lots of discussion there, for previous release. 

Bottom line, 1) it is valid the way it is 2) there's no "normal reason" someone would get compositeContent.jar "from a mirror", and 3) if someone did want their own mirror of the indigo repository, the (right, valid, supported) way to do it is to use p2 to make the mirror (and then all references are changed as that p2 mirrored repo would want them).  

And, keep in mind, this has nothing to do with "mirroring the artifacts" for which p2 allows, has its own design, which we do all the time, etc. 

I do understand some people do sometimes want to "make a mirror of a repo" by simply making a big huge copy of a bunch of files ... not sure that's what you are doing or talking about ... but, that's quite right. p2's not made for that sort of "file system duplication".

Hope this helps clarify. If not, keep asking.

*** This bug has been marked as a duplicate of bug 319853 ***