Community
Participate
Working Groups
When we build a repository using an update site project (build all) the category names are not unique. It looks like we pass "" for the category qualifier. This can be fixed in a few ways. 1. We can use the site.location as a prefix in this case (consider "" as no qualifier) 2. Add a version to the category files (bug 261104) 3. Do both.
So if I have category "A" on site "SiteX" and category "A" on site "SiteY" what does the UI display? Is it displayed as two different categories or one?
When this bug is fixed, the content from both sites will appear in "A"
Created attachment 134107 [details] If the empty string is passed as a qualiifer name, then site.location will be used This fixes the problem using method (1) above.
done
Sorry, I changed my mind about this. For export, this results in ids that look something like id='file:/C:/Dev/Platform/Workspaces/junit-workspace/pde.build/PublishFeature_Bug270882/category.xml.new_category_2' Which isn't very good. The site location only really makes a good qualifier when its a real site instead of a file in the workspace.
I've released the changes on bug 261104, so the categories now get versions. I am not sure if anything needs to be done here. I like the ability to say that no qualifier should be used, particularly if the site/category xml uses proper ids. I don't like having build time paths as the qualifier. Ian, do you have any other ideas about qualifiers in export, or are we happying with versions (ie solution (2))
(In reply to comment #6) > I've released the changes on bug 261104, so the categories now get versions. > > I am not sure if anything needs to be done here. > I like the ability to say that no qualifier should be used, particularly if the > site/category xml uses proper ids. > I don't like having build time paths as the qualifier. > > Ian, do you have any other ideas about qualifiers in export, or are we happying > with versions (ie solution (2)) > I'm happy with the versions. I didn't really like the file name qualifier either. Have you reverted this patch? If so, I'm happy to call this bug fixed (as won't fix).
Yes, I reverted the changes. Marking as won't fix.
wait a minute...this means category merging won't work. See bug 274356. Or are you claiming that versioning will solve the problem? I haven't been following the versioning discussion, are the versions timestamped so we know they are unique across different exports?
(In reply to comment #9) > wait a minute...this means category merging won't work. > See bug 274356. > Or are you claiming that versioning will solve the problem? I haven't been > following the versioning discussion, are the versions timestamped so we know > they are unique across different exports? > Never mind, you very nicely explained this back in my bug! I'll verify that one against the next build...
(In reply to comment #9) > wait a minute...this means category merging won't work. > See bug 274356. > Or are you claiming that versioning will solve the problem? I haven't been > following the versioning discussion, are the versions timestamped so we know > they are unique across different exports? > Categories are now being versioned with 0.0.0.date. I'm pretty sure we go down to the second with date, so unless two exports happen at the exact same time, with the same ID, this should fix the problem. Do you think we have to worry about the date?
I think that it won't matter for the wizard that I am using. I will test this soon.
Can you dup this to the bug that fixed the problem with versions?
Verified fixed on 0511-2000 sdk.
Marking a dup of bug 261104. *** This bug has been marked as a duplicate of bug 261104 ***
