Community
Participate
Working Groups
Its been mentioned a few times "why don't you use the file system for aggregation builds ... it's all right there". Of course, there is a very good reason ... because we want it to work every where, not only on the build machine! ... but, it did get me thinking ... I wonder if we could allow both? Sort of an "alternative URL". I don't think there is near enough uniformity at Eclipse to automatically map one to the other ... and even if there was, hopefully aggregator is useful elsewhere where there might be even more complex "mappings" ... so I think fair assumption teams would have to specify both, completely. Or, not sure, maybe there is a way to specify a "mapping rule" for the whole build/model? So, just to pick an example ... adding an alternate location attribute might look like ... <repositories location="http://download.eclipse.org/webtools/downloads/drops/R3.3.0/S-3.3.0RC3-20110527214303/repository/" fileLocation="file:///home/data/httpd/download.eclipse.org/webtools/downloads/drops/R3.3.0/S-3.3.0RC3-20110527214303/repository/" description="Web Tools 3.3 repository site"> There would have to be some simple assumptions/heuristics built in, such as if file system directory exists, assume that's the intended repo and use it, if it does not exist, assume the http one is the intended repo and use it. I'm sure there's complications I haven't thought of ... but seems it might be a big performance boost? While still allowing the same files/model to be "ran from anywhere"? If these URLs are used in creating any metadata, then the http form should be used (or, favored) in that metadata. I just wanted to capture the idea while I was thinking about it.
If I may ... will close my own bug as "won't fix". First, it wouldn't do what I was thinking, to begin with, so probably not that much boost. Even if repos named in b3aggrcon files were retried from file system, once those 'content' repos were retrieved, they would, in turn retrieve artifacts from what ever the content metadata files said ... which presumably would be some http: site, and the aggregator probably can not change those (even if it could ... not a good idea to "rewrite" that much of the behavior during aggregation?) Second, changing the URLs in b3aggrcon jobs can be done with simple scripts, (after retrieving them from cvs) so no need for aggregator to do anything differently.
I actually implemented the "rewrite" in b3aggrcon files. Here's the first run https://hudson.eclipse.org/hudson/job/indigo.runAggregator/512/console I as surprised to see msgs such as [exec] Mirroring artifacts from from file:///home/data/httpd/download.eclipse.org/modeling/emf/emf/updates/2.7milestones Is that a coincidence of how the messages are created? Or is the aggregator, some how, actually getting the the artifacts by using "file:///home/data/httpd/download.eclipse.org/modeling/emf/emf/updates/2.7milestones" (as one example)?
The reason the aggregator fetches the artifacts using the same URL is that it assumes that meta-data and artifacts are co-located.
I'm reopening this bug with a different title since I think that there really is a need for an enhancement that would allow what David suggests. The model could have profiles where this and other things could be specified. Let's assume that the URL could be composed using property expansion. We could then allow constructs like: ${eclipse.download.prefix}/modeling/emf/emf/updates/2.7milestones And then, in a location specific segment: eclipse.local.profile: eclipse.download.prefix=file:///home/data/httpd/download.eclipse.org default.profile: eclipse.download.prefix=http://download.eclipse.org The selected profile could be a preference (in the IDE) or a command line argument (when running Ant).
So as to not lose one complication, as seen in bug 348341, where we do a rewrite directly on b3aggrcon files, it was found it was causing an issue with the compositeArtifacts file we create, for the "trusted repositories" since there, the file:// form was being written whereas we want that to be the http:// form. So, just reminding that case needs to be covered ... or, that is, might be desired to have some special coverage. I supposed trusted repos could just know not to use ${eclipse.download.prefix} but instead leave the http:// form. Just making note, so we won't forget.
[Bookkeeping change only. Moving bugs to the new "home" of aggregator, CBI.]
If this issue is still relevant, please move it to https://github.com/eclipse-cbi/p2repo-aggregator/issues.
