Create lein projects, bump dependency versions

[mgaare]

For my own work, I found it helpful to create Leiningen projects for KR. I discovered some rather old dependencies in KR while doing this, so I went ahead and bumped those. Somewhat poor form to do both of these things in a single PR, admittedly. My apologies for that.

Submitting this as a PR in case it is of some use.

Note: if you use any pom-generating lein tasks - install, deploy, etc - it will overwrite the existing poms.

[drlivingston]

Hi Michael,

Thanks for taking interest in KR and being willing to do some maintenance work. I really appreciate it.

Thanks for donating the patch, it might take me a little bit to understand it, please bear with me.

I thought lein works fine with maven packages too (making maven the least common denominator), but admittedly I don't use lein much (at all?), could you help me understand what lein-ifying the library enables for you?

My one potential concern here is that there is a workflow baked into the pom using the release plugin, which has been a very stable way for me to move the version numbers of all the pieces together and push the jars to clojars. If there are lein project files they would then have to be manually adjusted? (and are the versions of the dependencies different between the project and the pom files currently?)

Do you have a list of the dependencies that you found that were out of date handy? I started to spot check for them, but there's a fair number of them...

Thanks again,
Kevin

[mgaare]

Hi Kevin,

Here are the versions that I bumped:
org.clojure/clojure "1.4.0" => "1.6.0"
org.clojure/java.classpath "0.1.0" => "0.2.2"
org.openrdf.sesame/sesame-runtime "2.6.10" => "2.7.13"
org.openrdf.sesame/sesame-queryresultio "2.6.10" => "2.7.13"
org.openrdf.sesame/sesame-queryresultio-binary "2.6.10" => "2.7.13"
org.apache.jena/jena-arq "2.10.1" => "2.12.1"

I also added the dep org.openrdf.sesame/sesame-queryresultio-sparqlxml
"2.7.13"

You're correct that you bring in KR as a dependency in Leiningen projects
easily.

The reason I created Leiningen projects was because I needed to bump a few
of these dependencies for my own usage, and I just much prefer working with
Leiningen to working with maven. Dealing with xml files makes me sad.

You're also right that out-of-the box maven has better support for
multi-module projects than Leiningen, particularly when you want to have a
master set of dependency versions that the child projects inherit. I
addressed this problem by using the lein-parent plugin in the sub-projects,
which lets you merge in parts of a parent project file, and the lein-sub
plugin in the parent project. The result is that all the dependencies are
specified in the top-level project.clj, and the sub-projects inherit only
the ones they specify.

One problem I didn't address was the versioning of the subprojects, which
at the moment is done by hand.

To be honest, I'm not sure that I'd merge this push. It would result in a
workflow change for you, and other than my own distaste for using maven
there's not a clear benefit.

I may have some other PRs for you dealing with the main project
functionality in the future.

Regards,
Michael

On Fri, Oct 10, 2014 at 4:34 PM, Kevin Livingston notifications@github.com
wrote:

Hi Michael,

Thanks for taking interest in KR and being willing to do some maintenance
work. I really appreciate it.

Thanks for donating the patch, it might take me a little bit to understand
it, please bear with me.

I thought lein works fine with maven packages too (making maven the least
common denominator), but admittedly I don't use lein much (at all?), could
you help me understand what lein-ifying the library enables for you?

My one potential concern here is that there is a workflow baked into the
pom using the release plugin, which has been a very stable way for me to
move the version numbers of all the pieces together and push the jars to
clojars. If there are lein project files they would then have to be
manually adjusted? (and are the versions of the dependencies different
between the project and the pom files currently?)

Do you have a list of the dependencies that you found that were out of
date handy? I started to spot check for them, but there's a fair number of
them...

Thanks again,
Kevin

—
Reply to this email directly or view it on GitHub
#12 (comment).

[drlivingston]

Sorry this sat for a minute. I've been pondering how best to do some of these upgrades. Some are discussed in issues / bug reports. On problem with Sesame is the jumping to 2.7 breaks some things when someone has only a 2.6 triplestore to talk to. There is no function difference with the KR library. I think I just need to bump it and then maintain a legacy one. It'd be nice if KR could have a 2.7 and a 2.6 sesame branch - but I'm not quite sure how to get them to share code that requires Sesame code to compile. As the vast majority of code shouldn't need to change.

There some legacy code that relies on old classpath behavior to read the CP, I need to update that to make it behave correctly.

I wonder if for the others I should just declare open-ended dpendencies. The clojure 1.4 shoudn't be a problem it was just compiled under an older one, but these could all be defined in Maven to say at least version 1.4 but newer is fine too. I think if your pom asks for 1.6 with the current KR also in the dependencies Maven is just smart enough to bring in only 1.4, right? (or does it bring in both but bring 1.6 first so it is preferred?)

Thanks for your help and interest. And given your comments on build flow etc. and version numbers, I'm disinclined to merge this, and since you are less certain of it's value. But we should definitely take some of these version numbers seriously and try to get this cleaned up.

Thanks!

[mgaare]

My experience is with Leiningen, so I'm not certain that all of this holds
true with Maven. I suspect it does.

For people who need Sesame 2.6, they can exclude the Sesame libraries from
kr-sesame as part of the dependency specification. In Leiningen, that would
look like:
[edu.ucdenver.ccp/kr-sesame "1.4.19" :exclusions
[org.openrdf.sesame/sesame-runtime org.openrdf.sesame/sesame-queryresultio
org.openrdf.sesame/sesame-queryresultio-sparqlxml
org.openrdf.sesame/sesame-queryresultio-binary]]

Then elsewhere they explicitly specify their Sesame dependency, or bring it
in via their tuplestore dependency, or however.

My understanding is that when you have multiple versions of a given
dependency in the dependency tree, the one specified first wins.

On Tue, Oct 28, 2014 at 6:33 PM, Kevin Livingston notifications@github.com
wrote:

Sorry this sat for a minute. I've been pondering how best to do some of
these upgrades. Some are discussed in issues / bug reports. On problem with
Sesame is the jumping to 2.7 breaks some things when someone has only a 2.6
triplestore to talk to. There is no function difference with the KR
library. I think I just need to bump it and then maintain a legacy one.
It'd be nice if KR could have a 2.7 and a 2.6 sesame branch - but I'm not
quite sure how to get them to share code that requires Sesame code to
compile. As the vast majority of code shouldn't need to change.

There some legacy code that relies on old classpath behavior to read the
CP, I need to update that to make it behave correctly.

I wonder if for the others I should just declare open-ended dpendencies.
The clojure 1.4 shoudn't be a problem it was just compiled under an older
one, but these could all be defined in Maven to say at least version 1.4
but newer is fine too. I think if your pom asks for 1.6 with the current KR
also in the dependencies Maven is just smart enough to bring in only 1.4,
right? (or does it bring in both but bring 1.6 first so it is preferred?)

Thanks for your help and interest. And given your comments on build flow
etc. and version numbers, I'm disinclined to merge this, and since you are
less certain of it's value. But we should definitely take some of these
version numbers seriously and try to get this cleaned up.

Thanks!

—
Reply to this email directly or view it on GitHub
#12 (comment).