For the release after 2.7.4, I wonder if it's a good time to do a single
jar of Jena for normal use - that would bump the version more than
incremental so sync the version numbers of IRI/core/ARQ/TDB and make it
"2.10.0", if the jump isn't going to get too confusing, else 2.8.0.
Q: Is this the right time to do this?
Q: 2.8.0 or 2.10.0
The jar is then "jena-2.10.0.jar"
Q: Is the name right?
module jena is something to be cautious about as we get to use it once
but this seems a good use "jena-sys", "jena-all", ...
There would still be a distribution "apache-jena" with dependent jars.
The advantage is that it separates the release structure from the
codebase module structure. When the single jar is the normal mode of
use, we have scope to reorganise the codebase without disturbing
applications.
It's simpler to use as well but people would still include the
additional jars or we create problems over multiple instances and
minor/incremental versioning. [dependencies]
I have mocked up a one-jar builder that avoids problems of the shade
plugin (which lowercases some file names ... like NOTICE) and with
simply combining dependencies (vast amount "warning" messages about
duplicates).
The javadoc would be combined as well - modulo getting the goal to
trigger properly if it's not in a JAR module, I have managed to produced
combined javadoc.
Andy
[dependencies]
FYI:
apache-jena
commons-codec
httpcore, httpclient
Xerces, xml-apis
slf4j-api, slf4j-log4j12, log4j
and for Fuseki,
jetty, jcl-over-slf4j, velocity
commons-collection, commons-lang, commons-fileupload,
