Milestone does not build on Jenkins

[cdietrich]

12:46:30 [ERROR] Failed to execute goal on project org.eclipse.xtext.ui: Could not resolve dependencies for project org.eclipse.xtext:org.eclipse.xtext.ui:eclipse-plugin:2.29.0-SNAPSHOT: The following artifacts could not be resolved: org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.29.0.M3, org.eclipse.xtext:org.eclipse.xtext.xbase.lib:jar:2.29.0.M3, org.eclipse.xtend:org.eclipse.xtend.lib.macro:jar:2.29.0.M3, org.eclipse.xtext:org.eclipse.xtext:jar:2.29.0.M3, org.eclipse.xtext:org.eclipse.xtext.util:jar:2.29.0.M3, org.eclipse.xtext:org.eclipse.xtext.ide:jar:2.29.0.M3: Could not find artifact org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.29.0.M3 in eclipse.maven.central.mirror (https://repo.eclipse.org/content/repositories/maven_central/) -> [Help 1]

@laeubi do you have a hint how to find out why these dependencies are tried to be resolved from maven central at all if they are p2 dependencies?

[cdietrich]

here is a run with debug log https://ci.eclipse.org/xtext/job/xtext-eclipse/job/milestone_2.29.0.M3/13/console

[cdietrich]

12:55:36 [DEBUG] -----------------------------------------------------------------------
12:55:36 [DEBUG] Goal: org.eclipse.tycho:tycho-p2-plugin:2.7.5:update-local-index (default-update-local-index)
12:55:36 [DEBUG] Style: Regular
12:55:36 [DEBUG] Configuration:
12:55:36
12:55:36 ${project}
12:55:36
12:55:36 [DEBUG] =======================================================================
12:55:36 [DEBUG] Resolving artifact org.eclipse.xtend:org.eclipse.xtend.lib:pom:2.29.0.M3 from [eclipse.maven.central.mirror (https://repo.eclipse.org/content/repositories/maven_central/, default, releases)]
12:55:36 [DEBUG] Using transporter WagonTransporter with priority -1.0 for https://repo.eclipse.org/content/repositories/maven_central/
12:55:36 [DEBUG] Using connector BasicRepositoryConnector with priority 0.0 for https://repo.eclipse.org/content/repositories/maven_central/
12:55:36 [INFO] Downloading from eclipse.maven.central.mirror: https://repo.eclipse.org/content/repositories/maven_central/org/eclipse/xtend/org.eclipse.xtend.lib/2.29.0.M3/org.eclipse.xtend.lib-2.29.0.M3.pom
12:55:36 [DEBUG] Writing tracking file /home/jenkins/agent/workspace/text-eclipse_milestone_2.29.0.M3/.m22222/org/eclipse/xtend/org.eclipse.xtend.lib/2.29.0.M3/org.eclipse.xtend.lib-2.29.0.M3.pom.lastUpdated
12:55:36 [WARNING] The POM for org.eclipse.xtend:org.eclipse.xtend.lib:jar:2.29.0.M3 is missing, no dependency information available
12:55:36 [DEBUG] Resolving artifact org.eclipse.xtext:org.eclipse.xtext.xbase.lib:pom:2.29.0.M3 from [eclipse.maven.central.mirror (https://repo.eclipse.org/content/repositories/maven_central/, default, releases)]

@laeubi why is tycho 2.7.5 doing this. how can i avoid it?

[cdietrich]

switching back to tycho 2.6.0 seems to help.

[cdietrich]

todo: is this a consumer pom problem?

[cdietrich]

skipping pom generation does NOT seem to help
https://github.com/eclipse/xtext-eclipse/compare/cd_xxxxx
https://ci.eclipse.org/xtext/job/xtext-eclipse/job/cd_xxxxx/

[laeubi]

It seems a bit strange that a 2.29.0-SNAPSHOT artifact tries to reference a 2.29.0.M3 one should versions not match? Also please note that Tycho 3.0 is already released, so probably it is already fixed there.

[cdietrich]

2.29.0.M3 not mentioned in the branch at all.
this is why i wonder where it is coming from
maybe it is baked into some metadata at
https://ci.eclipse.org/xtext/job/xtext-lib/job/milestone_2.29.0.M3/lastSuccessfulBuild/artifact/build/p2-repository/

[cdietrich]

looks like

[cdietrich]

switching to tycho 3.0.0 does not help

[cdietrich]

will try to create a smaller reproducer

[laeubi]

Well the problem is that you produced bad P2 metadata and now Tycho thinks your artifacts is available at a maven repository.
In such a case, Tycho injects a "real" maven dependency instead of a system scoped p2 one.

So the main question would be, why is there a claimed M3 release if it is not really released?

[cdietrich]

how do i know this is bad metadata. it is also produced by p2/tycho

[cdietrich]

the maven version numer is M3, the tycho one with qualified.
it was this way for 5+ years

[cdietrich]

and of course it is a chicken and egg problem.
we cant release M3 as it is not completely done yet.
as we are still producing it.

so tycho expect this maven thing to be in the repo list?

[laeubi]

The artifact was consumed from a repository named "local-gradle-result" and Tycho is recording this (maybe because you are using something like pom-dependencies=consider or maven targets?).

So who ever produces p2-repository seem to be doing something that let Tycho think you have released that artifact to a maven repository...

[cdietrich]

so if this metadata is there tycho evaluates it even if the p2 stuff is there anyway? and there is no possibility to skip this behaviour

[laeubi]

so if this metadata is there tycho evaluates it even if the p2 stuff is there anyway?

The metadata is the P2 data, so Tycho is using it.
And because maven needs this data as well it is injected into the maven model, then maven tries to fetch the artifact.

and there is no possibility to skip this behaviour

Not with current Tycho versions. Maybe we can think about dropping this feature completely because for me it seems superseded by the consumer pom approach trying to resolve dependencies after the fact, but this might be controversial because the license tool today uses that information to get the "real" artifact... I also had some success in "trick" maven with custom workspace readers so probably one can have a workaround here but a small eaxample would be required to check what we can do here.

As an intermediate solution one might investigate why this data is injected at all, or install the artifact in the local repo

[cdietrich]

so i basicallly have to also add the xtext-lib repo as maven repo. willl try that

[cdietrich]

also is there a possibility to skip the field in the p2 metadata in the first place?

[laeubi]

so i basicallly have to also add the xtext-lib repo as maven repo. willl try that

If it is deployed there, this would be the easiest solution I think.

also is there a possibility to skip the field in the p2 metadata in the first place?

Not yet, this part of Tycho is quite "dumb" and really basic as it just adds all meta-data it could fetch for an artifact.

[cdietrich]

this does help in the reproducer. will try in the real one too

[cdietrich]

also seems to help there

[cdietrich]

created eclipse-tycho/tycho#1662 for skip option

[LorenzoBettini]

Well the problem is that you produced bad P2 metadata and now Tycho thinks your artifacts is available at a maven repository. In such a case, Tycho injects a "real" maven dependency instead of a system scoped p2 one.

So the main question would be, why is there a claimed M3 release if it is not really released?

Probably it's unrelated, but while working on eclipse/xtext#2397 I noted that the JARs we publish in p2 repositories do not have any POM.xml in the MANIFEST/maven subdirectory (see e.g. https://download.eclipse.org/modeling/tmf/xtext/updates/milestones/S202211141328/plugins/org.eclipse.xtext.xtext.generator_2.29.0.v20221114-1037.jar). Can somehow this be also considered wrong metadata generation? I have some feelings that the problems I experienced in that issue is somehow related to this...

And I wondered if also this problem might be related to this.

[cdietrich]

i dont know this feature at all @LorenzoBettini
we just take maven artifacts built by gradle and put them into the p2 repo.

i also wonder/dont understand why the same problem is not seen with the snapshots

[LorenzoBettini]

i dont know this feature at all @LorenzoBettini we just take maven artifacts built by gradle and put them into the p2 repo.

I've always thought that's a terrible mistake to build Eclipse stuff with gradle...

i also wonder/dont understand why the same problem is not seen with the snapshots

if it puts 2.29.0-SNAPSHOT (didn't check) then I'd say everything works because it takes the latest snapshot version.

[cdietrich]

the counter question is:
how to get nice maven artifacts from p2 artifacts.
and what will die first, eclipse.ui or gradle

[cdietrich]

i also have no clue there the meta-inf/maven stuff would come from if you package pure maven artifacts with tycho.

[LorenzoBettini]

the counter question is: how to get nice maven artifacts from p2 artifacts. and what will die first, eclipse.ui or gradle

No matter how longer than eclipse.ui Gradle will live, I seem to understand that Gradle is not aiming at giving more support to Eclipse stuff. I doubt Gradle will ever beat Maven (unless for the hype of course).

In any case, we're still building bundles (not pure Maven artifacts) and publish them as Maven artifacts. With Tycho it works and it creates that directory automatically.

I don't know if Tycho takes that POM inside MANIFEST into consideration, that's why I was asking @laeubi about that.

[cdietrich]

In any case, we're still building bundles (not pure Maven artifacts) and publish them as Maven artifacts. With Tycho it works and it creates that directory automatically.

yes but how to have nice maven dependencies there, i have never seen a nice solution for that. and this is the main reason why we still use gradle

[LorenzoBettini]

If someone likes to sponsor development for a tycho-gradle plugin let me know :-D

Beside that, Tycho now contains the consumer pom generation to generate "real" maven poms but I'm a bit confused about what the issue with xtext directly (beside that meta-data confusion stuff), e.g. one can deploy/consume tycho build stuff to/from maven and the other way round as well...

@laeubi are you referring to the new tycho-packaging-plugin feature that can be opted out with <skipPomGeneration>true</skipPomGeneration>? As I said in the corresponding issue, I found it crucial to skip such a feature, otherwise, the produced POMs cannot be consumed in a few cases during a pure Maven build. Notably, if I remember correctly, they cannot be consumed when Maven resolves dependencies of a Maven plugin (because such dependencies are not JARs but eclipse-plugin?)

[cdietrich]

How well does that work with repo split

[LorenzoBettini]

How well does that work with repo split

@cdietrich are you asking me? What in particular?
Concerning Maven, m2e provides real first-class experience (IMHO) in Eclipse w.r.t. Gradle (but I might be biased and probably don't know Gradle much... like most of us, I seem to understand). M2e resolves from the workspace if the dependencies are present. Close the dependency project and M2e resolves from the cache or from Maven repositories. If that's what you were asking.

On a side note, again, IMVHO, like it or not, repo split will destroy us someday (in the very near future)... we should get rid of it ASAP ;)

[cdietrich]

Gradle replaces the dependencies with project references in eclipse even if they are in two reactors . What would maven do

[LorenzoBettini]

there's no such concept of the reactor in Eclipse: it works like any other Eclipse workspace. You have all projects in the workspace available.

As I said above:

"M2e resolves from the workspace if the dependencies are present. Close the dependency project and M2e resolves from the cache or from Maven repositories. If that's what you were asking."

[cdietrich]

So core stuff would be found from extras

[LorenzoBettini]

Yes.

Everything open in the workspace will be found by everything asking for it, just like it happens in an Eclipse workspace.

[laeubi]

I think there are some mixing of concerns here. The more you mix stuff, the more likely you will see obstacles.

1. Tycho can consume maven dependencies from different sources and then Tycho handles them as those, so just because you not explicitly add them to your pom, they are there and would have caused issues if used from "maven first" anyways. So this is the issue you are seeing here (you request to use an artifact from a repository that is not available to your build). This is an early attempt to make Tycho more "maven" like, and might vanish in Tycho 4.0 where there are better alternatives.
2. You can feed Tycho completely (or even partly) from maven dependencies, that is pomDependencies=consider option, but you are obviously responsible for manage this yourself. The drawback is that this works not very well in the IDE because PDE has no such concept of classpath derived bundles. Actually it would be possible but is a lot of work and effort (e.g. convincing others its a good idea as PDE do not has the concept of project local targets).
3. You can feed Tycho (and PDE) through maven-target-locations that is actually what I would recommend today if one want to share stuff that is build by maven (e.g. felix/bnd plugin) as it works for IDE+Commandline smoothly and do not require special deployed sites (that causes confusion here!)
4. You can mix "tycho build" artifacts and "maven build" artifacts in the same build (so called "mixed reactor build"), so there is no requirement that you use tycho for cases where you actually want to produce "pure" maven artifacts but still need tycho for example to build an RCP product or some Eclipse Plugins!
5. You can produce "proper" pom files with mapped dependencies by Tycho that the can be consumed with a "plain" maven build (there where some issues in the past but we are constantly improving there), how good this works depends on how proper you manage your dependencies, e.g. if you are using P2 sites much it most likely do not work well, because you will have missing items in the "plain maven" part, or issues you see here if you feed actual maven artifacts back into P2 sites.

There is one example that already uses such "maven first" approach for most of their artifacts and Tycho is only used for the Eclipse parts: https://github.com/faktorips/ and they even sponsored development in that areas to get better support in tycho/m2e for their use-cases.

All of this of course requires that you are using the most recent Tycho, or even tycho snapshot builds as that's an area where we constantly improve and enhance, and only using these features can reveal problems or quirks. Also it might require to restructure how one builds things today and choose what items are "plain" and what are "eclipse".

[LorenzoBettini]

@laeubi, thanks for the clarifications. I confirm that in my DSLs (thus, I'm not speaking for Xtext now) I don't mix things, and I prefer to manually specify Maven dependencies in the POM (as I said, I then also test my DSL in a pure Maven environment). I never had problems (of course, the new default behavior of the packaging plugin broke everything, but I know how to skip that, and everything went back to normal).

[cdietrich]

regarding

Tycho can consume maven dependencies from different sources and then Tycho handles them as those, so just because you not explicitly add them to your pom, they are there and would have caused issues if used from "maven first" anyways. So this is the issue you are seeing here (you request to use an artifact from a repository that is not available to your build). This is an early attempt to make Tycho more "maven" like, and might vanish in Tycho 4.0 where there are better alternatives.

i still dont understand why the p2 artifact from the repo is not consumed. https://ci.eclipse.org/xtext/job/xtext-lib/job/milestone_2.29.0.M3/lastSuccessfulBuild/artifact/build/p2-repository/plugins/org.eclipse.xtext.xbase.lib_2.29.0.v20221114-1034.jar

[LorenzoBettini]

@cdietrich @laeubi By looking again at the issue described here, I think it's related to the problems that drove me nuts in the second part of eclipse/xtext#2397 (where I had fixed the problem upstream but I was still experiencing problems when testing)

I report here my investigations and doubts because I think they're related to this very issue.

I'll try to summarize the problem:

• the problem started happening when consuming Xtext 2.29.0.M2 (the milestone before the one we're talking here), both from the target platform and from Maven central (it's NOT a SNAPSHOT version)
• there is one of our bundle, xtext.generator, that in the POM was not pinning all transitive dependencies (pinning was detected as crucial in the past because of version ranges of platform artifacts)
• due to version ranges of EMF, when running two maven plugins (in a Maven/Tycho reactor) the new version of emf.ecore was taken but the old version of emf.common was taken, resulting in a "field not found exception" (how could that happen is not completely clear to me/us, though the rest of this report might shed some light)
• one these plugins, exec-maven-plugin, was consuming xtext.generator as a project's dependency (specified in additional bundles of build.properties), so, xtext.generator should have been consumed from the p2 artifacts of the target platform
• the other plugin, our xtext-maven-plugin, consumes xtext.generator as one of its runtime dependencies, so it consumes it as a Maven artifact, but the transitive dependencies might be taken from the target platform (unless properly pinned in the xtext.generator POM)
• I fixed the emf dependencies pinning in the xtext.generator POM upstream (checked using the Dependency tree in the m2e POM editor)
• I started consuming the Maven version of xtext.generator (i.e., 2.29.0-SNAPSHOT) from our Jenkins Maven repos
• xtext-maven-plugin run was fixed! (emf.ecore and emf.common were taken consistently using the pinned versions)
• exec-maven-plugin was still failing (!)
• I realized (my bad!) I forgot to consume ALSO the p2 xtext.generator from our new Jenkins p2 repositories. [ref 1]
• I then also switched to our Jenkins p2 repositories and the problem was solved for exec-maven-plugin as well! (YEAH!)
• On a second thought, this second part made no sense to: the p2 xtext.generator JAR has no POM inside (see my note above about our JARs not containing the POM) and in the MANIFEST.MF of xtext.generator dependencies are not pinned anyway, so why would that have any relevance? Also, in the first place, exec-maven-plugin does not list any Maven dependency, so it should take dependencies resolved by Tycho from the target platform; in the target platform emf.ecore and emf.common are in sync from the start!
• By looking at the log of the failure of a build before I realized my "mistake" in [1] (that is, when I was using the fixed SNAPSHOT Maven artifact of xtext.generator, but I was still using previous p2 versions) I noted that at the beginning of the build Tycho was fetching

Fetching org.eclipse.xtext.xtext.generator_2.29.0.v20221024-0510.jar from https://download.eclipse.org/modeling/tmf/xtext/updates/milestones/S202210240854/plugins/

because I didn't change the p2 repo in the target platform (and that's OK, of course). Later in the build, before running exec-mave-plugin, someone (Maven + Tycho?) was

Downloading from central: https://repo.maven.apache.org/maven2/org/eclipse/xtext/org.eclipse.xtext.xtext.generator/2.29.0.M2/org.eclipse.xtext.xtext.generator-2.29.0.M2.jar (the version before my patch)

IN SPITE I removed 2.29.0.M2 from my POMs, because I switched to 2.29.0-SNAPSHOT.

How could that be possible?
I'm not blaming Tycho: I guess Tycho just found wrong or missing Maven metadata from the p2 version of xtext.generator and tried to resolve it as a Maven dependency using some other metadata?

[laeubi]

i still dont understand why the p2 artifact from the repo is not consumed.

As said before, the artifact IS consumed (by Tycho), but the meta-data says "this is actually a maven artifact from a maven-repository" (namely local-gradle-result) so Tycho propagates that information to the maven model and then Maven tries to fetch the real artifact what fails...

[cdietrich]

@laeubi so it is not possible to publish maven artifacts as p2 repo without also publishing the maven repo too

[laeubi]

@LorenzoBettini I think the length of your description already indicates this, but I think you have just too many different items in your setup to find a good (and consistent explanation) what you are seeing:

1. Xtext (w/o Snapshots, consumed from maven and/or P2)
2. Platform/EMF stuff with version ranges (was is simply wrong/bad designed but hopefully improve on next release)
3. exec-maven-plugin (what adds another level of complexity, e.g. what do you actually exec here?)
4. xtext-maven-plugin (what itself interacts with tycho/maven model)
5. Eclipse-Plugins and "plain" maven jars? bundles?
6. ...

So I can only tell that in general it should work if everything is setup properly, but obviously such setup is not part of many builds and defiantly not part of the integration test suite.

so it is not possible to publish maven artifacts as p2 repo without also publishing the maven repo too

It is possible, platform does it and others do it as well. But if you consume from a private/temporary repository and then publish to P2 and then want to consume again in maven without access to this private/temp repo, you simply break the thing, as you would break it in a traditional maven setup.

[cdietrich]

see also eclipse/xtext#2122
we publish purexbase to p2 but not to maven central

[cdietrich]

as we no longer build with gradle this is no longer an issue