Re: [epp-dev] Future of Rust/Corrosion in EPP

[Mickael Istria <mistria@xxxxxxxxxx>]

On Fri, Feb 5, 2021 at 4:00 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hi everyone,

Hi,

I think we need to decide whether EPP is the place we build (only) the packages on eclipse.org/download and have some other place to build packages like Rust that are distributed through other channels.

I'm just reading https://projects.eclipse.org/projects/technology.packaging and found the link to the proposal https://www.eclipse.org/proposals/packaging/ . I don't see anything that mentions EPP goal is restricted to eclipse.org/download .

IMO, what's happening on eclipse.org/download belong to the Planning Council and it was already clarified on some previous Planning Council call that the EPP project was a regular Eclipse project, free of its move according to EDP. The only issues happen when eclipse.org/download or SimRel results are involved, where we need some sync with Planning Council.

We already have a place where packages are distributed, it's https://download.eclipse.org/technology/epp/downloads/release/ . Here we're free to put whatever technical artifacts makes sense to EPP.

For example, I think going forward we are asking for trouble having corrosion in EPP input repositories because it means that a package can pull in some deps from corrosion, even though they are available in simrel. e.g. corrosion's p2 repo that is in EPP input contains lsp4e, mylyn, gson, etc. This means that unless someone continue to ensure that the corrosion p2 repo has exactly the same version of each plug-in as simrel, we have situations where the EPP package can be built with artifacts not coming from simrel.

From Corrosion POV, what's interesting in EPP is that it brings some level of consistency with other packages, making users more comfortable when switching their target stack and their Eclipse IDE. Being fine-grained about which dependencies are coming from SimRel or not is not really that interesting; but I understand that this can cause an issue to other packages getting unexpected (&non-SimRel) artifacts.

At the moment, I don't have a concrete solution to this problem; we're missing a way to configure the build to always prefer artifacts from SimRel and restrict Corrosion artifacts to the Rust package.

As a specific proposal, I would suggest that at a minimum that the non-simrel repos are hidden behind the profiles of the non-eclipse.org/download and that the EPP release builds don't activate those profiles.

+1, the Corrosion repo should move to the epp.package.rust profile.

 

(PS better still would be to get Corrosion back in simrel and keep it as a first class member of the Eclipse IDE community :-)

I'm personally already dealing with many projects that are in SimRel. The many additional deadlines and constraints of SimRel are a source of stress and extra work that I don't think is profitable for Corrosion. But I'd gladly let anyone willing to invest their effort into bringing Corrosion back into SimRel just do it.