Travis-CI: "trusty" works, "xenial" fails #173
Comments
|
Please explain which specific issues you're facing. I have also no idea what "trusty" and "xenial" are. |
|
"trusty" is a build environment of Travis-CI (an online Continuous Integration tool), that is based on Ubuntu 14.04. The configured environment "openjdk8" currently uses the following configuration (which in itself is imho an error - I raised it at https://travis-ci.community/t/using-jdk-openjdk8-brings-javac-9-0-1/3371). See https://travis-ci.org/phax/ph-ubl/jobs/531109413 for details: The verbose, working, output on this platform is: It works also with the "openjdk11" configuration (see https://travis-ci.org/phax/ph-ubl/jobs/531109415): When switching to the Travis "xenial" platform, that is based on Ubuntu 16.04, running also with JDK 8 and JDK 11 the compilation does not work. and the verbose output for compilation is (see https://travis-ci.org/phax/ph-ubl/jobs/531118439): I skipped a lot of similar error messages. I also tried working with "-e -X" on the Maven commandline and it seems to be an issue with the XML include resolution. So my question is: why does it work on Ubuntu 14.04 with OpenJDK 8/9 and 11 but not on Ubuntu 16.04 with OpenJDK 8 and 11???? |
|
I compared the output of both versions and noticed a difference in the following 5 rows. The order of files is different, but no difference in the content itself was found (they have exactly the same byte size): Here are the files for easier comparison of the above: The pom.xml relevant part is at https://github.com/phax/ph-ubl/blob/master/ph-ubl20/pom.xml#L120 |
|
FYI I could build To be honest, I have no idea. Except that I'm pretty sure that the problem is not in the The question is, how do we address the problem as I can't really reproduce it. Below are some suggestions. Let's focus on Java 8 as Java 11+ is not supported yet (anything could happen there). An even with Java 9 and 10 there's not so much experience yet. There are a few differences between two environments. Operating system version, Java version (even patch version may matter), order of schema files. It would be good to find out what exactly is causing the problem. I don't think that OS version has directly to do with it. That would be too surprizing. So I'd suggest to hold this option back for the moment. Java version might have something to do with it. Is it possible to install Java What I also noticed is that in one case JAXB API is loaded from JRE: https://travis-ci.org/phax/ph-ubl/jobs/531118439#L1430 (not working) In the other from Maven artifacts: https://travis-ci.org/phax/ph-ubl/jobs/531109415#L1976 (working) I think JRE bundles JAXB 2.2 (not 100% sure), so maybe this is some XJC 2.3.x/JAXB 2.2 incompatibility. Please try Next, the order of files. Should not matter but who knows. At the moment you simply include Finally, try to find a subset of schemas which compiles and incrementally add further schemas until it breaks. How about starting with, say Me personally, I'd start with the last suggestion. Please keep me informed how it goes. As I mentioned above, I don't think the problem is in |
|
See this: Seems like the order of files is important. |
|
Thanks. For the update. I tried switching back to 0.13.3 - still an error. |
|
I switched from <schemaIncludes>
<schemaInclude>common/*.xsd</schemaInclude>
<schemaInclude>maindoc/*.xsd</schemaInclude>
</schemaIncludes>to <schemaIncludes>
<schemaInclude>common/CodeList_LanguageCode_ISO_7_04.xsd</schemaInclude>
<schemaInclude>common/CodeList_MIMEMediaTypeCode_IANA_7_04.xsd</schemaInclude>
<schemaInclude>common/CodeList_UnitCode_UNECE_7_04.xsd</schemaInclude>
<schemaInclude>common/CodeList_CurrencyCode_ISO_7_04.xsd</schemaInclude>
<schemaInclude>common/CCTS_CCT_SchemaModule-2.0.xsd</schemaInclude>
<schemaInclude>common/UnqualifiedDataTypeSchemaModule-2.0.xsd</schemaInclude>
<schemaInclude>common/UBL-QualifiedDatatypes-2.0.xsd</schemaInclude>
<schemaInclude>common/UBL-CoreComponentParameters-2.0.xsd</schemaInclude>
<schemaInclude>common/UBL-CommonBasicComponents-2.0.xsd</schemaInclude>
<schemaInclude>common/UBL-CommonAggregateComponents-2.0.xsd</schemaInclude>
<schemaInclude>common/UBL-CommonExtensionComponents-2.0.xsd</schemaInclude>
<schemaInclude>common/UBL-ExtensionContentDatatype-2.0.xsd</schemaInclude>
<schemaInclude>maindoc/UBL-ApplicationResponse-2.0.xsd</schemaInclude>
</schemaIncludes>and still get the error: Therefore I added "-e -X" to the Maven commandline and get the following output from the XML Resource Resolver: |
|
Try to reduce the set of schemas and achieve some kind of configuration which works. |
|
Debug messages in |
|
But there is a difference in the resolution between the two versions. I switched back to "trusty" with the reduced set, and "-e -X" turned off, and it looks like this: the error is okay, because I didn't adopt the bindings file |
Could you please elaborate? I don't immediately see what you mean. |
|
I will respond to your question asap. The difference is: -> than comes the error. In the "trusty" version more happens: |
|
Is there a way to turn on more debug logging in XML/XSD include resolution? |
|
@phax I think it's the maximum. Changing order of schemas did not help, did it? |
|
No it didn't help. I tried already multiple orders and always the same result. |
It's not so easy. We should separate
But whether and if XJC will use the passed entity resolver to resolve anything is entirely up to XJC (and whatever it uses underneath). I think the passed entity resolver is not used there as the primary resolver but rather as a component in some other resolver. That's the where the actual problem seems to be. From javaee/jaxb-v2#906 it seems like people could work around the problem by changing the order of schemas. I'm a bit puzzled why this did not work for you. If you change the order of schemas, do you see any change in the order of resolution? I'm really sorry you have to endure this. |
|
Just to show some progress - I managed to get your latest verison deployed with my groupId: https://oss.sonatype.org/content/repositories/snapshots/com/helger/maven/ - now modify and increase logging... |
|
Well, I was distracted with other topics.
Whereas the calculated
even though the schemaIncludes in the pom.xml contains no single wildcard. Continuing.... |
|
So the source of error, seems to be the inconsistent result of with trusty (14.04), the debug output provides the following order: I looked at the |
|
@highsource I think I found a reasonable workaround for the problem. private static boolean isWildcard (final String s)
{
return s.indexOf ('*') >= 0 || s.indexOf ('?') >= 0;
}
/**
* Reorder the result of "scanner.getIncludedFile" so that the order of the
* source includes is maintained as good as possible. Source wildcard matches
* are postponed to the end.<br>
* Examples:<br>
* If the includes contain [a, b, c] and the resulting list should be in that
* order.<br>
* If the includes contain [a, b*, c] the resulting list should be [a, c,
* matches-of(b*)]
*
* @param resolvedFiles
* resolved files from scanner.getIncludedFiles. May not be <code>null</code>.
* @param includes
* The source includes in the correct order. May be <code>null</code> or empty.
* @return The ordered list of files, that tries to take the source order as good as possible
*/
private static List <File> reorderFiles (final List <File> resolvedFiles, final String [] includes)
{
if (includes == null || includes.length == 0)
{
// return "as is"
return resolvedFiles;
}
final List <File> ret = new ArrayList <> (resolvedFiles.size ());
for (final String inc : includes)
{
// Only deal with fixed files
if (!isWildcard (inc))
{
// Ensure to use the system path separator
final String sUnifiedInclude = inc.replace ('\\', File.separatorChar).replace ('/', File.separatorChar);
// Find all matches in the resolved files list
final List <File> matches = new ArrayList <> ();
for (final File resFile : resolvedFiles)
if (resFile.getAbsolutePath ().endsWith (sUnifiedInclude))
matches.add (resFile);
for (final File match : matches)
{
// Add all matches to the result list
ret.add (match);
// Remove from the main list
resolvedFiles.remove (match);
}
}
}
// Add all remaining resolved files in the order "as is"
ret.addAll (resolvedFiles);
return ret;
}Do you want to to create a PR? |
|
@highsource any chance for a new release of this? |
phax
added a commit
to phax/maven-jaxb2-plugin
that referenced
this issue
Jun 18, 2019
Proposed fix for highsource#173
Closed
|
Fixed in v2.0.4 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
I’m struggeling with unexpected issues with the maven-jaxb2-plugin on Travis-CI.
I tried to switched from “trusty” (14.04) to “xenial” (16.04) and got https://travis-ci.org/phax/ph-ubl/builds/525708887 which in turn leads to a different behaviour of the Maven plugin (I assume it is the Maven plugin because it is the same error on all 3 JDK versions). I switched back to “trusty” and it was working again… Other projects using the same Maven plugin and version are working well in “xenial”. I can provide the difference in logs if needed.
I am running it locally with Maven 3.6.1 and Java 8, Java 11 and Java 12 without issues and I am a bit stuck here. Anyone has a pointer where I might search? Is there any difference between “xenial” and “trusty” that might have caused this problem? Anyone being aware of anything?
Thanks - any input is welcome.
The text was updated successfully, but these errors were encountered: