You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I work with numerous services with a very similar build and runtime architecture, they are all Java services that build with Maven. They are all stored in git.
For some of them, I can right-click on the repository and import to a project, and m2e will successfully see everything that it needs to see, resulting in a .classpath file that allows Eclipse to compile everything it needs, resulting in no red marks in the project. For some of those, it fails to notice generated source code in "target/generated-sources", but that's easily patchable by adding those source directories. However, right now I'm not aware of a repository that imports clean like this. I would have to look for that.
What is really annoying are the cases where the resulting .classpath file has almost nothing in it, or sometimes not existing at all. I'm looking at two samples right now, one that generates a very primitive .classpath file that doesn't know it's a Maven project, or even a Java project, even though the .project file it managed to produce has both the java and maven2 builders. The other one doesn't generate a .classpath file at all, and it has a .project file similar to the other project.
I have tried to produce "minimal examples" that still demonstrate the problem, but I've never been able to do that. These services all have numerous dependencies to internal projects, and that's simply impossible to separate out.
I thought that perhaps enabling the Maven console would provide some useful info, but I doubt it. The second project that failed to produce a .classpath file at all, generated output in the Maven console with no errors at all, although it did have some WARN entries about particular artifacts causing a failure to create some directories, like this:
8/9/24, 3:37:38 PM PDT: [WARN] could not create Dir using bundle from url bundleresource://309.fwk1071681222:31/. skipping.
8/9/24, 3:37:38 PM PDT: [WARN] could not create Dir using commons_vfs2 from url bundleresource://309.fwk1071681222:31/. skipping.
The first project, which did generate a .classpath file, although almost empty, didn't have those warnings, although it did have one ERROR about failing to rename a directory:
8/9/24, 3:07:24 PM PDT: [ERROR] Status ERROR: org.eclipse.equinox.p2.discovery code=0 Failed to discover all connectors. children=[Status ERROR: org.eclipse.equinox.p2.discovery code=0 M2ERemoteBundleDiscoveryStrategy failed with an error org.eclipse.equinox.p2.core.ProvisionException: An error occurred while downloading https://github.com/eclipse-m2e/m2e-discovery-catalog/releases/download/2.x/catalog-2.x.xml. The cache file C:\Users\dk068x\workspace-2024-06\.metadata\.plugins\org.eclipse.equinox.p2.discovery.compatibility\cache\downloading\discovery554145892 could not be renamed to C:\Users\dk068x\workspace-2024-06\.metadata\.plugins\org.eclipse.equinox.p2.discovery.compatibility\cache\discovery554145892.]```
If it's useful, here is the resulting .classpath file I got for the first project:
```
What it actually needed to be was this (manually patched):
I've had to manually patch many .classpath files because of this, and it was possible to do because I had some projects that either imported correctly. Getting this one today was somewhat of a challenge, because I'm setting up a reimaged laptop, and I realized I didn't have any valid .classpath files. Fortunately, I found one in our messaging system from a few weeks ago, when I sent my current working file to a different team member, who always has the same problem I do.
The text was updated successfully, but these errors were encountered:
I work with numerous services with a very similar build and runtime architecture, they are all Java services that build with Maven. They are all stored in git.
For some of them, I can right-click on the repository and import to a project, and m2e will successfully see everything that it needs to see, resulting in a .classpath file that allows Eclipse to compile everything it needs, resulting in no red marks in the project. For some of those, it fails to notice generated source code in "target/generated-sources", but that's easily patchable by adding those source directories. However, right now I'm not aware of a repository that imports clean like this. I would have to look for that.
What is really annoying are the cases where the resulting .classpath file has almost nothing in it, or sometimes not existing at all. I'm looking at two samples right now, one that generates a very primitive .classpath file that doesn't know it's a Maven project, or even a Java project, even though the .project file it managed to produce has both the java and maven2 builders. The other one doesn't generate a .classpath file at all, and it has a .project file similar to the other project.
I have tried to produce "minimal examples" that still demonstrate the problem, but I've never been able to do that. These services all have numerous dependencies to internal projects, and that's simply impossible to separate out.
I thought that perhaps enabling the Maven console would provide some useful info, but I doubt it. The second project that failed to produce a .classpath file at all, generated output in the Maven console with no errors at all, although it did have some WARN entries about particular artifacts causing a failure to create some directories, like this:
The first project, which did generate a .classpath file, although almost empty, didn't have those warnings, although it did have one ERROR about failing to rename a directory:
What it actually needed to be was this (manually patched):
I've had to manually patch many .classpath files because of this, and it was possible to do because I had some projects that either imported correctly. Getting this one today was somewhat of a challenge, because I'm setting up a reimaged laptop, and I realized I didn't have any valid .classpath files. Fortunately, I found one in our messaging system from a few weeks ago, when I sent my current working file to a different team member, who always has the same problem I do.
The text was updated successfully, but these errors were encountered: