I've reviewed the user stories mentioned in http://wiki.eclipse.org/Tycho/Split_eclipse_repository_and_product_packaging_types#eclipse-repository_user_stories and added a note in the bug.
As for the technology, I'm not bound to XText. This all prototype started because I wanted to play with XText but that's about it :) On Wed, February 27, 2013 21:47, Igor Fedorenko wrote: > Better way to define contents of p2 repositories produced during Tycho > builds is something Tycho developers have considered for some time [1], > so I am happy to see other teams see this as desired improvement. I > think p2, pde and tycho should agree on a common "new" repository > definition format and use the same runtime to parse and manipulate it, > but I am generally not a big fan of DSL, especially if the > implementation comes with a very long dependency trail. > > I am wondering if it makes more sense to figure out what input > configuration information we need to capture first, and decide on the > best format and tools to work with this information after. > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=348586 > > -- > Regards, > Igor > > On 2013-02-27 9:15 PM, Pascal Rapicault wrote: >> What I currently see depends on Xtext which depends on EMF and others >> things, however I remember reading that it was possible to use this >> infrastructure outside of equinox, and I do see a generated class called >> RepoDSLStandaloneSetup with the following comment "Initialization >> support >> for running Xtext languages without equinox extension registry". >> >> What do you have in mind? >> >> On Wed, February 27, 2013 21:05, Igor Fedorenko wrote: >>> Will the generated parser and model classes work in standalone tools, >>> like Tycho, or will it require full-blown Eclipse runtime to work? >>> >>> -- >>> Regards, >>> Igor >>> >>> On 2013-02-27 8:56 PM, Pascal Rapicault wrote: >>>> I'm sending this to request feedback on how to better create >>>> repositories. >>>> Please direct all feedback, positive or negative to the bug >>>> http://bugs.eclipse.org/401960. What is below is the description that >>>> I >>>> put to the bug. >>>> >>>> When it comes to dealing with repositories, p2 offers a lot of >>>> flexibility >>>> that is not (or not easily) accessible through the old site.xml or >>>> category.xml file formats. >>>> Such things include, associated repositories, mirror URLs, download >>>> stats >>>> URL, nested categories, uncategorized content, etc. >>>> >>>> In attempt to overcome those limitations, and to learn XText, I >>>> created >>>> last summer the attached grammar which provides the basis for a >>>> repository >>>> DSL. Put in action, this DSL allows things like the following example, >>>> which I hope is sufficiently self explanatory: >>>> >>>> repoName: "My tools" >>>> referenceRepo: "http://download.eclipse.org/releases"; as "Juno" >>>> enabled >>>> hidden >>>> >>>> category: "Tools" >>>> iu:"org.eclipse.code.recomenders",["1.0.0", "2.0.0"] >>>> feature:"org.eclipse.pde" >>>> >>>> category: "Maven tools" >>>> iu:"org.eclipse.m2e" >>>> end >>>> end >>>> >>>> uncategorizedContent: >>>> feature: "someStuffThatNeedToBeInTheRepo" >>>> iu: "org.eclipse.p2" >>>> end >>>> >>>> >>>> As you can see the approach is fairly simple, describe what you want >>>> and >>>> you are done. In this example, I'm creating a Tools category that >>>> contains >>>> Eclipse recommenders, pde and a subcategory for Maven tools. Here I'm >>>> not >>>> making use of more advanced functionalities, but I'm sure you see >>>> where >>>> this is going. >>>> >>>> >>>> ** How will people work with this? >>>> This file will be used to replace site.xml and category.xml. People >>>> will >>>> be able to edit it using the Xtext generated editor (which includes >>>> all >>>> the bells and whistles an editor needs - (see below on addition >>>> completion >>>> for the various IDs)), or alternatively they should be able to edit it >>>> with a simple text editor or other more automation oriented tools. >>>> >>>> ** What is missing? >>>> Though I'm happy with the way things look, neither the grammar nor the >>>> editor are production ready, and we don't even have the p2 publisher >>>> bit >>>> that turns this DSL into a content.xml. >>>> >>>> On the grammar side the following things need to be added: >>>> - Inclusion mode. This element would allow to describe whether just >>>> the >>>> IU, its slice or resolved dependencies should be included in the IU. >>>> - Edition context. This element which should be located at the top of >>>> the >>>> DSL would tell the editor where it can find IDs to propose to the user >>>> in >>>> the completion. This could for example include target definitions, >>>> repos, >>>> etc. This entry would only be used for edition, but not at generation >>>> time >>>> where the context is provided by the build. >>>> - Stats tracker URL. The URL against which to report download stats. >>>> - Mirror list. The list of mirrors. >>>> - More simple format? I'm wondering if a Yaml like format would be >>>> better >>>> for ppl gre'ing, etc. >>>> >>>> On the editor side, the completion logic needs to be added. >>>> >>>> >>>> ** Where will the project be hosted? >>>> Though the prototype is currently on my personal bitbucket account >>>> (https://bitbucket.org/prapicault/p2-repo-dsl), this is something that >>>> belongs to p2 or PDE and will be moved to the Eclipse Foundation once >>>> there is enough traction around it. >>>> >>>> Pascal > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > _______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
