FileNotFoundException: .m2/repository/.meta/p2-artifacts.properties #1650
phermsdorf
started this conversation in
General
Replies: 6 comments 7 replies
Please note that m2 local repository is not safe to share between different processes! beside this, you can try to run the build with |
0 replies
i wasn't aware of this.
i'll add that to our build and get back with the error message when it happens again Thank you |
0 replies
|
@laeubi does that help? |
2 replies
|
I'll try to take a look if there is something that might needs to be more aware of concurrency. |
|
after switching to tycho 4 and running multiple(2 are enough most of the time) docker based build jobs together a lot of builds fail. followed by running the same build alone does work. The path Would be great to have a solution for that problem. Thanks, Bye Peter |
Actually there is none. As mentioned it is generally not safe to share a maven repository if they share the same artifacts and this is what you are seeing here.
|
0 replies
|
Basically i get your point, but i'm wondering that even in the official docker image describes mounting the local .m2 folder as a method for "The local Maven repository can be reused across containers" here under "Reusing the Maven local repository". And "Packaging a local repository with the image" was currently not too successful, probably because "dependency:resolve" does not resolve target platform (and maybe other) artifacts needed for the build in a tycho context - and of course add's another layer of complexity for the image creation and managing. I'm on the other side wondering why the build(s) do write/modify/change the maven artifacts below the .m2/repository folder when building/running tests. For my understanding they should just use/read them after they have been downloaded for the first time and then maybe "do their things" below the their module's target folders .... Thank you for your comments! |
2 replies
It can be reused for sure, but I don't think it can reliable be shared across parallel invocations.
I can only assume that for whatever reason the artifact is modified because without a reproducable example its hard to analyze, but this maybe also depends on the used maven version and Tycho version, on the used filesystem (e.g. if it support reliable locking) and maybe even of the docker version used (no clue how reliable file locks work across containers) |
|
I'm now trying to bundle the .m2 folder into the docker image. Is there something like
for tycho which resolves/downloads all required artifacts for the target-platform-configuration without building everything? |
|
Sorry for bringing up an old topic, this subject is becoming a larger issue, we are finding that AV can have an impact on holding onto the .properties file, the reality is that even when we limit the use of the repo to a single thread/process it is highly likely that a AV/Business Protection services will have a short read lock at some point on the file as it changes a lot and would be an obvious attack target. The issue for me I see is that within FileBasedTychoRepositoryIndex there is no check to determine the success of the file deletion. if (indexFile.isFile()) { |
3 replies
|
Safer would be to check the return value of |
|
Yeah that I think could be a fix, possibly the delete action instead could be |
|
Yes, that would work too. This pattern is used elsewhere for similar reasons... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi,
since upgrading to tycho 3 we occassionally see the following error in our builds:
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:3.0.0:validate-classpath (default-validate-classpath) on project com.godyo.p4.workflow: Execution default-validate-classpath of goal org.eclipse.tycho:tycho-compiler-plugin:3.0.0:validate-classpath failed: java.io.FileNotFoundException: /p4/.m2/repository/.meta/p2-artifacts.properties (No such file or directory) -> [Help 1]The builds run in docker containers with the .m2 folder of the builds server mounted to /p4/.m2/ in the containers.
It seems to me this happens when there are many parallel builds running - but not every time or reproducible.
Has anyone seen this kind of error too or has an idea what could cause this kind of error message?
Thanks.
Bye Peter
All reactions