Bugzilla – Full Text Bug Listing
| Summary: | Add support for associateSitesURL <site/> attribute | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Greg Amerson <gregory.amerson> | ||||||||
| Component: | Tycho | Assignee: | Project Inbox <tycho-inbox> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | P3 | CC: | igor, pascal, robert.munteanu, suresk, t-oberlies | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Greg Amerson
Created attachment 196394 [details]
0001-bug-346926-Support-associateSitesURL-attribute-in-si.patch
This patch was ported from the original patch from TYCHO-296. Since I didn't originally author the patch I didn't modify any of the headers for the modified java files.
Since the code was not 100% written by "Submitting Contributor", we'll have to do CQ thing for this patch it seems (http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf) Maybe I should try to contact Spencer to have him repost his patch here since he was the original author and we wouldn't have to go through that process. No need to repost, just "sure, I am fine with this" comment from Spencer here should be enough. CQ in this case should not be terribly difficult to do I believe, so even if Spencer does not reply it should not be a big deal. I'm fine with Greg's enhancements to my original patch. Let me know if there is anything else you need from me to move forward. Thanks Spencer. Igor, do we need a unit test to move forward? If so i can give it a shot with an updated patch but will likely need some pointers along the way. Created attachment 196805 [details]
0001-bug-346926-Support-associateSitesURL-attribute-in-si.patch (Update #1)
I've updated my patch and now this one contains an additional unit test that covers this new functionality. The test just checks to make sure that the associate-sites.xml will be copied to the target site folder which is all that is needed to properly support the associateSitesURL.
What needs to happen next to help this patch get accepted? Comment on attachment 196805 [details]
0001-bug-346926-Support-associateSitesURL-attribute-in-si.patch (Update #1)
I reviewed and applied the patch. Thank you.
We still need to make this work for the eclipse-repository packaging type (or whatever we agreed to call it), so I keep this bug open to make sure we do not forget.
> We still need to make this work for the eclipse-repository packaging type (or
> whatever we agreed to call it), so I keep this bug open to make sure we do not
> forget.
While it is pretty clear how associate sites are defined & handled when the source artifact is a site.xml, I am not sure how this integrates properly with eclipse-repository. I think this will need more thought and help from the community. Whoever wants to drive this should open a new enhancement request for this.
To document the new feature in eclipse-update-site, I am closing this bug.
On second thoughts, I even think that associate sites are already supported by eclipse-repository. The "native" p2 solution is to define these sites via a touchpoint [1], and eclipse-repository fully supports p2.infs for products, features, and bundles. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=234213#c20 (In reply to comment #11) > On second thoughts, I even think that associate sites are already supported by > eclipse-repository. The "native" p2 solution is to define these sites via a > touchpoint [1], and eclipse-repository fully supports p2.infs for products, > features, and bundles. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=234213#c20 Unfortunately the p2.inf doesn't solve one of the main reasons why I use associate sites. In my eclipse plugins I depend on several upstream eclipse.org frameworks that are not yet published on the eclipse release trains. So in order for the user to be able to resolve all the dependencies that my bundles have they must have added several new updatesites. Instead of instructing end-users of my plugins to add 2 additional updatesites in addition to my own updatesite, I just instead want to use the associateSitesURL so I can list those associate sites. With eclipse-repository + p2.inf that does not solve this problem. With p2.inf I can add respositories to the user's install manager post-install of my features, but not pre-install, so those updatesites are not available in the dependencies resolution/planner stage of the p2 install process. So for eclipse-repository packaging type a solution for the "associate sites" in the sense of planning/dependency resolution stage is not yet available and probably needs its own bugzilla entry. However, the p2 team doesn't seem to have a good solution for this as I've asked on the p2 mailling list with no suggestions. FYI, I've started http://wiki.eclipse.org/Tycho/Split_eclipse_repository_and_product_packaging_types#eclipse-repository_user_stories to collect requirements for eclipse-repository rework and opened corresponding bug 348586 (In reply to comment #12) > However, the p2 team doesn't seem to have a good solution for this (...) IMHO a composite p2 repository with your p2 repositories and the repositories from the target platform is a good solution. Wouldn't it be neat if eclipse-repository could automatically create such a composite as side product? (But not as part of this bug ;-) (In reply to comment #14) > (In reply to comment #12) > > However, the p2 team doesn't seem to have a good solution for this (...) > > IMHO a composite p2 repository with your p2 repositories and the repositories > from the target platform is a good solution. Wouldn't it be neat if > eclipse-repository could automatically create such a composite as side product? > (But not as part of this bug ;-) Ah yes, composite repository would be a good solution for this now that you mention it. That is likely a good way forward, should we mention that on this page? http://wiki.eclipse.org/Tycho/Split_eclipse_repository_and_product_packaging_types#eclipse-repository_user_stories (In reply to comment #15) > Ah yes, composite repository would be a good solution for this now that you > mention it. That is likely a good way forward, should we mention that on this > page? > http://wiki.eclipse.org/Tycho/Split_eclipse_repository_and_product_packaging_types#eclipse-repository_user_stories Yes, please add your user stories to the page. I think that "lets use composite repository for that" is only one possible implementation, so it would be helpful to understand underlying use case. Looking again at the http://wiki.eclipse.org/Tycho/Split_eclipse_repository_and_product_packaging_types#eclipse-repository_user_stories page. I believe my user story is covered by the first one. Its where I want to create a repository that contains multiple features but it doesn't contain all of the transitive dependencies. So I need an "associate sites" type concept which is covered in that first story. So unless we need a section on "possible implementations" I think we are covered. (In reply to comment #1) > This patch was ported from the original patch from TYCHO-296. Since I didn't > originally author the patch I didn't modify any of the headers for the modified > java files. @Igor: Please review the IP log entry for this patch. It currently gives Greg the credits for this patch, although this should (probably) be credited to Spencer. IP log is generated from bugzilla and we are supposed to mark individual patches with "iplog" flag (which I already did) and I believe we don't need to do anything else. This is only the case if the author attaches the patch. However in this issue, Spencer attached the patch, although Greg is the author - therefore the current IP log entry is wrong. You either need to correct it manually [1], or, probably easier, have Greg attach his patch again and "move" the iplog flag over to that attachment. [1] http://wiki.eclipse.org/Development_Resources/Automatic_IP_Log What exactly do I need to do? Just resubmit the patch only or do I have to do something with the iplog flag? @Tobias please ask EMO IP Team if you believe this patch requires special treatment. (In reply to comment #21) > What exactly do I need to do? Sorry, I had it the wrong way round. We need the author of the patch, i.e. Spencer Uresk to attach the patch to this bug. @Spencer: Could you please re-attach your original patch from TYCHO-296 [1]. This would greatly help us maintaining our IP log. Thanks! [1] https://issues.sonatype.org/browse/TYCHO-296 Created attachment 198038 [details]
This is the original patch for supporting an associateSitesUrl in the site element.
I've attached the original patch for this enhancement.
(In reply to comment #24) > Created attachment 198038 [details] > This is the original patch for supporting an associateSitesUrl in the site > element. > > I've attached the original patch for this enhancement. Thank you, Spencer. With the patches attached by both authors (Spencer Uresk for the productive code, and Greg Amerson for the corresponding unit test), we now have the legal clearing to include this change. Note that the Git repository only shows a commit from Greg, because his patch includes the contribution from Spencer. So thanks again for this contribution :-) *** Bug 349632 has been marked as a duplicate of this bug. *** |