Holodeck B2B is an AS4 system-to-system messaging solution that implements the OASIS specifications for ebMS3 and it's AS4 profile. For more information visit the project website
I've just been tinkering with getting holodeck building inside Eclipse on Windows.
I'm completely new to Eclipse, Maven, etc. so it's been a bit of a crash course and hence this might not be a real issue and rather a misunderstanding or Eclipse misconfiguration on my part.
I've been getting lots of test failures in the holodeck test suite via maven,
I've tracked down the root cause to code fragments like the following:
The strings returned on Windows for this end up being of the form "/C:/path/to/dir/" since I gather that returns the path part of a URL i.e. with the "file:" (protocol) portion chopped off.
The File objects in Java don't like filenames like that under Windows and throw java.nio.file.InvalidPathException: Illegal char <:> at index 2 exceptions when passed them.
I had success in getting the tests to work on Windows by changing those code fragments to the following:
Since that will translate such paths into the "C:\path\to\dir\" that Windows is happy with.
I had been doing that test by test as I hit exceptions but I've since realised that all of the tests that use resources contain this fragment and sometimes the resulting exceptions are caught and the tests are skipped without error because they can't access a supplied test file resource.
Since this seems to be systemic and require a lot of changes, I'm now not sure if this isn't actually an Eclipse configuration issue. And maybe my code changes would then break the tests on Linux. I don't speak Java or Eclipse well enough to know the answer to that. So I'm raising it here where wiser heads can point out the error of my ways.
If it turns out I'm not just a Java/Eclipse newbie and that this is a 'real' issue that would prevent the running of the test suite of Windows, would a patch that fixed all the tests to more 'portable' resource path handling be welcome?
If so, it looks like the best way forward is to grep the test code base looking for the problem pattern (i.e. getResource(*).getPath()) to make sure I find them all.
I've just been tinkering with getting holodeck building inside Eclipse on Windows.
I'm completely new to Eclipse, Maven, etc. so it's been a bit of a crash course and hence this might not be a real issue and rather a misunderstanding or Eclipse misconfiguration on my part.
I've been getting lots of test failures in the holodeck test suite via maven, I've tracked down the root cause to code fragments like the following:
baseDir = <...>.getClassLoader().getResource("some-resource").getPath();
The strings returned on Windows for this end up being of the form "/C:/path/to/dir/" since I gather that returns the path part of a URL i.e. with the "file:" (protocol) portion chopped off.
The File objects in Java don't like filenames like that under Windows and throw java.nio.file.InvalidPathException: Illegal char <:> at index 2 exceptions when passed them.
I had success in getting the tests to work on Windows by changing those code fragments to the following:
baseDir = Paths.get(this.getClassLoader().getResource("some-resource").toURI()).toString();
Since that will translate such paths into the "C:\path\to\dir\" that Windows is happy with.
I had been doing that test by test as I hit exceptions but I've since realised that all of the tests that use resources contain this fragment and sometimes the resulting exceptions are caught and the tests are skipped without error because they can't access a supplied test file resource.
Since this seems to be systemic and require a lot of changes, I'm now not sure if this isn't actually an Eclipse configuration issue. And maybe my code changes would then break the tests on Linux. I don't speak Java or Eclipse well enough to know the answer to that. So I'm raising it here where wiser heads can point out the error of my ways.
If it turns out I'm not just a Java/Eclipse newbie and that this is a 'real' issue that would prevent the running of the test suite of Windows, would a patch that fixed all the tests to more 'portable' resource path handling be welcome?
If so, it looks like the best way forward is to grep the test code base looking for the problem pattern (i.e. getResource(*).getPath()) to make sure I find them all.