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

Trying again to debug why importing some maven repositories simply fails to generate a valid .classpath file #1801

Open
davidmichaelkarr opened this issue Aug 9, 2024 · 0 comments

Comments

@davidmichaelkarr
Copy link

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):

<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="src" path="target/generated-sources/annotations">
		<attributes>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" path="target/generated-sources/xjc/bds"/>
	<classpathentry kind="src" path="target/generated-sources/xjc/csi_crm"/>
	<classpathentry kind="src" output="target/classes" path="src/main/java">
		<attributes>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry excluding="**" kind="src" output="target/classes" path="src/main/resources">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/test-classes" path="src/test/java">
		<attributes>
			<attribute name="test" value="true"/>
			<attribute name="optional" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry excluding="**" kind="src" output="target/test-classes" path="src/test/resources">
		<attributes>
			<attribute name="test" value="true"/>
			<attribute name="maven.pomderived" value="true"/>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="GROOVY_DSL_SUPPORT">
		<attributes>
			<attribute name="maven.pomderived" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="src" output="target/test-classes" path="target/generated-test-sources/test-annotations">
		<attributes>
			<attribute name="test" value="true"/>
			<attribute name="optional" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
		<attributes>
			<attribute name="module" value="true"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="output" path="target/classes"/>
</classpath>

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.

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

No branches or pull requests

1 participant