Fails with InvalidPathException when launched from Eclipse about archunit HOT 7 CLOSED

Yep, can confirm, with 0.8.2 everything works fine, thanks a lot.

from archunit.

I've just tried running a JUnit test under Windows 10 with Eclipse Oxygen and I haven't run into that problem.
Are you using ArchUnit 0.8.1 ? I think 0.8.0 had a problem like this if you'd use Windows and Java >= 9.
If you're using 0.8.1 I have to look into it closer, why the error doesn't appear on my Windows box with Eclipse (any information about your setup would be helpful then, for example how System.getProperty("java.class.path") looks like)

from archunit.

I'm using

• Eclipse Neon
• ArchUnit 0.8.1
• Windows 10
• JDK 8

path looks like this:

C:\projects\workspaces\playfield\dummy\target\test-classes;C:\projects\workspaces\playfield\dummy\target\classes;C:\projects\m2\repository\com\tngtech\archunit\archunit\0.8.1\archunit-0.8.1.jar;C:\projects\m2\repository\org\slf4j\slf4j-api\1.7.7\slf4j-api-1.7.7.jar;C:\projects\m2\repository\junit\junit\4.12\junit-4.12.jar;C:\projects\m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar;/C:/Software/eclipse/eclipse-neon-developer/eclipse/configuration/org.eclipse.osgi/432/0/.cp/;/C:/Software/eclipse/eclipse-neon-developer/eclipse/configuration/org.eclipse.osgi/431/0/.cp/

from archunit.

Ah, I see. So from my point of view, this looks like a bug in Eclipse, i.e. Eclipse creates a wrong "java.class.path" system property. I've cross checked

https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html

where it pretty clearly states, that the classpath should be of the form "C:\foo;C:\bar" and not sth. like "/C:/" so I think Eclipse is at fault here. I've also found another issue with that respect 😉

gwtproject/gwt#9564

The combination of some entries of the form "C:..." and some entries of the form "/C:/..." seems strange anyway, I would guess it's some erroneous conversion of URL to path.

Originally I was wondering, if I should add more robustness against wrong classpath entries, or not, and decided against it, since I thought clients should just supply valid classpath properties (which so far seemed to work out within IntelliJ, Maven and Gradle). But I see that this is kind of hard to achieve when running tests within Eclipse, since (as far as I know) control over this part of the supplied classpath is limited.

I'll make this more robust and add error logging instead, if an invalid file path is encountered within the classpath property.

from archunit.

I've looked closer into this, and I could reproduce this issue with Eclipse Neon. It seems to be gone with Eclipse Oxygen, though.
It seems like the JRE itself is resilient enough to parse these types of entries (the respective URLClassLoader knows these URLs), so I've added a fallback to parse entries of the form "/C:/foo/bar" as well as "C:\foo\bar" (I've also labeled it as a bug now, instead of an enhancement, since the JRE can handle it 😉)
I'll release a new bugfix version soon.

from archunit.

Great thx a lot

from archunit.

It's on Maven Central now: https://search.maven.org/#search%7Cga%7C1%7Carchunit
I'm pretty positive that it solves the problem, since I've tried Eclipse Neon, too, and the problem disappeared with the upgrade, but I'd be happy about a short "works on my machine" from you 😉

from archunit.