I have written Maven plugins in the past and I had one project that used the schemagen plugin. I have not had the drive to maintain schemagen and so have never stepped forward on this topic, but if someone steps up to drive the maintenance I would be happy to contribute my knowledge and a bit of time, not htat hI have much spare time anymore.,
Claude On Thu, Nov 28, 2019 at 1:46 PM Andy Seaborne <[email protected]> wrote: > Hi Stu, > > jena-maven-tools has not been released since 3.6.0 because its tests > don't pass after the upgrade to the Apache parent POM v19 JENA-1474. > > schemagen itself is not affected - it's just the maven plugin. > > As you note, there hasn't been much interest and no one has stepped up > to fix and maintain it. All code needs maintenance, community discussion > and oversight. The environment changes, Java is now releasing to a > faster schedule, new users/uses are made so there is no such thing as > completed software. > > Sorry - that is the reality of open source software! > > If you or anyone else is willing to do that, it can be brought back but > the current active contributors. > > Or as 2B, fork it. > > Maybe there is a lighter weight way to provide the functionality just > invoking schemagen (might even be as "documentation" if using the exec > plugin). i.e. 2D - replace with a sustainable solution. > > 3.6.0 isn't going to be removed from either the archives of the Jena > release area - http://archive.apache.org/dist/jena/. Versions are never > removed or replaced. > > There are no plans to remove from central.maven.org either (which is run > by Sonatype). > > Andy > > > On 26/11/2019 08:32, Stu B22 wrote: > > > > 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 > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
