Skip to content
This repository has been archived by the owner on Apr 6, 2023. It is now read-only.

Use Tycho 3 #15

Open
LorenzoBettini opened this issue Mar 20, 2023 · 31 comments
Open

Use Tycho 3 #15

LorenzoBettini opened this issue Mar 20, 2023 · 31 comments

Comments

@LorenzoBettini
Copy link
Contributor

@cdietrich In eclipse/xtext#2135 (comment) you were mentioning that the toolchain is complex with Tycho 3, could you please give more details?

I've opened this issue not to fill the other issue too much.

@cdietrich
Copy link
Member

@LorenzoBettini we need to create toolchains xml locally and on ci. we also need to do something to run the same build with java 11 and java 17
right now we just set java home and are done.

@LorenzoBettini
Copy link
Contributor Author

@cdietrich why are we still building with Java 11? (just to understand).
Couldn't we simply switch to Tycho 3.0.4 in the POM and when building with Java 11 we pass the old Tycho version on the command line?
If I'm not wrong, that's already done in the current setup for old target platforms? I mean, currently, we default to 2.7.5, but for some older platform we pass -Dtycho.version=2.7.4, do I remember correctly?

@cdietrich
Copy link
Member

cdietrich commented Mar 20, 2023

we use r202203 as minimal target and this one still supports java 11 and so to make sure we dont use any java 17 api we stick to that.

and yes we can pass the tycho version as long as the poms are equivaltent
i assume we are not cause tycho 2.7.x does not support the ci friendly versions

the problem is: i have no toolchain experience so i cannot tell how easy it can be set up and switched so that the same build runs with multiple java versions

@LorenzoBettini
Copy link
Contributor Author

@cdietrich for avoiding using Java 17 API it is a matter of using the release flag set to 11 of the Java compiler

Indeed, I did not mean to set up the toolchain to use different Java versions; I meant use Java 17 and Tycho 3.0.4 by default and use Java 11 passing the Tycho version on the command line for the minimal target platform.
Note that, with this solution, one would realize using Java 17 API even without the release flag: when building with Java 11 the compilation would fail.

@cdietrich
Copy link
Member

I meant use Java 17 and Tycho 3.0.4 by default and use Java 11 passing the Tycho version on the command line for the minimal target platform.

but can we then use the ci friendly version feature?

@LorenzoBettini
Copy link
Contributor Author

If I understand the CI friendly version feature you mentioned (https://tycho.eclipseprojects.io/doc/master/TychoCiFriendly.html), I think that would not still help us for the timestamp in the OSGI bundles and different POM versions without qualifiers.

If I understand the CI friendly mechanism correctly, that only allow you to specify versions for released POMs and OSGI from the command line without modifying POMs and MANIFESTs. That's cool, but I guess it still relies on the versions always to be exactly the same in OSGIs and POMs, which is not what we want.

From what I read in that URL, mvn -Dtycho.buildqualifier.format=yyyyMMddHHmm clean deploy will allow you, without modifying the POMs and MANIFEST, to have everywhere 1.0.0-<formatted qualifier>. Instead, for example, for releases, we want 1.0.0 in POMs and 1.0.0-<formatted qualifier> in MANIFESTs.

Maybe we should ask people from Tycho?

I'd like to switch to Tycho 3.x because I am more worried about delaying the switch to Tycho 3 too much ;)

@cdietrich
Copy link
Member

hmm the i completely missunderstood the ci friendly versions feature. i understood it allows the qualifier vs milestone feature ootb

@cdietrich
Copy link
Member

did some experiments. so it allows to do a

mvn clean install -Dqualifier=.M1
mvn clean install -Dqualifier=""

but it seems to produce
Bundle-Version: 1.0.0.M1.202303201358

and even complains about that

org.osgi.framework.BundleException: Invalid manifest header Bundle-Version: "1.0.0.M1.202303201403" : invalid version "1.0.0.M1.202303201403": invalid qualifier "M1.202303201403"
at org.eclipse.osgi.internal.resolver.StateBuilder.createBundleDescription (StateBuilder.java:124)

@cdietrich
Copy link
Member

i will start a tycho discussion

@cdietrich
Copy link
Member

created eclipse-tycho/tycho#2261

@LorenzoBettini
Copy link
Contributor Author

hmm the i completely missunderstood the ci friendly versions feature. i understood it allows the qualifier vs milestone feature ootb

From what I understand CI friendly means that you can change the version and the qualifier without changing the sources, just passing a property at the command line. As I suspected, it cannot work in our case because we want a bundle version different from the POM version during releases and milestones.

@LorenzoBettini
Copy link
Contributor Author

@cdietrich Concerning my comment #15 (comment) does it sound good? It should address our use cases if I understand them correctly.

@cdietrich
Copy link
Member

cdietrich commented Mar 20, 2023

i assume yes. but i still dont understand how we switch between

  • build with java 17 against java 11 release
  • build with java 17 against java 17 release

but this is cause i am a complete noob

so your assumption is the poms will work with both tycho 3 and 2
and we will use java home 11 with tycho 2

maybe i am extra confused cause the default is java 11 and tycho 2
for both 11 and 17
and we built against latest und tycho 3 and 4 not by default
but in special nightly builds only

@LorenzoBettini
Copy link
Contributor Author

@cdietrich I was proposing something even simpler:

build with Java 11 against a Java 11 release with Tycho 2.x (because Tycho 3 requires Java 17).

By default, with Java 17 with Tycho 3.x.

@cdietrich
Copy link
Member

cdietrich commented Mar 20, 2023

so we would switch the default from current state. am not sure how pr validating friendly this is (default build wont detect too new api used)

@LorenzoBettini
Copy link
Contributor Author

@cdietrich yes, the default would be the latest versions.

Yes, API violations would be detected only when building with Java 11.

However, using the release option in JDT settings would detect API violations right in Eclipse. Note that --release has been introduced in Java 9, so unless we want to build with Java 8 as well, that wouldn't be a problem.

@cdietrich
Copy link
Member

ok

@cdietrich
Copy link
Member

with tycho 4 we might also profit from this one
eclipse-tycho/tycho@b187122

@LorenzoBettini
Copy link
Contributor Author

with tycho 4 we might also profit from this one eclipse-tycho/tycho@b187122

mh... but that would not solve our problem to have 2.31.0.M1 in POMs and 2.31.0.v2023... in OSGI, would it?

@cdietrich
Copy link
Member

@LorenzoBettini i understood it would support 2.31.0-M1 and 2.31.0.v2023
this is at least what i see in the test

@cdietrich
Copy link
Member

cdietrich commented Mar 21, 2023

seems to work with .M1 and also -M1
the only thing what i see that we dont the the v
but
Bundle-Version: 1.0.0.202303211901

@laeubi
any idea where there normal v aka 1.0.0.v202303211901 is coming from respectively not coming from?

@LorenzoBettini you can find my experiments at
https://github.com/cdietrich/tycho-ci-friendly-bq
calling it with
mvn clean install -DreleaseVersion=1.0.0 -Dqualifier=".M1"
had to build tycho 4.0.0-SNAPSHOT locally to get it running

@LorenzoBettini
Copy link
Contributor Author

@cdietrich with your experiment what's the result?

The 'v' is something that we usually specify in the format of tycho-packaging-plugin; in your POM there's no such a configuration so you end up with the default timestamp format

@cdietrich
Copy link
Member

The result is that at first glance it seems to work

@LorenzoBettini
Copy link
Contributor Author

Great! So for the 'v' you just have to specify the format correctly in the configuration of tycho-packaging-plugin

<configuration>
	<format>'v'yyyyMMdd-HHmm</format>

@cdietrich
Copy link
Member

thx for the hint @LorenzoBettini
seems to work. now i am getting Bundle-Version: 1.0.0.v20230322-0735

@LorenzoBettini
Copy link
Contributor Author

@cdietrich Is Maven 3.8.7 required? I can't get it working

mvn -Dmaven.repo.local=~/tmp/maven-repo clean verify -DreleaseVersion=1.0.0 -Dqualifier=".M1" -Dtycho-version=4.0.0-SNAPSHOT
Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
[WARNING] The POM for org.eclipse.tycho:tycho-build:jar:4.0.0-SNAPSHOT is missing, no dependency information available
[ERROR] Error executing Maven.
[ERROR] Extension org.eclipse.tycho:tycho-build:${tycho-version} or one of its dependencies could not be resolved: Could not find artifact org.eclipse.tycho:tycho-build:jar:4.0.0-SNAPSHOT
[ERROR] Caused by: Could not find artifact org.eclipse.tycho:tycho-build:jar:4.0.0-SNAPSHOT
[ERROR] Caused by: Could not find artifact org.eclipse.tycho:tycho-build:jar:4.0.0-SNAPSHOT

@cdietrich
Copy link
Member

@LorenzoBettini release notes from tycho say Maven 3.8.5

@cdietrich
Copy link
Member

@LorenzoBettini i had to build and install it locally
maybe @laeubi has an idea how to make the tycho snapshot repo available in the .mvn/extensions.xml file without building locally

@cdietrich
Copy link
Member

@LorenzoBettini using custom settings xml seems to work. pushed that

@laeubi
Copy link

laeubi commented Mar 23, 2023

It seems you sorted that out already, yes a settings.xml is currently the only way to do it because this is loaded before the project is even parsed see:
https://github.com/eclipse-tycho/tycho/wiki#configure-snapshots-repository-globally

@cdietrich
Copy link
Member

thx for downporting to 3.0.5 @laeubi

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants