Community
Participate
Working Groups
The (Tools) Update Site is currently titled "Eclipse OCL Tools Build Site". After searching for it in the Intall New Software pull-down I think "OCL Update Site" is better for the Core+Tools update site "OCL Core Update Site" if someone actually gets hold of the Core ZIP If "Group items by category" is unchecked, the user has 17 install options. But if "Group items by category" is checked, there are only three. I suspect that some hierarchical names are needed so that all 17 items reappear but in a tree.
(In reply to comment #0) > The (Tools) Update Site is currently titled "Eclipse OCL Tools Build Site". > After searching for it in the Intall New Software pull-down I think > > "OCL Update Site" is better for the Core+Tools update site > "OCL Core Update Site" if someone actually gets hold of the Core ZIP > I think that Bug 369313 gives some reasoning about the name of the repository. This name doesn't appear in our public P2 repositories. In any case if you want to change it, it's OK to me and very easy. Just a question, do you want to follow EMF, and UML name convention, otherwise that one you suggested ?. > If "Group items by category" is unchecked, the user has 17 install options. > > But if "Group items by category" is checked, there are only three. I suspect > that some hierarchical names are needed so that all 17 items reappear but in a > tree. I guess that the "17 install options" are all the features of the p2 repository. However, most of them are transitively included by others so I'm not sure what you want. It's a matter of defining which (root) features you want to see when installing software from our repository. If you want to see other features, just let me know... but IMHO, the current selection is the best option. Regards, Adolfo.
It may be a 'P2' UI problem rather than our Update Site. On the initial 'OCL' select page I would like to see a full tree structure of all the features showing the include dependencies. Currently we can have a flat listing of 17 features, or a two-deep listing of about 5. The full hierarchy is only available in the confirmation phase. I'm wondering whether the limited hierarchy is becuase we have not defined categories appropriately or becuase P2 doesn't display them usefully. I don't hit this problem with the OCL site becauase I know it. The problem I typically get is how do I install all of EMF without ODA, or all of Xtext without GEF, so as a user I need to view the full hierrachy so that I can prune some leaf features.
I'm not sure why P2 should allow the user to "remove" "nested" features in the installation, when the "root" categorized features probably states that it includes the "nested" one. Maybe the installed software doesn't work without it. For your described case. I don't think it's a problem of/request for P2. In this case, it's a problem of the EMF repository for not providing a categorized feature which doesn't include the ODA one.... BTW, this is not real, EMF ODA driver comes with its own feature (EMF ODA Driver SDK), am I missing anything ?. Note: This bugzilla (similarly to Bug 369355) is also claiming for a rename of our public repositories. I'll create a dependency on the other bug. Once the related bug is solved, this one may be solved as well. Regards Adolfo.
(In reply to comment #3) > For your described case. I don't think it's a problem of/request for P2. In > this case, it's a problem of the EMF repository for not providing a categorized > feature which doesn't include the ODA one.... BTW, this is not real, EMF ODA > driver comes with its own feature (EMF ODA Driver SDK), am I missing anything > ?. I raised a Bugzilla on that to no effect. Prior to the Query delegates, the EMF All-In-One SDK was good news. Now the correct answer is EMF-SDK + XSD-SDK. You need the hierarchical view to discover this.
After solving Bug 369355, I've renamed our public repositories. The coming Attachment is a screenshot with the current main OCL public repositories. (In reply to comment #4) > (In reply to comment #3) > > For your described case. I don't think it's a problem of/request for P2. In > > this case, it's a problem of the EMF repository for not providing a > categorized > > feature which doesn't include the ODA one.... BTW, this is not real, EMF ODA > > driver comes with its own feature (EMF ODA Driver SDK), am I missing anything > > ?. > I raised a Bugzilla on that to no effect. Prior to the Query delegates, the EMF > All-In-One SDK was good news. Now the correct answer is EMF-SDK + XSD-SDK. You > need the hierarchical view to discover this. I'm not sure I follow... Could I resolve this bug as fixed ? Regards, Adolfo.
Created attachment 210606 [details] Watch out of OCL public repositories
(In reply to comment #6) > Created attachment 210606 [details] Ah. I see a confusion. You are looking at the names of the online repositories. I am looking at the names of the offline downloaded ZIPs. (In reply to comment #5) > > I raised a Bugzilla on that to no effect. Prior to the Query delegates, the EMF > > All-In-One SDK was good news. Now the correct answer is EMF-SDK + XSD-SDK. You > > need the hierarchical view to discover this. > > I'm not sure I follow... If you install the EMF All-In-One SDK offline without pre-installing ODA the EMF install fails. EMF-SDK + XSD-SDK can be installed offline without prerequisites.
(In reply to comment #7) > (In reply to comment #6) > > Created attachment 210606 [details] > > Ah. I see a confusion. You are looking at the names of the online repositories. > I am looking at the names of the offline downloaded ZIPs. > Ok. I assumed that the other bug concerned the offline downloaded ZIPS, therefore this one claimed for our public repositories. Anyway, I beleive that the same reasoning applies, so I'll maintain the current names as-is. If you prefer I revert the names, let me know it. Regards, Adolfo.
Now that Core and Tools builds have merged there is jusrt the "OCL Build Site".
CLOSED after more than a year in the RESOLVED state.
