search

mojohaus / jaxb2-maven-plugin

JAXB2 Maven Plugin
https://www.mojohaus.org/jaxb2-maven-plugin/
Apache License 2.0
106 stars 77 forks source link

Incorrect path passed on MacOS #123

Open Beakster opened 5 years ago

Beakster commented 5 years ago

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.

lennartj commented 5 years ago

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

bergert commented 4 years ago

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

ggili commented 3 years ago

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.

tomaswolf commented 3 years ago

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}.
tomaswolf commented 3 years ago

@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.)

tomaswolf commented 3 years ago

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

tomaswolf commented 3 years ago

@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.

mlemnian commented 2 years ago

same for me. This bug breaks my CICD pipeline.