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
