Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build with Tycho 4.0.8 #301

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

HannesWell
Copy link
Member

Let's see what happens.

@cdietrich
Copy link
Member

we also use older in Jenkinsfile. am not sure if this is a Java 11 thing and no toolchains

@HannesWell
Copy link
Member Author

Probably that's a problem yes.
Do you mind to run the build with Java-17 and toolchains enabled?

@cdietrich
Copy link
Member

yes, but

  • i have no idea how to set this up
  • we need also a guide how to setup locally

@HannesWell
Copy link
Member Author

I can set it up. For local use one needs a ~/.m2/toolchains.xml file, so I guess the usage should only be activated via a corresponding profile.

On the other hand, do you already have a plan when to require Java-17 in MWE?

With #302 this passes locally using a Java-17 JDK.

@cdietrich
Copy link
Member

it depends when we find the time to do the java 21 move part 2 in Xtext

@HannesWell
Copy link
Member Author

Understand.
I have now setup the maven-toolchains-plugin along with a few other minor enhancements of the root/parent pom.

I also removed the tychoVersion parameter of the buildProject() method, assuming that in the future all kind of builds use the same version of tycho and removing it removes some places where a version can be forgotten.
If one wants to try-out for example another tycho snapshot version the version in the pom can still be overwritten in that branch or one can again add e.g. -Dtycho-version=5.0.0-SNAPSHOT \.

@HannesWell
Copy link
Member Author

And regarding the documentaiton, one only needs the usual local ~/.m2/toolchains.xml file and can then run the build with the additional argument -Pstrict-jdk. Do you think that's necessary to document explicitly? If yes, where should that be?

@cdietrich
Copy link
Member

How does your toolchain look like
I have 5 machines with different os so something to copy paste adapt will help

@cdietrich
Copy link
Member

Can you double check with the tycho 5 branch

@HannesWell
Copy link
Member Author

HannesWell commented Aug 11, 2024

How does your toolchain look like I have 5 machines with different os so something to copy paste adapt will help

Sure, the following is my ~/.m2/toolchains.xml, stripped for similar entries and with the actual paths replaced by a variable $$local-path-to-JDK-<version>$$

<?xml version="1.0" encoding="UTF-8"?>
<toolchains xmlns="http://maven.apache.org/TOOLCHAINS/1.1.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/TOOLCHAINS/1.1.0 http://maven.apache.org/xsd/toolchains-1.1.0.xsd">
	<toolchain>
		<type>jdk</type>
		<provides>
			<id>JavaSE-1.8</id>
			<version>1.8</version>
		</provides>
		<configuration>
			<jdkHome>$$local-path-to-JDK-1.8$$</jdkHome>
		</configuration>
	</toolchain>
	<toolchain>
		<type>jdk</type>
		<provides>
			<id>JavaSE-17</id>
			<version>17</version>
		</provides>
		<configuration>
			<jdkHome>$$local-path-to-JDK-17$$</jdkHome>
		</configuration>
	</toolchain>
</toolchains>

@HannesWell
Copy link
Member Author

Btw. the changes in the Jenkinsfile are not picked up from a PR since I don't have write access in this repo.
So to fully test it you would have to push it to a branch in the repo or push it into a branch of your fork.

@cdietrich
Copy link
Member

Meh can do later when home

@HannesWell
Copy link
Member Author

Can you double check with the tycho 5 branch

Will have a look.

Btw. at least locally it looked like this resolves #277.

@HannesWell
Copy link
Member Author

Btw. the changes in the Jenkinsfile are not picked up from a PR since I don't have write access in this repo. So to fully test it you would have to push it to a branch in the repo or push it into a branch of your fork.

Alternatively you can also Replay the build of this PR in the Jenkins UI and apply the Jenkins in the Jenkins file there.

@cdietrich
Copy link
Member

@HannesWell
Copy link
Member Author

https://ci.eclipse.org/mwe/job/mwe2/job/HannesWell-update-tycho-4.0.8/

I have no clue why it fails this way (at least the toolchain is picked up)...

[INFO] --- surefire:2.19.1:test (test) @ org.eclipse.emf.mwe.tests ---
 [WARNING] Parameter 'localRepository' is deprecated core expression; Avoid use of ArtifactRepository type. If you need access to local repository, switch to '${repositorySystemSession}' expression and get LRM from it instead.
 [INFO] Toolchain in maven-surefire-plugin: JDK[/opt/tools/java/openjdk/jdk-11/latest]
 [INFO] Surefire report directory: /home/jenkins/agent/workspace/e2_HannesWell-update-tycho-4.0.8/git-repo/tests/org.eclipse.emf.mwe.tests/target/surefire-reports
 
 -------------------------------------------------------
  T E S T S
 -------------------------------------------------------
 Picked up JAVA_TOOL_OPTIONS: -Dmaven.ext.class.path="/home/jenkins/agent/workspace/e2_HannesWell-update-tycho-4.0.8@tmp/withMavena974a009/pipeline-maven-spy.jar" -Dorg.jenkinsci.plugins.pipeline.maven.reportsFolder="/home/jenkins/agent/workspace/e2_HannesWell-update-tycho-4.0.8@tmp/withMavena974a009" 
 Running org.eclipse.emf.mwe.tests.util.Bug484372Test
 Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.439 sec <<< FAILURE! - in org.eclipse.emf.mwe.tests.util.Bug484372Test
 testWarningMessage(org.eclipse.emf.mwe.tests.util.Bug484372Test)  Time elapsed: 0.007 sec  <<< ERROR!
 java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/plugin/EcorePlugin
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.clearPlatformResourceMap(Bug484372Test.java:118)
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.setUp(Bug484372Test.java:50)
 Caused by: java.lang.ClassNotFoundException: org.eclipse.emf.ecore.plugin.EcorePlugin
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.clearPlatformResourceMap(Bug484372Test.java:118)
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.setUp(Bug484372Test.java:50)
 
 testRegisterFile(org.eclipse.emf.mwe.tests.util.Bug484372Test)  Time elapsed: 0 sec  <<< ERROR!
 java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/plugin/EcorePlugin
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.clearPlatformResourceMap(Bug484372Test.java:118)
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.setUp(Bug484372Test.java:50)
 
 testNoWarningMessageTargetClasses(org.eclipse.emf.mwe.tests.util.Bug484372Test)  Time elapsed: 0 sec  <<< ERROR!
 java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/plugin/EcorePlugin
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.clearPlatformResourceMap(Bug484372Test.java:118)
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.setUp(Bug484372Test.java:50)
 
 testIntroducedJarNameRegex(org.eclipse.emf.mwe.tests.util.Bug484372Test)  Time elapsed: 0 sec  <<< ERROR!
 java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/plugin/EcorePlugin
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.clearPlatformResourceMap(Bug484372Test.java:118)
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.setUp(Bug484372Test.java:50)
 
 testNoWarningMessageBin(org.eclipse.emf.mwe.tests.util.Bug484372Test)  Time elapsed: 0.001 sec  <<< ERROR!
 java.lang.NoClassDefFoundError: org/eclipse/emf/ecore/plugin/EcorePlugin
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.clearPlatformResourceMap(Bug484372Test.java:118)
 	at org.eclipse.emf.mwe.tests.util.Bug484372Test.setUp(Bug484372Test.java:50)
 
 
 Results :
 
 Tests in error: 
   Bug484372Test.setUp:50->clearPlatformResourceMap:118 NoClassDefFound org/eclip...
   Bug484372Test.setUp:50->clearPlatformResourceMap:118 NoClassDefFound org/eclip...
   Bug484372Test.setUp:50->clearPlatformResourceMap:118 NoClassDefFound org/eclip...
   Bug484372Test.setUp:50->clearPlatformResourceMap:118 NoClassDefFound org/eclip...
   Bug484372Test.setUp:50->clearPlatformResourceMap:118 NoClassDefFound org/eclip...
 
 Tests run: 5, Failures: 0, Errors: 5, Skipped: 0

@HannesWell
Copy link
Member Author

But what I find very strange is that each Maven module seems to be executed twice. Once for the clean lifecycle and once for the regular one?

@cdietrich
Copy link
Member

The mwe build is 100 years old and nobody understands it

part of the problem might be the aggregate javadoc which makes problems without tycho resolver classic (see open issues )

@HannesWell
Copy link
Member Author

The mwe build is 100 years old and nobody understands it

part of the problem might be the aggregate javadoc which makes problems without tycho resolver classic (see open issues )

I guess its more because the test and deploy goal are executed and even if that isn't the cause, it is not necessary:

@cdietrich
Copy link
Member

@HannesWell can you rebase this one. then i can update the other branch

The release option is simpler to use (just one option) and more
powerful, it also checks if the Java standard API referenced is
available in the specified release.
@HannesWell
Copy link
Member Author

@HannesWell can you rebase this one. then i can update the other branch

Done. Unfortunately the strange double execution still exists. So I guess I have to dig deeper into #277, but I cannot tell if I have time for that today. :/

@cdietrich
Copy link
Member

i guess we can take the time we need

@HannesWell
Copy link
Member Author

Locally I cannot even build the current master with javadoc generation enabled.

But a general question: Is the javadoc generation even necessary/used? Or can we at least use javadocs per project?
As far as I understand the build the javadoc are only published to
https://repo1.maven.org/maven2/org/eclipse/emf/org.eclipse.emf.mwe2.parent/
Is this referenced anywhere, e.g. a public website? If not I suggest we switch to javadoc per project if that works better or just drop javadoc generation at all? Source bundles are usually sufficient for development (in my opinion).

@cdietrich
Copy link
Member

I don’t know if anybody uses it or if it is uploaded somewhere
@szarnekow do you?

@HannesWell
Copy link
Member Author

I don’t know if anybody uses it or if it is uploaded somewhere @szarnekow do you?

Any updates on this one?
If there are no known users should we then remove the javadoc generation entirly or just switch to javadoc per maven-module?

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

Successfully merging this pull request may close these issues.

2 participants