Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 349075 - Cannot update bundles that came with our product installer (able to update bundles provisioned using p2)
Summary: Cannot update bundles that came with our product installer (able to update bu...
Status: CLOSED WORKSFORME
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: p2 (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: P2 Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-10 12:53 EDT by David Peraza CLA
Modified: 2011-06-11 15:46 EDT (History)
1 user (show)

See Also:


Attachments
DefaultProfile latest state file (33.12 KB, application/x-gzip-compressed)
2011-06-10 12:58 EDT, David Peraza CLA
no flags Details
content jar containing update metadata repository info (919 bytes, application/x-zip-compressed)
2011-06-10 13:00 EDT, David Peraza CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Peraza CLA 2011-06-10 12:53:33 EDT
Build Identifier: Build id: 20100917-0705

We have a full osgi app running on equinox. Our build generates what I though was a p2 enabled driver. Driver includes launcher and all application bundles under plugins directory. The build also generates a p2 repository that we export to our test site. This drivers will get layout not using the p2installing but Install Anywhere installer instead. Once the driver gets install people can start running our app, no problems. If they want an update they can point to a p2 repository we give them and then run some simple commands we created around your p2 InstallOperation and UpdateOperations services. My logic is this. I first find the IUs that are completely new bundles not found in DefaultProfile, then I use InstallOperations to install that list. Then I figure out IUs that are new versions of existing IUs and I update those using the UpdateOperations service. Here is what works: I can install new bundles via p2 and I'm able to update those. Here is what I can't get to work: I can't update those bundles that came with the installer, the UpdateOperations claims there is not updates available. I query the DefaultProfile and I see the old version, I query the repo with new metadata and artifacts and I see the new version. No quite sure why update installer is not finding the new updates in the new repo. Another thing I tried was to use your provremove and provinstall commands. That half worked, I'm not able to really uninstall the old version, the two versions run side by side, not what I want. 

Code snippets:

This is how I get the agent

agent = agentProvider.createAgent(null); //null to get current running agent

This is how I install new bundles in repository:

InstallOperation installOperation = new InstallOperation(
						new ProvisioningSession(agent), newIus);
				IStatus result = installOperation.resolveModal(new NullProgressMonitor());
				if (result.isOK()) {
					Job job = installOperation.getProvisioningJob(new NullProgressMonitor());
					job.schedule();
				} else {
					updStrm.println(Messages.getInstance().getString(locale, "updates.new.error", result.getMessage())); //$NON-NLS-1$
				}

This is how I do updates after new bundles have been installed

// Still some update needed
			if (newIus.size() != iuUpdates.size()) {
				UpdateOperation updateOperation = new UpdateOperation(
						new ProvisioningSession(agent));
				IStatus result = updateOperation.resolveModal(new NullProgressMonitor());
				if (result.isOK()) {
					Job job = updateOperation.getProvisioningJob(new NullProgressMonitor());
					job.schedule();
				} else {
					updStrm.println(Messages.getInstance().getString(locale, "updates.existing.error", result.getMessage())); //$NON-NLS-1$
					return;
				}

			}

Reproducible: Always

Steps to Reproduce:
1. Install product without using p2install
2. Add a p2 repo containing updates to bundles installed on product
3. Try to do an update
4. System responds with "No updates were found"
Comment 1 David Peraza CLA 2011-06-10 12:58:06 EDT
Created attachment 197801 [details]
DefaultProfile latest state file

This file was asked for by Pascal on mailing list
Comment 2 David Peraza CLA 2011-06-10 13:00:15 EDT
Created attachment 197802 [details]
content jar containing update metadata repository info

Metadata info requested by Pascal on mailing list
Comment 3 Pascal Rapicault CLA 2011-06-10 22:40:30 EDT
Assuming that the profile and the content.jar are corrects, it is normal that no updates are being found. This is because p2 only look for updates for the "roots", and not all the IUs that are part of the profile. A "root" is best identified by something that has been explicitly installed, be it by the end user through the UI or the build using the director app.

Now to put that in perspective of your use-case:
- The initial install has one root called com.ibm.cfs.product.
- The repository contains com.ibm.cfs.core
Therefore when p2 looks for update, it will look for com.ibm.cfs.product and there is nothing to be found.

What is important to understand here is that the granularity of the updates is determined by the roots you have. If you want to have a fine grained update, then you need to split up your product into different features and get them installed into your base one by one so there are multiple roots.
The reason why p2 takes this root approach is two fold:
- it helps with figuring out the IUs that are no longer usable
- in case of updates it prevents getting prompted for spurious updates (e.g. as a user I don't want to be presented with updates for osgi)

Does that make sense?
Comment 4 David Peraza CLA 2011-06-10 23:08:27 EDT
(In reply to comment #3)
> Assuming that the profile and the content.jar are corrects, it is normal that
> no updates are being found. This is because p2 only look for updates for the
> "roots", and not all the IUs that are part of the profile. A "root" is best
> identified by something that has been explicitly installed, be it by the end
> user through the UI or the build using the director app.
> Now to put that in perspective of your use-case:
> - The initial install has one root called com.ibm.cfs.product.
> - The repository contains com.ibm.cfs.core
> Therefore when p2 looks for update, it will look for com.ibm.cfs.product and
> there is nothing to be found.
> What is important to understand here is that the granularity of the updates is
> determined by the roots you have. If you want to have a fine grained update,
> then you need to split up your product into different features and get them
> installed into your base one by one so there are multiple roots.
> The reason why p2 takes this root approach is two fold:
> - it helps with figuring out the IUs that are no longer usable
> - in case of updates it prevents getting prompted for spurious updates (e.g. as
> a user I don't want to be presented with updates for osgi)
> Does that make sense?

I think it does, so we only have the product bundle as a root and what I really need is all my bundles to be root (we are not building features yet). One way to do that, as I unerstand, is have the build install all the bundles via director app. Then I can package that with install anyware and send to the customer. Question though, is there any type of maven integration to create a base by installing from the p2 repos that we build? Or do I need to have a script calling director app and then hook that with maven? I will test this scenario manually first an let you know. 

Thanks much for you help. Things start to make more sense now.
Comment 5 Pascal Rapicault CLA 2011-06-11 11:41:52 EDT
> I think it does, so we only have the product bundle as a root and what I really
> need is all my bundles to be root (we are not building features yet). 
   Yes this is correct, and you would have to not install the product IU itself since it has strict dependencies on the IUs it contains (this is how the metadata is generated). The way to think about it is that anything that gets explicitly installed aka roots (e.g. through the director) will be locked and if any of these roots have strict dependencies on other IUs they will be locked as well.

> to do that, as I unerstand, is have the build install all the bundles via
> director app. Then I can package that with install anyware and send to the
> customer. Question though, is there any type of maven integration to create a
> base by installing from the p2 repos that we build? Or do I need to have a
> script calling director app and then hook that with maven? I will test this
> scenario manually first an let you know. 
   I don't know of any way to do this with tycho, however having the ability to create an install and explicitly specify the roots would be a good enhancement request.

Btw, I also opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=349123 to help better deal with situation like these.
Comment 6 Pascal Rapicault CLA 2011-06-11 15:46:30 EDT
closing since no p2 work is required