Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 461328

Summary:	P2 message needs improvement when opening a target definition file
Product:	[Eclipse Project] PDE	Reporter:	Peter Steinfeld <pete.steinfeld>
Component:	UI	Assignee:	PDE-UI-Inbox <pde-ui-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	dubauski_psl, pascal
Version:	4.5
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:	stalebug

Description Peter Steinfeld

2015-03-03 13:21:15 EST

I have an automated build that produces a P2 Software Site whose contents matches the contents of the build. So each build produces a new Software Site. For the entire build stream, there is also a composite P2 repository that points to the Software Site for the latest good build. Thus, the URL of the composite P2 repository does not change, but its contents are updated with every good build.

I have created a target definition file with a single location that contains the URL of this composite repository. Thus, when I open this target definition file, Eclipse looks at the composite P2 repository. This repository points to the P2 Software Site. Eclipse reads the contents of this site and resolves the target definition file based on its contents. This resolved target definition file contains a list of installable units along with their version numbers.

When new content is delivered to the build, the contents of the installable units changes as does their version numbers. The problem is that, when I open the target definition file after the contents and version of an installable unit changes, I get an error message that says that Eclipse is "Unable to locate installable unit ...". In this situation, the installable unit exists in the Software Site, but it has a new version. But the message does not contain either the version number that the target definition file expects or the version number found. If you open the target definition files with a text editor, you can see the expected version number.

Note that, for teams performing continuous integration, creating targets that contain new content and installable units with new version numbers is standard operating procedure. In fact, it's great that Eclipse is providing evidences that the target definition file needs to be updated. But the message should indicate that the installable units need to be updated rather than that their missing. Furthermore, it should recommend updating the location to fix the problem.

In summary, to fix this problem, I'd like to see a message that indicates that there's a new version of the installable unit rather than saying that it's missing. Furthermore, the message should recommend updating the location to fix the problem.

Here are the steps to reproduce this situation --
1. Create a P2 Software Site with some installable units.
2. Create a composite P2 repository that points to this Software Site.
3. Create a target definition file with a location that points to this composite repository.
4. Open the target definition file and be sure that it resolves all of the contents.
5. Close the target definition file.
6. Create a new P2 Software Site just like the original one, except that at least one of the installable units has a new version number.
7. Point the composite repository to the new Software Site.
8. Open the target definition file.

Comment 1 Pascal Rapicault

2015-03-31 21:44:32 EDT

Hey Peter, good to hear from you. I hope things are going well for you.

I'm moving this to PDE because improvements could probably be done there. Another possibility would be for PDE to automatically propose you an alternative set of IUs.

Note that as a workaround for people doing CI, it is probably easier to use 0.0.0 in the versions of the target definition. This way, p2 will always pick the highest version applicable. Note that I don't think the target editor supports 0.0.0 as an official version but you can edit the file by hand.

HTH

Comment 2 Peter Steinfeld

2015-04-06 16:09:15 EDT

Hey, Pascal.

Thanks for the information.  I am well, thank you.  I hope your are, too!

But I wanted to mention that we're now working on another technique to do continuous integration.  Here's a brief description.

We use a target definition file that points to a specific version of a specific P2 Software Site that contains the bundles that were used in the build.  We then check this target definition file into the source code repository that was used by the build itself.  Note that this target definition file contains the URL of the software site produced the build, so that it's easy to determine which version of the target definition file corresponds to which version of the build.

Then, when a developer wants to synchronize her Eclipse workspace to the integration stream, she accepts changes from the source code of the integration stream into her Eclipse workspace.  These changes include normal source code files such as *.java files along with a version of the target definition file produced by the latest good build from the integration stream.

This strategy also makes it relatively easy to synchronize your Eclipse workspace to a previous release and its associated build in the case where you want to create a bug fix for that build.

Comment 3 Eclipse Genie

2019-04-22 19:44:23 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 4 Lars Vogel

2019-10-29 05:33:41 EDT

This bug is marked as stale for some time. If it is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.