"build.properties does not exist" warning on no-PDE projects #1185
Comments
|
It's strange and annoying because it seems like an intermittent problem. Have you been able to reproduce it in a debug launch? I failed in that effort last I tried. |
I was not able to reproduce it in debug or manual set up projects. Best thing i can offer is to double check and may be log an IllegalStateexception to get a stacktrace how it happens. it is only supposed to run when there is a in the (see |
Is there a link / reproducer? I'm not sure I really understand when it happens, e.g if the builder is configured for the project or has this projects no builder and no nature at all? |
…ipse-pde#1185 but log a IllegalStateException() to find out how that happens. eclipse-pde#1185
…ipse-pde#1185 but log a IllegalStateException() to find out how that happens. eclipse-pde#1185
but log a IllegalStateException() to find out how that happens. #1185
|
Just want to confirm that I experienced the same in our company's workspace. Sadly, I have no reproducer. I got it on the |
|
Yes, I keep getting this problem too, on many projects, but it kind of comes and goes. Yesterday my Oomph environment has that, but a clean build make it go away. |
|
I seem to have the same problem. After I installed a new default Java runtime I suddenly got 
in all my projects. I'm using the J2EE bundle and I'm not doing Eclipse plug-in development. Before seeing this issue I uninstalled maven and PDE (I don't need those), but this did not change anything. Eclipse version: 2024-03. |
|
If you uninstalled, likely nothing will ever remove the errors. Deleting them will be necessary once. |
|
It happens to me all the time in Eclipse 2024-06 M1 Comitters version, in projects that doesn't require a BTW: I have noticed that the call Our code now: /**
* Checks if a Project is of Java Nature.
*
* @param project The project to check.
*
* @return {@code true} if the nature {@link JavaCore#NATURE_ID} is present, {@code false} otherwise.
*
* @throws CoreException If project nature could'nt be retrieved, or if it is not accessible (closed perhaps).
*/
public static boolean hasJavaNature(IProject project) throws CoreException
{
if ( !project.isAccessible() )
throw new CoreException(Activator.createErrorStatus(ERR_PROJECT_CLOSED));
return project.hasNature(JavaCore.NATURE_ID);
}
/**
* Gets the Java Project from a Project.
*
* @return The Java project.
*
* @throws CoreException If project nature could'nt be retrieved.
*/
public static IJavaProject getJavaProject(IProject project) throws CoreException
{
if ( !hasJavaNature(project) )
throw new CoreException(Activator.createErrorStatus("Project is not of Java Nature"));
// Get Java project: must work!
IProjectNature nature=project.getNature(JavaCore.NATURE_ID);
try
{
try
{
// This used to work up until Eclipse 2024-xx when it suddenly stopped!
return (IJavaProject)nature;
}
catch(ClassCastException e)
{
// This way, at least a JavaProject is created...
return JavaCore.create(project);
}
}
catch(Throwable t)
{
throw new CoreException(Activator.createErrorStatus(ERR_PROJECT_CLOSED,t));
}
} |
|
OK, so there might be a hint here: I opened another workspace that contained only plain and Java projects, along with two plug-in projects, without Maven (Tycho), then I didn't get the warning about missing The only two plugin projects has Plugin projects like: Java projects as: Other projects as: |
That ProjectDescription.natures seems not to be multithreading save, i will suggest a PR |
Can you please explain where multiple threads are involved here? |
eclipse ide is multithreaded. any thread can call get/set on that natures |
That's a general purpose statement like "eclipse ide uses java" if we use this as a general development guideline then we need to effectively sync everything everywhere... especially in this case, the project description will be read exactly once and nothing in this thread indicates that the natures are ever changed. |
|
I think what may happen (to be confirmend in practice):
See |
|
A possible solution would be to clone the current description, update it with the values of the new description and set it atomically on the ProjectInfo. ProjectInfo.description must be marked as volatile in that case, though. |
Thats exactly what java demands: either make sure your data is private and accessed single threaded only or use concurrent datastructures :-(
Even the initialize technically would be an update that can go wrong without a final keyword, but there is not even a initializer on the natures field but setter access only. |
It is reported that sometimes ProjectDescription#hasNature(String) returns wrong values. While it is not clear how that happens chances are that this a concurrency problem: ProjectDescription can be used from arbitrary threads and yet totally missed any synchronization. eclipse-pde/eclipse.pde#1185 "when multiple threads share mutable data, each thread that reads or writes data must perform synchronization." https://ahdak.github.io/blog/effective-java-part-10/
|
This now gives false positive errors:
|
It is reported that sometimes ProjectDescription#hasNature(String) returns wrong values. While it is not clear how that happens chances are that this a concurrency problem: ProjectDescription can be used from arbitrary threads and yet totally missed any synchronization. eclipse-pde/eclipse.pde#1185 "when multiple threads share mutable data, each thread that reads or writes data must perform synchronization." https://ahdak.github.io/blog/effective-java-part-10/
It is reported that sometimes ProjectDescription#hasNature(String) returns wrong values. While it is not clear how that happens chances are that this a concurrency problem: ProjectDescription can be used from arbitrary threads and yet totally missed any synchronization. eclipse-pde/eclipse.pde#1185 "when multiple threads share mutable data, each thread that reads or writes data must perform synchronization." https://ahdak.github.io/blog/effective-java-part-10/
|
I have now been able to reproduce the problem and will provide a PR soon one need the following setup:
Now one must delete the Now go to the JDK preferences and choose another JDK as the default (e.g. Java 21 if currently Java 17 is the default), this will trigger a rebuild of both projects and the checker complains that both projects have a missing build.properties file even though only the Plugin Project has the builder explicitly enabled, this is because |
Currently MinimalState schedules a build for every project that has any PDE nature, this can lead to projects scanned that have no ManifestBuilder enabled at all and creating unrelated warnings. This now checks if the builder is enabled for the project before scheduling a build. Also the check for possible invalid invocations is moved up so it is triggered even if a build.properties exits. Fix eclipse-pde#1185
Currently MinimalState schedules a build for every project that has any PDE nature, this can lead to projects scanned that have no ManifestBuilder enabled at all and creating unrelated warnings. This now checks if the builder is enabled for the project before scheduling a build. Also the check for possible invalid invocations is moved up so it is triggered even if a build.properties exits. Fix eclipse-pde#1185
Currently MinimalState schedules a build for every project that has any PDE nature, this can lead to projects scanned that have no ManifestBuilder enabled at all and creating unrelated warnings. This now checks if the builder is enabled for the project before scheduling a build. Also the check for possible invalid invocations is moved up so it is triggered even if a build.properties exits. Fix eclipse-pde#1185
Currently MinimalState schedules a build for every project that has any PDE nature, this can lead to projects scanned that have no ManifestBuilder enabled at all and creating unrelated warnings. This now checks if the builder is enabled for the project before scheduling a build. Also the check for possible invalid invocations is moved up so it is triggered even if a build.properties exits. Fix eclipse-pde#1185
Currently MinimalState schedules a build for every project that has any PDE nature, this can lead to projects scanned that have no ManifestBuilder enabled at all and creating unrelated warnings. This now checks if the builder is enabled for the project before scheduling a build. Also the check for possible invalid invocations is moved up so it is triggered even if a build.properties exits. Fix #1185
|
I'll consider this fixed unless someone can provide a new stack trace from the error log view here. Be aware that likely one needs to delete the warnings once manually as there is no one who will clean them automatically. |
|
Yes, definitely one needs to remove the warnings manually. Even a clean does not remove them. |
Happens in platform workspace and is also asked often on Stackoverflow
It is produced by ManifestConsistencyChecker - no idea why it runs on non-PDE projects, Anybody an idea? otherwise i would just add a doublecheck that it does nothing when the project has no plugin nature.
The text was updated successfully, but these errors were encountered: