Hi Antonio, Thank you for the suggestion and confirming it works. I have added the sites to category.xml but still have them in feature.xml (as discovery URLs). I was wondering if in your experience it’s better to have them in category, feature or both? Only to simplify maintenance. My initial thought is that if we just have the Epsilon update site as a discovery URL in the core feature, then in theory we can remove the references to other update sites in feature.xml, since every feature depends on core via <includes> (either directly or indirectly). Also Dimitris and I had briefly discussed the situation with EuGENia’s dependencies and wondered if you have any thoughts on that front. The problem is that whilst in the manifest we now require GMF (no longer optional), we do not depend on ALL of GMF which may cause some problems. So the workaround has been to put GMF as <includes> (see [1]), which results in the GMF binaries, plugins and features being added to our update site (see [2]). Any way we can force installation of these features without <includes> or Require-Bundle? Thanks, Sina [1] https://git.eclipse.org/c/epsilon/org.eclipse.epsilon.git/tree/features/org.eclipse.epsilon.eugenia.feature/feature.xml [2] https://download.eclipse.org/epsilon/interim/binary/ Hi Sina, Yes, target platforms need you to find everything yourself, which is annoying. We're using the "Additional Repositories" bit for the Hawk update sites and that seemed to work just fine :-). Hi Antonio, Good point! At the time I was trying so many things and most of them didn’t work, so I presumed the same would be true for sites added to category.xml. I’ve also referenced some sites in feature.xml of some projects: presumably this is redundant? I’ll give it a go anyway. However for the Oomph setup I think they still need to be explicitly declared, so at a minimum we need to maintain setup file and category.xml for users, and the target platform for developers. Thanks, Sina Hi Sina, I was going to suggest using the "Repository Properties" tab of the category.xml editor, adding "Additional Repositories" entries. In fact, we already do that for Emfatic. Those sites will be automatically added when the user loads our update site for the first time - the user has the convenience of getting everything working in one go, and our update sites will take up less space in download.eclipse.org. Users will also be able to get updates of those third-party projects without us having to rebuild the update site. Hi everyone, I’ve recently been spending a lot of time to get the update site in good shape – specifically, to resolve dependencies without the user having to manually add repositories or install them. After a lot of headscratching and scouring mailing lists, forums and Bugzilla, the solution was actually relatively simple. https://download.eclipse.org/epsilon/interim/ is now a P2 repository, built using the eclipse-repository Tycho packaging in org.eclipse.epsilon.updatesite.interim’s pom.xml. So, we don’t need to ask users to add update sites to their list. I propose that we update the website to remove links to dependencies to simplify maintenance and keeping things up to date. There are now “only” two places we need to declare external dependencies: in the target platform and in epsilonUse.setup. Thanks, Sina _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epsilon-dev
-- Antonio Garcia-Dominguez _______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/epsilon-dev
-- Antonio Garcia-Dominguez |
