Andy Seaborne wrote: > 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.
Asking people who want to compile or test or develop to use Maven does not seem to me a bad thing. At the end of the day our CI system is using Maven (not Eclipse) and when we build releases or artifacts we use Maven (not Eclipse). Once you have Maven to manage your project, it is a bad practice IMHO to have jar files in your lib and lib-src directories. It creates two views on your software (command line != IDE) and those two views might diverge for all sort of reasons. Personally, I prefer the approach followed by ARQ, Fuseki, TxTDB and LARQ. I am also in favor of a consistent approach across our modules. Consistency helps people who are new to the project. I do not know any other open source project who adopt the same approach of Jena2, IRI, SDB, etc.: jars in the lib directory + use of Maven to manage dependencies. Do you know any? Diverging from what people might expect will require explaining them why we diverged and help them to understand something they might not have seen elsewhere. As I said, having two set of jars caused me problems more than once when I was making changes to two or more modules. The two sets might diverge. > >> 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). It did (and I think it is a *good* thing, since CI systems are there for this as well, "continuously" checking different modules work together): https://builds.apache.org/view/G-L/view/Jena/job/Jena_LARQ/194/ LARQ depends on ARQ-2.8.9-SNAPSHOT. If a change is made to ARQ which has an effect on LARQ, LARQ will fail as soon as an ARQ-2.8.9-SNAPSHOT is published. All this is *good*. I've never said or proposed to change this. By the way, thanks for the patch (I was faster, this time) for those small changes it takes more time to write the JIRA issue and submit the patch than fixing the source code directly. Fixing the code directly is my favorite option, since I might not involve me and there should be no boundaries/barriers between modules, nor strict rules or mapping between "software module" and "person". >From a point of view of communication, I see (and review) all the changes anyway, via the notifications via email which we all receive. :-) Paolo > >> 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
