[GIB-TEST] Handle default package name when generating class names Fixes #13540 #13543
Conversation
|
Thanks for your pull request! The title of your pull request does not follow our editorial rules. Could you have a look?
|
ghost
added
area/arc
|
First off thanks for taking on this task! I had a look at JVM Tests - JDK 11 and the problem here is this: That constructor hasn't been touched for a year. And even more strangely: The module containing this class ( I found one place where this jar is overwritten: While that's definitely something to fix (because Maven invoker tests should not operate on the "real" local Maven repo, IMHO), it does not explain the problem since it is merely re-installing the same jar that has been build before. This is already the second strange "inconsistent jarfile" (so to say) in an integration test, the other one being a CCE in a |
|
@maxandersen until we have a clue what's the problem we could switch GIB to |
|
@famod if you open prs against gib-test I'll happily merge them. Just mention me. This way I'm not making mistakes :) |
|
Ok, might come up with PR then. But first I'm trying to reproduce it in my fork. |
|
So this seems to fix the problem: @aloubyansky do you have a clue? |
maxandersen
force-pushed
the
gib-test
branch
from
3a7f715 to
7d4bbc4
Compare
maxandersen
force-pushed
the
defaultpackage-gib
branch
from
db09061 to
01b9c1f
Compare
|
i've rebased gib-test and then this pr on new gibtest. |
|
What the... So same test, different error. I didn't get this error in my fork. 😞 |
So it finds/activates no features. How can this be? |
|
All these stacktraces indicate that the classpath isn't complete for some reason. |
I guess it can't locate the JAR that was built from the current workspace and pulls in an older version somehow. |
This one is probably "helping locate" the JAR built from the current workspace. Not sure how/why yet. |
|
@aloubyansky Thanks for chiming in!
But where can such an old outdated version even come from? I mean sure, there is a SNAPSHOT deployment but even if the job would pull such artifacts, they should not be that old.
Workspace resolution only works for the modules that are part of the reactor. So when I force |
I don't have the answer, unfortunately. It might not be related at all but there is for example a test in the Maven IT module that is pulling it 1.3.3.Final quarkus-bom (not the core though). Perhaps we should check whether it has anything to do with it. Although, I don't see how.
If you remove that quarkus-core from force build modules, how reproducible would that be? I mean the resolution of the old version. |
I stand corrected! I made a mistake while trying to mimic this PR in my fork.
Should be reproducible, now that I've found my mistake (see above). Will try this next.
Since Maven ITs run in a separate job, I don't think this is related. Maybe I really should have a look at those container-image invoker tests that seem to mutate the local repo. |
|
After rebasing and including #13218 (to close some gaps, just in case) and without any It looks as if classes are being loaded by the wrong classloader(s) (or maybe twice or whatever).
Exclusion of those and the |
|
Is it still failing at different points on every run or is this a consistent outcome? |
|
@aloubyansky I haven't yet tried to reproduce the "new" PS, to clear things up a litte (or to make things more complex 😨):
These scenarios came up while testing in my fork. I thought it is better to remove |
Oh well, if only |
Hot candidate: /cc @aloubyansky |
|
It is @aloubyansky @stuartwdouglas any ideas? |
|
FTR: If @aloubyansky and I still need to figure out what is happening exactly during |
|
The |
|
I don't think we need another iteration here, closing. Thanks for your support @maxandersen! |
** DO NOT MERGE **
this is a mirror of real PR going to master - but this one is just testing against GIB as
discussed in #13243