Community
Participate
Working Groups
Build Identifier: Eclipse 3.6.0 The enterprise users of our product don't allow their end users to pick up updated components from the internet. So they want to hide all the eclipse update repositories and only expose the ones contributed by themselves. They used to create a parent feature to contain all the eclipse features to achieve this goal. P2 now provides a touch point action to remove the repository URLs. But we found that the removed URLs would come back when searching for a update. Reproducible: Always Steps to Reproduce: 1. Start eclipse SDK 2. Create a feature com.abc.test.feature which contains eclipse SDK 3. Create a update site project and add the created feature com.abc.test.feature to it 4. Build the update site 5. Install feature com.abc.test.feature as a new feature from the update site 6. Open the preferences page and remove all the eclipse related repository URLs 7. Bump up the version number of com.abc.test.feature and rebuild the update site 8. Run the action Check for Updates which should find the newly built com.abc.test.feature 9. Cancel the installation and open the preferences page 10. The deleted eclipse repository URLs come back again We also found that revert an installation history would also bring back the deleted URLs
This works as expected. The repositories are being added by some IUs that are required from the org.eclipse.sdk.ide IU. This is the definition of the SDK. If you don't want to have those repositories being added, then you need to selectively pick the IUs of the SDK.
I can't agree with the statemenet in comment 1. Since an end user is given the option to remove the URLs, his choice should be honored. P2 should check for the user's override when collecting the URLs from IU.
The URIs for the extra repositories are provided as referenced repositories in the metadata. If you have a company policy of only installing from local servers and you provide a local/internal copy of the metadata and that is where your users are installing from, then a work-around would be modify your copy of the repository's metadata to not include the referenced repos.
The problem is that the remove the URL would come back again during the update. Even the ones were manually removed from the preferences page. This is not an enhancement request. This is a bug.
If you are only connecting to local copies of repositories which have been modified to not include the referenced repos, I don't understand how the removed repos would re-appear on updates. Please explain.
Samuel, although I have seen this issue before, I've re-run your initial scenario as described in comment #0 and cannot reproduce the problem with those steps. Are you able to attach the metadata for your product to this bug report? (or the internal one if it is non-public data) We've discussed this issue a bit and the metadata actions which add the repositories is only attached to the product so if you are building your own product, then it should not have the actions defined by the SDK product.
Created attachment 178926 [details] product profile
Did you pick up a built eclipse SDK 3.6.0 when producing it? I can constantly reproduce it. There are nine .gz files in my ...\eclipse\p2\org.eclipse.equinox.p2.engine\profileRegistry\profile.profile. I'm attaching the last one
Yes. Please attach a copy of the metadata for your product. Thanks.
It's already uploaded in comment 7
That is your profile contents. I'm looking for the content.xml for your repository that you are installing from. (just in case there is a difference)
Created attachment 178971 [details] content.xml in zip
The content.xml file that you provided here indeed contains a list of reference repositories which is re-read when you go to do the update and then added to your list of repositories. As a work-around you can do what is mentioned in comment #3. If you modify the local copy of the repository metadata (content.xml) then the repositories will not be added back during an update.
Can you please advise how to modify this content.xml since it was generated by the feature build ? And it is rebuild nightly.
The repository references are being adding to your content.xml because they are listed in the features that you are building. The first answer would be to remove those references from the features. But if you do not control their content, then PDE/Build provides several places to hook into the build and run custom Ant targets. You should easily be able to write a block of Ant code which reads the content.xml file and strips out the proper element.
Can you please provide an example of this ant script? I'm not familiar with content.xml and I don't want to corrupt it. This work around may work for our product build but our customers will still run into the problem. Our customers usually do some customization of the product and delpoy the product along with the customization. They achieve this by creating an enterprise feature which includes our main feature. The enterprise feature will be made available on internal update site. They use the update project provided by PDE to build the update site. Content.xml is in the jar file content.jar in this case. It's just too problem-proning.
In the example you posted, you just need to remove the <references> element and everything contained within it. Thus: <repository ... > <properties size='2'> <property name='p2.timestamp' value='1284559201296'/> <property name='p2.compressed' value='false'/> </properties> <references size='28'> ... </references> <units size='947'> ... </repository> becomes: <repository ... > <properties size='2'> <property name='p2.timestamp' value='1284559201296'/> <property name='p2.compressed' value='false'/> </properties> <units size='947'> ... </repository> Documentation for Ant can be found at http://ant.apache.org/ or by doing a quick Google search.
Please advise which ant task to call and what operands need to be set.
You are trying to modify the default behaviour of your repo. There are no pre-defined tasks for that, you'll have to write some XSLT to do it. Here are 2 examples that also seek to modify repo metadata at [1] and [2]. And here is an example of an ant script that calls it. See the postBuild target in [3]. [1] http://dev.eclipse.org/viewcvs/viewvc.cgi/e4/releng/org.eclipse.e4.builder/builder/general/fix-ibuild.xsl?view=co&content-type=text%2Fplain [2] http://dev.eclipse.org/viewcvs/viewvc.cgi/e4/releng/org.eclipse.e4.builder/builder/general/patch-ver.xsl?view=co&content-type=text%2Fplain [3] http://dev.eclipse.org/viewcvs/viewvc.cgi/e4/releng/org.eclipse.e4.builder/builder/general/customTargets.xml?view=co&content-type=text%2Fplain
