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
Re-enable tests in CI (Eclipse Jenkins) #1166
Conversation
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: André Silva <andre15andre@hotmail.com>
Signed-off-by: Javier Ron <javierron90@gmail.com>
Just to keep you up to date then, the current problems are:
|
Cool! thanks for the info! I am focusing on point 3 for now. I believe the problem might be here: Line 14 in fc73f4a
My guess is that the |
Could be. When running on the local docker container the only problem is with the Nopol test not finding the spoon-core jar, so should be related to the environment in Jenkins. |
f189028
to
7b9bc08
Compare
9a180a5
to
f001b0d
Compare
Solved 2 & 3 (log). I will attempt point 1 tomorrow and hopefully the modification on the Jenkinsfile will fix some of the problems of the pipeline. @andre15silva |
c85daf2
to
91977a1
Compare
Add explicit dependecies on maven-reapiar pom to avoid conflicts and missing jars on tests Signed-off-by: Javier Ron <javierron90@gmail.com>
This PR is passing the tests now. |
container('maven') { | ||
sh 'bash ./.ci/ci-maven-repair.sh' | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there really a need to use a separate script for maven-repair
? It would be nice to merge this with run-with-core
. The only difference is the NPEFix
version option.
If we change this we can eliminate xmlstarlet
from the Docker image too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure of what does that version property does, have you tried to run the tests without it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, and they work. I also don't know why that is needed. I haven't found any usage of a property NPEFIX_VERSION
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cokefh @monperrus WDYT?
<dependency> | ||
<groupId>fr.inria.gforge.spoon</groupId> | ||
<artifactId>spoon-core</artifactId> | ||
<version>7.0.0</version> | ||
</dependency> | ||
<dependency> | ||
<groupId>commons-cli</groupId> | ||
<artifactId>commons-cli</artifactId> | ||
<version>1.3</version> | ||
</dependency> | ||
<dependency> | ||
<groupId>org.json</groupId> | ||
<artifactId>json</artifactId> | ||
<version>20160810</version> | ||
</dependency> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is the best approach, albeit it works. Shouldn't the dependencies be fetched transitively?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is the best approach
I agree with you. At least in the case of spoon-core
I could see that the dependency metadata (pom and sha files) is downloaded, but unless I put these here explicitly it does not download the jar. I assumed the same for commons-cli
and json
.
Also, I checked and the maven-repair tests work locally in my pc only because those jars were already there as a result of compiling another module.
If there is a better way to trigger the jar download, we can replace this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's very weird behavior indeed. While debugging I also saw that pom and sha files were downloaded, just not the jar file.
I think it's important to get this right tho, because having sub-dependencies hardcoded makes it hard to maintain.
I will look further into it after my exam tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mvn dependency:tree
for maven-repair
is in https://gist.github.com/andre15silva/254c0de8ef2d2a7ac45c834f404119c4
The issue is that these three dependencies are being omitted because of conflicts with sub-dependencies from other repair tools that use these libraries but with a different version.
[INFO] +- (fr.inria.gforge.spoon:spoon-core:jar:7.0.0:compile - omitted for conflict with 6.0.0)
[INFO] +- (commons-cli:commons-cli:jar:1.3:compile - omitted for conflict with 1.2)
[INFO] \- (org.json:json:jar:20160810:compile - omitted for conflict with 20160212)
If we added the Nopol
dependency first, it would fetch these versions. It's also not a very elegant solution tho. Yours is probably better, as it is explicitly written.
Another option would be to change getClassPathFromPom
to take into account that the version explicited in the repair tools pom files may not be available locally and that another version has to be used. I'm not sure this is a very good idea tho.
@javierron WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we added the Nopol dependency first, it would fetch these versions. It's also not a very elegant solution tho. Yours is probably better, as it is explicitly written.
I believe I tried this, and it did not resolve the conflicts.
Another option would be to change getClassPathFromPom to take into account that the version explicited in the repair tools pom files may not be available locally and that another version has to be used.
I don't think this is a good idea either, we may create an even more complicated compatibility/dependency issue.
The only changes were the timeouts, but you have already included that here. I added some comments, tell me what you think. Other than that, we can skip the rebase and merge this yes. |
Thanks a lot for the heavy work. LGTM to merge and proceed. We can fine-tune later. OK for you? |
OK for me |
OK for me too |
Thanks a lot for the foundational PR |
I'm hijacking @andre15silva's PR #1164 to attempt some fixes myself. Any progress will be rebased to his PR.