[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Improving the way repositories are described

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