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

Unit test for no resources in the target folder #1478

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

BoykoAlex
Copy link

In support of issue #1302

Copy link
Member

@laeubi laeubi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the testcase I'll hopefully find some time the next days to further analyses this failure, in the meantime I think the test can even be shrinked a bit see above comments.

@BoykoAlex
Copy link
Author

Thanks @laeubi! I have pushed adjustments you've proposed.

@github-actions
Copy link

github-actions bot commented Jul 18, 2023

Test Results

  216 files  +109    216 suites  +109   16m 17s ⏱️ + 6m 6s
  666 tests +  1    654 ✅  -   1  10 💤 ± 0  1 ❌ +1  1 🔥 +1 
1 332 runs  +667  1 307 ✅ +653  22 💤 +11  2 ❌ +2  1 🔥 +1 

For more details on these failures and errors, see this check.

Results for commit ab134c1. ± Comparison against base commit 8789e4c.

♻️ This comment has been updated with latest results.

pomXml.setContents(new ByteArrayInputStream("Nothing".getBytes()), true, false, null);

waitForJobsToComplete(monitor);
Thread.sleep(5000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HannesWell can you please advice here? It seems waitForJobsToComplete is not enough here or @BoykoAlex maybe can explain why additional wait is required here...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically waitForJobsToComplete wasn't enough. Removing Thread.sleep(...) calls makes it fail at line 76 AFAIR. There are ways to execute stuff async bypassing the Eclipse job queue, i.e. Display.asyncExec(...) or less likely CompletableFuture... I admit I didn't experiment any further with "waiting".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BoykoAlex can you probably replace this then with a loop that check if the file is deleted and if not waits a little time up to 5 seconds?

@martinlippert
Copy link

Any news on this? Anything we can do to provide additional help?

@laeubi
Copy link
Member

laeubi commented Aug 1, 2023

Any news on this? Anything we can do to provide additional help?

I have a rough idea how to solve this but not yet finished/implemented that,

@martinlippert
Copy link

Any news on this? Anything we can do to provide additional help?

I have a rough idea how to solve this but not yet finished/implemented that,

Sounds great. Let us know if we can provide any additional help here.

@martinlippert
Copy link

And many many many thanks for looking into this, very much appreciated !!!!!!!

@laeubi
Copy link
Member

laeubi commented Aug 1, 2023

Anything we can do to provide additional help?

One possibility is of course to help with the upstream issue:

this would already help for the case of copy resources.

@laeubi
Copy link
Member

laeubi commented Aug 2, 2023

@BoykoAlex this looks good now, can you shash / rebase the testcase?

@BoykoAlex
Copy link
Author

I have squashed and rebased the commits

@laeubi
Copy link
Member

laeubi commented Aug 3, 2023

I have squashed and rebased the commits

Thanks, sadly even with my recent changes it still fails :-\

Copy link
Member

@laeubi laeubi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to have some message added to the asserts so we don't need to check linenumbers in case of failure to see whats going on.

@BoykoAlex
Copy link
Author

Added the failure messages in asserts. Squashed the commits into a single commit again.

@mickaelistria
Copy link
Contributor

@laeubi any idea why CI is requesting a version bump for an untouched bundle?

@laeubi
Copy link
Member

laeubi commented Oct 30, 2023

This sometimes happens because of changed ECJ version.

@mickaelistria
Copy link
Contributor

Indeed: https://ci.eclipse.org/m2e/job/m2e/job/master/ ; looks like build has been broken for 4 weeks already.

@fbricon
Copy link
Contributor

fbricon commented Oct 30, 2023

It's because the license content changed

[INFO] Artifact comparison detailed log directory /Users/fbricon/Dev/projects/m2e-core/org.eclipse.m2e.logback/target/artifactcomparison
[WARNING] MavenProject: org.eclipse.m2e:org.eclipse.m2e.logback:2.2.0-SNAPSHOT @ /Users/fbricon/Dev/projects/m2e-core/org.eclipse.m2e.logback/.tycho-consumer-pom.xml: baseline and build artifacts have same version but different contents
   no-classifier: different
      META-INF/MANIFEST.MF: different
         Bundle-License: baseline='Eclipse Public License - v 2.0;link="https://www.eclipse.org/legal/epl-v20.html"' != reactor='EPL-2.0;link="https://www.eclipse.org/legal/epl-v20.html"'

[INFO] MavenProject: org.eclipse.m2e:org.eclipse.m2e.logback:2.2.0-SNAPSHOT @ /Users/fbricon/Dev/projects/m2e-core/org.eclipse.m2e.logback/.tycho-consumer-pom.xml
    The main artifact has been replaced with the baseline version.

adding <ignore>Bundle-License</ignore> to the baseline-check fixes it

@mickaelistria
Copy link
Contributor

Ignoring MANIFEST fields in the comparison is IMO a last resort solution.
If the new Bundle-Header is more standard, we can also adopt it and just bump the version. Or we can probably change the license in the pom.xml so it says the same as before.


pomXml.setContents(new ByteArrayInputStream(content.getBytes()), true, false, null);
waitForJobsToComplete(monitor);
Thread.sleep(5000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here replace with a loop that checks regualry with an upper bound instead of a fixed delay.

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.

None yet

5 participants