jaxb2-maven-plugin

jaxb2-maven-plugin copied to clipboard

Running Maven within Eclipse 2018-12 on MacOS. I have a POM which works on windows but fails on my MacOS setup. It appears to be prefixing the path to the source with the path of the eclipse application.

My source file is at: /Users/christ/Dev/KeyDirectory/Gateway-Message/src/main/xsd/Message.xsd

This is the error I see in the Maven log:

2019-03-12, 2:22:14 p.m. EDT: [ERROR] null [-1,-1] schema_reference.4: Failed to read schema document 'file:/Applications/Eclipse.app/Contents/MacOS/Users/christ/Dev/KeyDirectory/Gateway-Message/src/main/xsd/Message.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>.

Running mvn package from the command line does allow it to run however.

This seems to be Eclipse-related, implying that anyone with Eclipse IDE expertise is welcome to supply an Integration Test and a patch.

This seems related to https://github.com/mojohaus/jaxb2-maven-plugin/issues/149 and https://github.com/mojohaus/jaxb2-maven-plugin/issues/153

just look at the path: on macOS /Applications and /Users are in the root of the disk correct = /Applications/Eclipse.app/Contents/MacOS correct = /Users/christ/Dev/KeyDirectory/Gateway-Message/src/main/xsd/Message.xsd invalid = /Applications/Eclipse.app/Contents/MacOS/Users/christ/Dev/KeyDirectory/Gateway-Message/src/main/xsd/Message.xsd

I have the same issue during generating source from maven.

After some debugging I found out that

class AbstractJavaGeneratorMojo extends AbstractJaxbMojo {
....

    private String[] getXjcArguments(final String classPath, final String episodeFileNameOrNull) {
........
     if ("file".equalsIgnoreCase(current.getProtocol())) {
                    unwrappedSourceXSDs.add(FileSystemUtilities.relativize(
                            current.getPath(),
                            new File(System.getProperty("user.dir")),
                            **true**));
                } 

The FileSystemUtilities.relativize will remove the '/' separator from the beginning of the file path (because the third parameter passed as removeInitialFileSep = true ). This will case an issue later. Since thats a relative path. And later it will append the base dir to it. Then the whole generation call will end up looking for a non existent file.

Me personally I would pass in with removeInitialFileSep = false . I've change in the debugger the flag and my use case passed. Of corse I do not see all the consequence. But it is clearly in my case the current.getPath() path is not starting with the system.user.dir that means nothing to make relative as base path is not equals with the user dir.

That code tries to relativize to the current directory ("user.dir"). Why?

1. The current directory inside Eclipse (at least when run on Mac) is the directory where Eclipse is installed. This may be anywhere and has got nothing to do with where the sources are, which may be anywhere else.
2. To reproduce the problem, just run a normal maven build from outside the project hierarchy: cd ~/somewhereElse && mvn clean install -f ~/myProject/pom.xml Ka-boom.
3. The proper fix IMO is not to relativize at all, but instead consider relative paths relative to ${project.builddir}.

@lennartj

This seems to be Eclipse-related, implying that anyone with Eclipse IDE expertise...

Not really Eclipse-related, just any out-of-tree build runs into this.

... is welcome to supply an Integration Test and a patch.

See #168. The test is a bit convoluted; don't know if there'd be a better way to test this. It works, though: fails in the expected way without the fix, succeeds with the fix. (Tested locally on OS X, and verified that this indeed solves the issue also when running via m2e in Eclipse.)

BTW: #143 is also a good fix. (But using String.startsWith() to check for path prefixes is not good anyway; "/home/somebody/foo" should not be a path prefix of "/home/somebody/foobar". Which is issue #149.)

@lennartj: is this plug-in still maintained? Would be good to have a new version published with the fixes for issues #123, #131, and #149. Once Patrick's fix for #131 (PR #143) is in, I could provide a fix for issue #149, too.

same for me. This bug breaks my CICD pipeline.