Upgrade to a modern build tool

[alexanderankin]

since this repo comes up as the top hit for java developers trying to use relaxng, it seems like it could benefit from using a modern build tool instead of ant

[ndw]

I looked into that briefly the last time I was working on it. I quickly concluded that it would probably prove challenging. The repository layout and build systems are a bit...nonstandard.

[alexanderankin]

yeah i got it to work for compiling just the class files, next step is going tests, which may or may not involve hard coding the services, it looks like ant was creating META-INF files during the build.

[alexanderankin]

@ndw - just pushed it here - https://github.com/relaxng/jing-trang/compare/master...alexanderankin:gradle?expand=1

[sideshowbarker]

@ndw - just pushed it here - master...alexanderankin:gradle?expand=1 (compare)

@alexanderankin Will you be opening a pull request with that patch?

[alexanderankin]

I think there are a couple more milestones for me to hit before its ready, namely: 1) tests and 2) the two jars being put in the same directory as before.

I put a day into it to test feasibility, I can get it over the line if you guys are interested in merging - if yes, ill get back to it this upcoming week.

[sideshowbarker]

I put a day into it to test feasibility, I can get it over the line if you guys are interested in merging - if yes, ill get back to it this upcoming week.

I can’t speak for the other maintainers, but if the patch works and is easy enough to run, then I highly doubt anybody here is going to object to merging it.

One nice thing about build patches is that it’s trivial for anybody to find out if they work or not — they don’t don’t really have a risk of introducing invisible regressions; the build either continues to produce output that runs as expected, or it doesn’t

And as far as the wider community goes, it seems clear there’s significant interest in being able to use a better build system.

That said — and again not attempting to speak for the other maintainers here — I don’t personally feel strongly about the need to replace the current build system. So it’s not a very high priority for me at least. But I’m not very well socialized at all into Java community, so I think my lack of feeling pain with the current build system here is probably not the norm.

And because I’m relatively not very up to speed with other current Java build systems, I wouldn’t be the best person to review any build patches and tests if they required a lot of very-careful scrutiny to make sure there are no regressions.

But as I said, because of the nature of it, I wouldn’t expect build-changes review to be something that requires a super high level of expertise — so probably even I could manage to help with the review.

[alexanderankin]

still working on this, hit a bit of an issue with services - ant is detecting classes which implement the given interface on the classpath and generating resources, working on resolving that

[alexanderankin]

Hey, I'm going to hard code some of these service names... I spent quite a while trying to figure out this magic for instance, overwriting the file in what is essentially an xml-encoded bash script...

the shellscript-like xml snippet

   <target name="mod.nvdl.services">
      <mkdir dir="${build.dir}/mod/nvdl/classes/main/META-INF/services"/>
      <delete file="${build.dir}/mod/nvdl/classes/main/META-INF/services/com.thaiopensource.validate.auto.SchemaReceiverFactory"
              quiet="true"
              failonerror="false"/>
      <echo file="${build.dir}/mod/nvdl/classes/main/META-INF/services/com.thaiopensource.validate.auto.SchemaReceiverFactory"
            append="true"
            message="com.thaiopensource.validate.nvdl.NvdlSchemaReceiverFactory${line.separator}"/>
      <echo file="${build.dir}/mod/nvdl/classes/main/META-INF/services/com.thaiopensource.validate.auto.SchemaReceiverFactory"
            append="true"
            message="com.thaiopensource.validate.nrl.NrlSchemaReceiverFactory${line.separator}"/>
      <echo file="${build.dir}/mod/nvdl/classes/main/META-INF/services/com.thaiopensource.validate.auto.SchemaReceiverFactory"
            append="true"
            message="com.thaiopensource.validate.mns.MnsSchemaReceiverFactory${line.separator}"/>
   </target>

which is not actually linkable, its gitignored:

jing-trang/.gitignore

Line 5 in 84ec6ad

modbuild.xml

generated from here:

jing-trang/build.xml

Line 43 in 84ec6ad

<xslt style="build.xsl" in="modules.xml" out="modbuild.xml" force="true">

also the tests are incomprehensible, what does this even do? Any input helps (this is apparently a testng feature):

jing-trang/mod/nvdl/test/nvdltest.xml

Lines 1 to 7 in 84ec6ad

	<testSuite>
	<testCase>
	<incorrect>
	<thisIsJunk/>
	</incorrect>
	</testCase>
	<testCase>

[oliviercailloux]

@alexanderankin Still planning to introduce a PR about this? I think it would have a very positive effect by encouraging more PRs from other developers who might otherwise be discouraged by the build system.

[alexanderankin]

I couldn't figure out the unit tests unfortunately

…

On Sat, Mar 18, 2023, 7:13 PM Olivier Cailloux ***@***.***> wrote: @alexanderankin <https://github.com/alexanderankin> Still planning to introduce a PR about this? I think it would have a very positive effect by encouraging more PRs from other developers who might otherwise be discouraged by the build system. — Reply to this email directly, view it on GitHub <#266 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACECGJCWXC5D4WLHS3YBD7TW4Y6Q7ANCNFSM5XIKFXDQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>