Closed josteinaj closed 9 years ago
I would prefer if the master branch only depended on released versions of dependencies. SNAPSHOTs are volatile and might unexpectedly break things.
That goes without saying.
It's not always easy to keep things nice and separate on many feature branches and wait for until it's safe to merge, if some of the features you're working on depend on each other, and when you're modifying the same files in different branches. Usually I'm quite disciplined regarding this, but it does require a lot of extra effort! This time I guess I wasn't careful enough, sorry :disappointed:
Banning all snapshot dependencies is a nice ideal but maybe not always realistic. No snapshot dependencies on stuff that is not on a master branch already seems reasonable, as long as updates of those dependencies don't break things too often. This condition should be met if the project we depend on (e.g. Braille Utils) has feature branches too. Related: https://github.com/snaekobbi/pipeline-mod-braille/issues/47.
I can't revert this particular snapshot dependency anymore unfortunately. So I guess we'll have to wait until @joeha480 is finished with the API changes in Braille Utils.
Also we should look at why Braille Utils doesn't build for you.
(PS: I use docker to build some project too. A tip is to use a Dockerfile, a docker-compose.yml file and a Makefile. Then it's no hassle at all.)
I am still working towards the first release with the new build structure, i.e. using maven artifacts. I asked Bert a few weeks ago if he needed the release soon, after that I concluded that I could go ahead with the api restructuring without publishing an intermediary release. I am sorry for the inconvenience.
To build braille utils you need JAVA_HOME set to jdk1.6 and also, since there are no released artifacts, you need to run the install tasks (not just the build tasks) and also in the correct order (api first, then impl, then BrailleUtils). Note that I am not yet using the multi project build in the root for this purpose. You should run the build.gradle files in each of the sub projects directly.
No wonder you can't build it! I totally understand. All I can say is that I am working on it. :-)
@joeha480 Yes you warned me, I should have known this would happen, it's totally my own fault.
I didn't mean it like that. I just wanted to mention that we talked about it, since I can't fix it right away. It seemed appropriate to explain that we knew that there could be problems for a while. Still, I want to fix it as soon as possible.
But I mean it! :)
(PS: I use docker to build some project too. A tip is to use a Dockerfile, a docker-compose.yml file and a Makefile. Then it's no hassle at all.)
Interesting. I'm familiar with Dockerfile
s but not docker-compose.yml
and I haven't written Makefiles from scratch in years.
I hope none of you mind if I wait until pipeline-mod-braille
s dependencies (i.e. Braille Utils) are sorted out until I continue work on the scripts? I'd rather work on some other tasks than spending time getting the build working locally.
@bertfrees: Ok, I'm back to the
org.daisy.braille.table does not exist
error I had earlier which was most likely due to depending on an unreleased version of brailleutils. I remember we got it working last week but when I tried today it wouldn't work anymore. Maybe maven pulled down some new SNAPSHOT release which breaks things, I'm not sure. I tried building brailleutils again as before but it didn't work this time. I need to build brailleutils through a docker image because my system gives an error otherwise (for unknown reasons), so it's a bit of a hassle building brailleutils.I would prefer if the master branch only depended on released versions of dependencies. SNAPSHOTs are volatile and might unexpectedly break things.