[eclipse/xtext#1976] pin explicit transitive deps in xtext.xtext.gene…

[LorenzoBettini]

This pins all transitive dependencies of org.eclipse.xtext.xtext.generator, in particular, the ones with version ranges (EMF, JDT and other platform dependencies) that are taken from org.eclipse.emf:org.eclipse.emf.codegen.

This should fix eclipse-xtext/xtext#1976

(see also xtext/xtext-reference-projects#188)

Signed-off-by: Lorenzo Bettini [email protected]

[cdietrich]

@kthoms @szarnekow @ArneDeutsch @miklossy we should somewhen come together and decide how to continue with this mess

[LorenzoBettini]

@cdietrich the build fails because probably I don't understand whether I should have touched releng/pom.xml like that

<upstreamBranch>lb_xtext_issue1976</upstreamBranch>

should I remove that?

[cdietrich]

just create that branch on lib too and start core again when lib has been built

[LorenzoBettini]

@cdietrich thanks (the joys of multiple repositories ;)
Now the build succeeds. I don't understand if this is a proof that this works or if we should build other repositories.

[cdietrich]

you would have to build a "Sammelsurium" of maven repos like here
and use master for downstream and your branch for lib and core like here
#393 (comment)
in your test project
(e.g. in xtext-reference-projects)

[LorenzoBettini]

Should we wait for feedback first?
By the way, by "other repositories" I meant Xtext ones. I seem to understand that due to transitive dependency hell other Xtext CI jobs used to fail.

[cdietrich]

you can always

• create branches everywhere
• use adjustPipelines in umbrella
• add all changed files
• commit them and push them as "use upstream"
• cancel all build
• restart the lib branch with the trigger downstream checkbox set.

[LorenzoBettini]

OK, but is the fact that this build succeeds is a good thing?
I mean: was the problem already there in this repository without any intervention?

[cdietrich]

No there is not test

[cdietrich]

You can also try a gradlew generateTestLanguages -PuseJenkinsSnapshots=true

[LorenzoBettini]

In this repo?

[cdietrich]

Yes

[LorenzoBettini]

@cdietrich There's a failure that does not seem to be related to this... but I don't understand... maybe you know... or maybe I did not write correctly the step in the Jenkinsfile

[cdietrich]

@LorenzoBettini this is not meant to be ran on jenkins. please try locally.

[LorenzoBettini]

@cdietrich I'm getting the same error also locally...

[cdietrich]

You should clone eclipse next to core

[LorenzoBettini]

OK, on my machine it works (using Java 8), but I see no trace of org.eclipse.xtext.xtext.generator in the .gradle directory and since I don't know gradle at all I have no idea whether this tests anything...

Anyway, let's wait for some feedback by others

[cdietrich]

can you please rebase and also create a base branch in lib and check if the bom has all of them

[LorenzoBettini]

The BOM has all of them (it's been having them since the beginning I guess) and I made sure of that when I created the PR
but I don't know what api and optional implies in Gradle (https://github.com/eclipse/xtext-core/pull/1714/conflicts)

[cdietrich]

optional wont end up is maven unfortunately

eclipse-xtext/xtext#1847

[LorenzoBettini]

so we can't use optional to fix this

[cdietrich]

yes we would need to make all non optional.

[cdietrich]

some seem to be missing

[LorenzoBettini]

Those ones do not depend on other Eclipse bundles like JDT or other ones that have version ranges that might break things, so they should be harmless, IIRC

[cdietrich]

@szarnekow @kthoms as the optional thing is not working for generated poms.
is there anything that speaks against simply blowing up the transitive hull for the generator?

[szarnekow]

is there anything that speaks against simply blowing up the transitive hull for the generator?

I don't think so.

[cdietrich]

created #1804 as replacement