On 23/09/11 15:16, Paolo Castagna wrote:
This is a good example of continuous integration in action.
I want to briefly comment on this, since it's in topic with my previous
suggestion to remove jar files from the lib and lib-src directories.
Building SDB from the POM file use dependencies.
Jenkins builds via maven so it's picking up changes anyway. Why does the
JAR files make any difference?
The jars are for Eclipse and which ever way round you do it, there is
separate step for Eclipse. Its just a question of who has to do it -
the person making the changes (who is likely to understand the process)
or all the people who only download from SVN and look at the code in
Eclipse and now MUST have maven.
> I saw this message. The cause is that a method has been removed from
the Binding interface (see: JENA-121):
http://svn.apache.org/viewvc/incubator/jena/Jena2/ARQ/trunk/src/com/hp/hpl/jena/sparql/engine/binding/Binding.java?r1=1174251&r2=1174250&pathrev=1174251
That change is perfectly fine and I was aware of that change because
I saw the notifications. When LARQ failed, without nobody working on
it, it's was obvious the reason was that change.
A quick and easy fix. Done.
No communication needed between me and who is doing the change on JENA-121.
ARQ (development) and LARQ (development) are back in sync.
I didn't break LARQ - I took the time and uploaded a patch for LARQ
(JENA-122).
We could have delayed or postponed this to a later point in time.
What's the difference? We lose the context.
Someone can make a change to a module and not even realize his change
will break things somewhere else. This is why CI systems such as Jenkins
are really helpful and useful.
Is anyone saying they are not?
For this particular change, which is trivial, losing context is not that
important. For other situations I think it's much better spotting problems
earlier than later (for example when you need to upgrade dependencies, etc.)
My 2 cents,
Paolo
Andy
