search

mojohaus / jaxb2-maven-plugin

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

XJB Argument is shortened. #5

Closed yogeshrao closed 9 years ago

yogeshrao commented 9 years ago

Hi,

We are using the jaxb2-maven-plugin version 2.1 on JDK 8. Our project basically is a multi module maven project with the directory structure as :

Parent
|__ sub module 1
      |_pom.xml
|__ sub module 2
      |_ pom.xml
|_ pom.xml

One of the maven sub module is using the jaxb2-maven-plugin for generating JAXB classes by providing the xjb and xsd's.

The plugin works fine as long as the sub module pom is directly invoked however the code fails to generate JAXB classes when it is run from the parent pom, exception thrown during execution is 

com.sun.istack.SAXParseException2; IOException thrown when processing "file:/D:/workspace/project1/parent/src/main/xsd/bindings.xjb". Exception: java.io.FileNotFoundException: D:\workspace\project1\parent\src\main\xsd\bindings.xjb (The system cannot find the path specified).
    at com.sun.tools.xjc.ErrorReceiver.error(ErrorReceiver.java:94)
    at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:402)
    at com.sun.tools.xjc.reader.internalizer.DOMForest.parse(DOMForest.java:274)
    at com.sun.tools.xjc.ModelLoader.buildDOMForest(ModelLoader.java:330)
    at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:377)
    at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:174)
    at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:119)
    at com.sun.tools.xjc.Driver.run(Driver.java:354)
    at org.codehaus.mojo.jaxb2.javageneration.AbstractJavaGeneratorMojo.performExecution(AbstractJavaGeneratorMojo.java:384)
    at org.codehaus.mojo.jaxb2.AbstractJaxbMojo.execute(AbstractJaxbMojo.java:200)

I looked up into the source code and found out that the plugin is actually shortening the argument with respect to the current directory, this approach would work if the pom invoked contains the plugin however in our case since parent pom is invoked the relative location generated by the mojo wouldn't actually be relative to the directory from where it is getting invoked.

Hence I feel that it would be best to modify the source org.codehaus.mojo.jaxb2.javageneration.AbstractJavaGeneratorMojo.java to undergo a change from 

        for (File current : getSourceXJBs()) {

            // Shorten the argument if possible.
            final String strippedXjbPath = FileSystemUtilities.relativize(
                    current.getAbsolutePath(), getProject().getBasedir());

            // Each XJB must be given as a separate argument.
            builder.withNamedArgument("-b", strippedXjbPath);
        }

to

        for (File current : getSourceXJBs()) {           

            // Each XJB must be given as a separate argument.
            builder.withNamedArgument("-b", current.getAbsolutePath());
        }

i.e. removing the logic for shortening the paths.

Let me know what you think about this and if needed can provide you a pull request of the changed code.

Regards, -Yogesh

architectron commented 9 years ago

Hi Yogesh,

I am facing the same issue (explained in my SO question here: http://stackoverflow.com/questions/30834601/using-xjb-with-jaxb2-maven-plugin

akhaware commented 9 years ago

Hi,

You can make it work with older version of jaxb2-maven-plugin (version 1.6), it requires a system property accessExternalSchema present . We have set the system property using a plugin within our maven pom

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>properties-maven-plugin</artifactId>
        <version>1.0-alpha-2</version>
        <executions>
          <execution>
            <id>set-additional-system-properties</id>
            <goals>
              <goal>set-system-properties</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <properties>
            <property>
              <name>javax.xml.accessExternalSchema</name>
              <value>file,http</value>
            </property>
          </properties>
        </configuration>
      </plugin>
lennartj commented 9 years ago

We have 2 requirements which somewhat oppose one another on this issue.

I'll look into this from both perspectives.

yogeshrao commented 9 years ago

How about generating a command file (containing several commands) in a temporary location and passing it to cmd for execution..

This command file could set environment variable containing directory path and use this environment variable in XJC and other commands which would be executed.

This is just an initial thought might have not completely thought through any other implications the approach might have.

Do let me know i can help providing a quick pull request if contributions are welcomed :)

Thank you!

Regards, -Yogesh

On Mon, Jun 15, 2015 at 7:45 PM, Lennart Jörelid notifications@github.com wrote:

We have 2 requirements which somewhat oppose one another on this issue.

-

We want the XJC and SchemaGen argument lines to be short enough not to overflow the windows command line buffer (remember, windows shells cuts the command line if it gets too long). The only other option (in case the command line gets "too long") is to stash the SchemaGen command into a temporary JAR file and execute that - instead of actually executing the SchemaGen within the local shell

We want the arguments to be correct, so that the SchemaGen and XJC operates properly

I'll look into this from both perspectives.

— Reply to this email directly or view it on GitHub https://github.com/mojohaus/jaxb2-maven-plugin/issues/5#issuecomment-112083804 .

lennartj commented 9 years ago

I believe that other Maven plugins use the "create a temporary JAR and execute it in java -jar" approach.

First - contributions are always welcome, particularly if they come with unit and Integration Tests attached.

Secondly - I will nose around to check if the JAR approach used by other plugins is easily sharable with the JMP

yogeshrao commented 9 years ago

Hello,

Quick question on the executable jar thing.. do you intend the store the arguments as well as part of the executable jar or they would be passed to it?

I did look at how CXF's XJC plugin[1] handles this and arrived at following :

a. To my understanding they do not call the xjc.exe directly instead are calling a java class wrapping the calls to classes within com.sun.tools.xjc package and pass on the arguments

b. In forkmode they endup creating a temporary executable jar file with this wrapper class and execute it with arguments that needs to be passed.

You are right that they end up creating a executable jar however this seems more from the point of avoiding to write environment specific shell code.The long arguments would still be passed as part executable jar for calling the xjc.

[1] https://github.com/apache/cxf-xjc-utils/blob/master/cxf-xjc-plugin/src/main/java/org/apache/cxf/maven_plugin/

yogeshrao commented 9 years ago

Hello,

I got some time today and was looking at the code.. From what i understood I noticed that the plugin isn't spawning out a new process and instead giving a direct java call using Driver.run() with args, If such is the case it should be okay commenting out shortening the path logic.

Please let me know if I am missing out on something!

Regards, -Yogesh

yogeshrao commented 9 years ago

Hi,

any updates on this ? I see a pull request waiting to be merged if my above understanding is correct.

Regards, -Yogesh

lennartj commented 9 years ago

Fixed in bf17714b6c8b414b5f22b322ea34ca0632c04d8e

yogeshrao commented 9 years ago

Thanks!

jeffmaury commented 9 years ago

I had the problem with one of my project using 2.1. I switched to 2.2-SNAPSHOT and I'm still facing the problem with .xsd. I looked at the code and it seems the patch has been done for XJC files only not .xsd. Should we reopen ?

fericit-bostan commented 9 years ago

I have this same issue. Do we know when this will be addressed?

jeffmaury commented 9 years ago

I have submitted a pull request that fixes the pb Waiting for it to be applied

Jeff Le 28 juil. 2015 02:38, "Fericit Bostan" notifications@github.com a écrit :

I have this same issue. Do we know when this will be addressed?

— Reply to this email directly or view it on GitHub https://github.com/mojohaus/jaxb2-maven-plugin/issues/5#issuecomment-125390409 .

mw84367 commented 5 years ago

This issue is present in 2.4 again :(

tbres commented 5 years ago

And still present in 2.5.0

class101 commented 5 years ago

For me reverting to 2.3.1 fixed the issue (tested 2.4 and 2.5.0)

but I'm unsure if I got the same issue as you, leaving a bit more technical informations.

We have a multi maven project with the following supported mode of build:

No problems at all building under Windows, but under Linux, xjc and schemagen seem to have a recurring but random issue in the basedir calculation causing jax2-maven-plugin to look for file at the wrong locations as show below

10/29/19, 8:42:28 PM GMT: [ERROR] null [-1,-1] schema_reference.4: Failed to read schema document 'file:/root/eclipse-201909/root/0src/......', 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>. 10/29/19, 8:42:28 PM GMT: [DEBUG] Accepted configured sources [/root/0src/...xsd] My sources are in /root/0src/ but the plugin look at some point for /root/0src/

We had previously another problem Linux by asking the schemagen goal to look for a file with a relative folder change "../../" , the plugin always remove the first / of the generated absolute path at some point and this lead to a similar issue than /etc!=etc. We solved it by using the dependency plugin and the local repo rather than relative paths that is anyway bad practice.

But for the basedir problem I'm out of idea, I'm been testing relative, absolute paths, pluginManagements conf, nothing worked except downgrading

Again I'm unsure if I have to open another ticket for this issue, what gave me a link to this ticket is a search and someone having a similar issue here that is redirecting here

https://issues.jenkins-ci.org/browse/JENKINS-56829

class101 commented 5 years ago

Since this issue is closed I opened a newer one for better visibility

https://github.com/mojohaus/jaxb2-maven-plugin/issues/150