Hello Jena Community,
I write regarding the recently retired 'jena-maven-tools' sub-project. It provided a maven plugin used to cleanly execute the 'jena-schemagen' tool during a maven build. I found this tool very useful for generating .java constants from domain ontologies. Example: I edit a file like GoodDomainOnto_owl2.ttl in my (maven) project source tree. Then I configure the jena-maven-tools plugin to run during my maven build, to cleanly generate updated java constants (in an output .java file). These constants are in turn used during later stages of the build. Very tidy! But there is trouble in the wind. I summarize what I have read about the apparent demise of this maven plugin in items 1A, 1B, 1C below. Then in item #2 I describe my own situation, listing some possible courses of action in 2A, 2B, 2C. 1A) There have been two mentions of 'jena-maven-tools' on the jena-users list in the last two years: https://lists.apache.org/[email protected]:lte=2y:jena-maven-tools 1B) One of those mentions is this announcment from Andy S., on 2018/12/14 entitled "Retiring Jena modules", where he said "we are looking at the status of: jena-maven-tools - command line schemagen is in jena-cmds." Obviously this was my BEST chance to speak up, but I tarried too long: https://markmail.org/message/v6i3d5ktqx5j6teb 1C) The other mention is the 3.13.0 release announcement on 2019/09/29, which included this fearsome notice: JENA-1760: Retire jena-maven-tools https://issues.apache.org/jira/browse/JENA-1760 https://markmail.org/message/tidlnyfivbr4xumj ========== 2) Currently I use jena-mvn-tools at version 3.6.0 (due for upgrade!) despite several bugs in the maven plugin implementation. I have used the jena-maven-tools in several past and current projects. I have a pragmatic interest in seeing jena-maven-tools continued and improved, or replaced with something better. Upon request I am happy to report what I know about the extant bugs (in the jena-maven-tools plugin). But as noted in 1A,1B,1C above, the jena-maven-tools are currently on their way out of the main jena codebase. So perhaps I will wind up fixing these bugs myself, in a fork, or...? Option 2A) I formally report the bugs, and we collaborate to get them fixed, resulting in an eventual pull request that re-establishes an improved version of jena-maven-tools. Option 2B) If the jena team prefers to be rid of this troublesome plugin, it may be best for me to publish a new artifact from one of my own projects. I could fork the code from jena-maven-tools, and eventually publish it somewhere. I am guessing it would take 6+ months, depending on how much support + interest we get from the community. As illustration of how I think about this tool, here is an example where we used a previous version of jena-maven-tools (0.8) together with 'rdf-reactor' (which is also falling into disuse by ... everyone but me?). https://app.assembla.com/spaces/cogchar/subversion/source/HEAD/trunk/maven/org.cogchar.lib.onto/pom.xml Option 2C) Perhaps there is some better way to organize build integration for jena-schemagen (or something similar) which I am not aware of. I do prefer to remain in the maven orbit, but if someone has a really snazzy config for some other build environment (like sbt or gradle or ...?), then I will be happy to hear about it, and maybe I can find a way to switch some of my builds to use it. (Not looking for a general discussion about build tools; just the specific experience with invoking jena-schemagen, or comparable alternatives, from these build environments). I am eager to hear any comments and suggestions from the jena-users community. peace, Stu
