Bug 303935 - need to remove most, change a few, webtools repository URL in feature.xml
Summary: need to remove most, change a few, webtools repository URL in feature.xml
Status: RESOLVED FIXED
Alias: None
Product: WTP Releng
Classification: WebTools
Component: releng (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P1 normal (vote)
Target Milestone: 3.10.0   Edit
Assignee: David Williams CLA
QA Contact: David Williams CLA
URL:
Whiteboard: PMC_approved
Keywords:
Depends on: 314133 314135 314137
Blocks:
  Show dependency tree
 
Reported: 2010-02-25 12:15 EST by David Williams CLA
Modified: 2018-06-29 15:29 EDT (History)
3 users (show)

See Also:
david_williams: pmc_approved+
david_williams: pmc_approved? (raghunathan.srinivasan)
david_williams: pmc_approved? (naci.dai)
david_williams: pmc_approved? (deboer)
neil.hauge: pmc_approved+
david_williams: pmc_approved? (kaloyan)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2010-02-25 12:15:31 EST 
See bug 291637 for a broader discussion. 

In Web Tools, we have historically always used the following URL for our update sites: 

http://download.eclipse.org/webtools/updates/ 

But, this needs to change, for a few reasons. For one, (if we have to change it anyway) the term "updates" is now inaccurate or at least old-fashioned ... it is more of a "repository". 

Also, because we now want repositories to persist forever, it is too "high level". For each major release, we should have one specific to that release. Also, using the "version number" is pretty old fashioned too, and I see no reason not to use the yearly release name. such as 

http://download.eclipse.org/webtools/repository/helios


While we can (and should?) still provide 
http://download.eclipse.org/webtools/repoository 
as a viable URL, it is anticipated that, over the years, it would perform slower and slower, so it would be best to normally point people to a more specific one, for any particular release. 

And, while not normally advertised to most users, under the covers, we will have separate ("hierarchical") repositories for each maintenance or off-cycle release. Currently, I'd prefer date-time-stamp directories for these (rather than, say "SR0", "SR1", "SR2", because then "off cycle" release fit in more naturally, so these very specific URLs would look like 

http://download.eclipse.org/webtools/repository/helios/201006260900/

So, the suggestion is that for feature update URLs, the value would be 

http://download.eclipse.org/webtools/repository/helios/

We'd probably want to do this by M6, since it is "UI". (That is, might effect documentation, screen captures, or similar). 

Comments? Suggestions?
Comment 1 David Williams CLA 2010-05-24 09:45:08 EDT 
There's another twist to this ... 

Having this URL in each feature is not needed, doesn't do anyone any good, and should be removed from all features, except for those that can be expected to be installed "on its own" via some known package or distribution. 

That is, we'd pick just a 2 or 3 "key" features. provide the update URL in them, and simply omit it from all others. 

This is a difference in the whole p2 update concepts ... where being in the update URL gets something added to the software sites list (so, being in multiple features does no good). 

Likewise, we should just remove any mention of "discovery URL". There's some subtle differences, where its default state will be "enabled" but that doesn't seem like a big need, and in most cases not desired.
Comment 2 David Williams CLA 2010-05-24 09:54:43 EDT 
So, I think only two features _need_ the URL: 

jsdt and 
xml_ui

I think any other package or distribution would have one of these features. 

There might be others desired, where components are used "stand alone" (e.g. xpath2 processor? One fproj feature? But, I'll let those owners decide. Perhaps in those contexts, you wouldn't want to provide an update URL anyway?
Comment 3 David Williams CLA 2010-05-24 09:56:46 EDT 
So, I'll start working on removing many. 

I the few cases we want to list one, I'd like to propose the "name" be standardized on 

# "updateSiteName" property - label for the update site
updateSiteName=Eclipse Web Tools Platform (WTP) Repository 

and the URL standardized to 

<url>

<update label="%updateSiteName" url="http://download.eclipse.org/webtools/repository/helios"/>

</url>
Comment 4 David Williams CLA 2010-05-24 12:36:56 EDT 
Dave, adding you to CC. Since it will be incorrect, I removed the update URL in 

org.eclipse.wst.xml.xpath2.processor.feature

If you think there's some standalone install scenarios where users would want or get the URL from this feature, feel free to add back correct one. (But, in many scenarios, they may have it there already).
Comment 5 David Williams CLA 2010-05-24 12:40:43 EDT 
Konstantin, add you explicitly to CC. Since the URL will be incorrect, I removed the update URL from 

org.eclipse.wst.common.fproj.feature

If there are some stand-alone scenarios, where this feature needs to provide its own update URL, please feel to add back a correct one. (But, as mentioned, in many cases the URL will be in software sites list anyway, from other means).
Comment 6 Konstantin Komissarchik CLA 2010-05-24 13:09:23 EDT 
Thanks for the head's up David. I do not see a big issue with not including the update site URL in the fproj feature.
Comment 7 David Carver CLA 2010-05-24 13:51:30 EDT 
(In reply to comment #4)
> Dave, adding you to CC. Since it will be incorrect, I removed the update URL in 
> 
> org.eclipse.wst.xml.xpath2.processor.feature
> 
> If you think there's some standalone install scenarios where users would want
> or get the URL from this feature, feel free to add back correct one. (But, in
> many scenarios, they may have it there already).

This should be fine.  Most standalone scenarios are non-eclipse scenarios for the PsychoPath processor, so they won't even be using the update repository url in this case.   They can grab a jar from Hudson if they need it.
Comment 8 David Williams CLA 2010-05-27 17:38:44 EDT 
appears all fixed. Will confirm as RC3 rolls out.
Comment 9 David Williams CLA 2010-05-28 20:26:23 EDT 
Looks like I missed releasing one for RC3, wst.common.fproj so I have released it for RC4.
Comment 10 David Williams CLA 2010-05-30 02:29:12 EDT 
Have rebuilt RC3 to pick this up.