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

FileNotFoundException when sources are relatively referenced outside maven project #131

Open
kotelnik opened this issue May 21, 2019 · 14 comments · May be fixed by #143
Open

FileNotFoundException when sources are relatively referenced outside maven project #131

kotelnik opened this issue May 21, 2019 · 14 comments · May be fixed by #143

Comments

@kotelnik
Copy link

Plugin fails to generate java from XSD when source is specified e.g. like this:
<source>${basedir}/../../xsd-sources/source.xsd</source>

In first "phase" it finds the source so it is handed over to the xjc driver but then this driver prepends a working directory to the resolved absolute path. So from resolved path:
/home/username/xsd-sources/source.xsd
...it becomes:
/home/username/projects/xsd-project/home/username/xsd-sources/source.xsd
...which of course does not exist.

This worked nicely with plugin version 1.6 that I use for now. Anyway, thanks for this plugin! :-)

@goodale
Copy link

goodale commented Jul 19, 2019

we are seeing the same error. oddly, it is only occuring on Ubuntu 18.04 (Maven 3.6.1 and AdoptOpenJDK 11). The v2.5.0 plugin works fine on Windows 10 64 bit (Maven 3.6.0 and AdoptOpenJDK 11) with the exact same mvn command but fails on Ubuntu.

$ mvn org.codehaus.mojo:jaxb2-maven-plugin:2.5.0:xjc -X

@lennartj This is currently marked as an 'enhancement'. Unless @kotelnik and I are mistaken this seems to be a bug rather than an enhancement.

@goodale
Copy link

goodale commented Jul 19, 2019

Anyone aware of a workaround? We're migrating to Java 11 and therefore need version 2.5.0

@pieter-v
Copy link

I think, this is related to #53

@lennartj
Copy link
Member

lennartj commented Jul 22, 2019

I believe this is indeed an enhancement request for the plugin to support something it currently does not, namely having sources reside outside of the project as indicated by the ${basedir}/../../some/path.

The suggested workaround is to supply a project where all the XSDs are compiled, and - downstream in the project - use the dependency on that project (including its compiled JAXB classes) instead of placing the XSD or other sources outside the project itself.

#53 is a duplicate of this issue.

@andham
Copy link
Member

andham commented Jul 22, 2019

Maven best-practice IMHO is to never use something outside of the project filesystem-wise during build.

@lennartj
Copy link
Member

That is, indeed, the Maven Way (tm) - and for good reason.
The standard approach is:

  1. If you need some resource or plugin to build the current project, include them within the current project.
  2. If you need some resource or plugin in several projects (i.e. "Multi-Module Build"), include them in a separate project and depend upon that project within all projects requiring the resource.

@goodale
Copy link

goodale commented Jul 22, 2019

The use of ${project.basedir} was a carry-over from a previous developer and worked fine with the previous version of jaxb2-maven-plugin. I just updated the pom to remove ${project.basedir}. I'm still getting the error and it appears to be duplicating the path, but only on the Maven running on Ubuntu (works fine on my PC)

Previously the pom had:

${project.basedir}/src/main/resources/rc-api.xsd

And now it has:

src/main/resources/rc-api.xsd

I have also tried:

/src/main/resources/rc-api.xsd

[ERROR] null [-1,-1]
org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'file:/root/.jenkins/jobs/API%20v3.0/workspace/root/.jenkins/jobs/API%20v3.0/workspace/src/main/resources/rc-api.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.

I'm running the following maven command within the workspace folder on both the Windows 10 and Ubuntu:

mvn org.codehaus.mojo:jaxb2-maven-plugin:2.5.0:xjc -X

p.s. This project does not have a parent pom

@lennartj
Copy link
Member

lennartj commented Jul 22, 2019 via email

@goodale
Copy link

goodale commented Jul 22, 2019

thank you - will give that a try

@goodale
Copy link

goodale commented Jul 22, 2019

just a note that the path and file name haven't changed since our usage of the previous version of jaxb2-maven-plugin (v1.6)

everything worked fine with the following version, same project name, XSD and same path and Java 1.8
org.codehaus.mojo
jaxb2-maven-plugin
1.6

@ummels
Copy link

ummels commented Jul 30, 2019

We are experiencing the same issue: Locally, the plugin works fine (generating Java bytecode from XSD). However, on our Jenkins instance it fails because the path of the workspace contains a space.

The problem seems to have been introduced between version 2.3.1 and version 2.4 of the plugin.

We are using a relative source in the form:
<source>src/main/xsd/source.xsd</source>.

@goodale
Copy link

goodale commented Aug 5, 2019

I fixed this by renaming the Jenkins projects so they didn't contain spaces. It is a sufficient work-around but does appear to be a bug in the new version since the old version handled spaces without an issue.

@byteit101
Copy link

I ran across this issue, and have a fix waiting in PR #143

@rslkvk
Copy link

rslkvk commented Dec 14, 2021

I ran across this issue, and have a fix waiting in PR #143

I have tried out your fix locally and it worked with the relatively referenced path. But there is still an error thrown: com.sun.istack.SAXParseException2: "file:./../...xsd" **is not a part of this compilation**. Is this a mistake for "file: ../../...xsd"

Any guesses on how to get around this? Is the plugin now set the way that no files from external folders may be included?

I appreciate every suggestion. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants