search

drlivingston / kr

Clojure API for RDF and SPARQL - provides consistent access to APIs including Jena and Sesame
56 stars 17 forks source link

Create lein projects, bump dependency versions #12

Open mgaare opened 10 years ago

mgaare commented 10 years ago

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 commented 10 years ago

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 commented 9 years ago

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 https://github.com/drlivingston/kr/pull/12#issuecomment-58712601.

drlivingston commented 9 years ago

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 commented 9 years ago

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 https://github.com/drlivingston/kr/pull/12#issuecomment-60843703.