This is *not* a new runtime format. This is only a development time one. The information there is converted to a content.xml / content.jar through some
publication step. This is similar to what we are doing today with site.xml or category.xml.
As for generating the editor at build time, I’m not sure that this is an approach that we want to follow on this, though I know this is what should be done.
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ian Bull
Sent: February-28-13 2:35 AM
To: Pascal Rapicault; P2 developer discussions
Subject: Re: [p2-dev] Improving the way repositories are described
I assume this is for 'development' time (publishing time) only, not runtime? That is, a repository specified in this format will be 'compiled' into the standard repository format (content.xml). Or were you thinking of providing a new repository
format to p2?
My concern is similar to Igor's, and that's the dependency trail. In particular, the build time dependencies we'll have on Xtext. The last year has certainly taught us that 'builds are hard'. How do we keep the Xtext compiler up-to-date?
How well does it work with Tycho? Can you version the Xtext tools that were used to ensure we get reproducible builds? Are these tools fetched from a Maven repository, or are we going to have a complicated 'base builder'?
I'm not opposed to this idea, and certainly Xtext is the right tool for the job. These are just a few concerns I have.
On Wed, Feb 27, 2013 at 7:53 PM, Pascal Rapicault <pascal@xxxxxxxxxxxxx> wrote:
I've reviewed the user stories mentioned in
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 ,
> 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.
> 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
>> 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?
>>> On 2013-02-27 8:56 PM, Pascal Rapicault wrote:
>>>> I'm sending this to request feedback on how to better create
>>>> Please direct all feedback, positive or negative to the bug
>>>> http://bugs.eclipse.org/401960. What is below is the description that
>>>> put to the bug.
>>>> When it comes to dealing with repositories, p2 offers a lot of
>>>> 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
>>>> URL, nested categories, uncategorized content, etc.
>>>> In attempt to overcome those limitations, and to learn XText, I
>>>> last summer the attached grammar which provides the basis for a
>>>> 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"
>>>> category: "Tools"
>>>> iu:"org.eclipse.code.recomenders",["1.0.0", "2.0.0"]
>>>> category: "Maven tools"
>>>> feature: "someStuffThatNeedToBeInTheRepo"
>>>> iu: "org.eclipse.p2"
>>>> As you can see the approach is fairly simple, describe what you want
>>>> you are done. In this example, I'm creating a Tools category that
>>>> Eclipse recommenders, pde and a subcategory for Maven tools. Here I'm
>>>> making use of more advanced functionalities, but I'm sure you see
>>>> this is going.
>>>> ** How will people work with this?
>>>> This file will be used to replace site.xml and category.xml. People
>>>> be able to edit it using the Xtext generated editor (which includes
>>>> the bells and whistles an editor needs - (see below on addition
>>>> 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
>>>> 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
>>>> IU, its slice or resolved dependencies should be included in the IU.
>>>> - Edition context. This element which should be located at the top of
>>>> DSL would tell the editor where it can find IDs to propose to the user
>>>> the completion. This could for example include target definitions,
>>>> etc. This entry would only be used for edition, but not at generation
>>>> 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
>>>> 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.
> p2-dev mailing list
p2-dev mailing list
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484