Andy Seaborne wrote: > On 23/09/11 13:21, Paolo Castagna wrote: >> >> >> Andy Seaborne wrote: >>> On 22/09/11 19:53, Paolo Castagna wrote: >>>> [email protected] wrote: >>>>> Modified: >>>>> >>>>> incubator/jena/Jena2/SDB/trunk/lib-src/arq-2.8.9-SNAPSHOT-sources.jar >>>>> >>>>> incubator/jena/Jena2/SDB/trunk/lib-src/arq-2.8.9-SNAPSHOT-test-sources.jar >>>>> >>>>> >>>>> incubator/jena/Jena2/SDB/trunk/lib/arq-2.8.9-SNAPSHOT-tests.jar >>>>> incubator/jena/Jena2/SDB/trunk/lib/arq-2.8.9-SNAPSHOT.jar >>>> >>>> I think we should drop these. >>> >>> And break SDB completely? >> >> No. Why? > > The development system relies on those jars as does the distribution. It > hasn't been changed to the new world order (ditto TDB).
I think we should remove those files and change the development system as well as the distribution in such a way that those files are not used (as you have done for ARQ, Fuseki, TxTDB and as it's the case for LARQ). I just want to know if it's just a matter of time or there are other reasons why those files should not go away. I am happy to fix this for SDB if we agree on removing those files. >> SDB latest release will be unaffected by the change. > > This keeps SDB development up-to-date with internal changes in ARQ. LARQ or Fuseki development are up-to-date with internal changes in ARQ without having the lib or lib-src directory, but simply depending on ARQ-x.y.z-SNAPSHOT. This is what the majority (if not all) projects using Maven do. > I prefer that to having to go back much later and remember how to carry > out all the changes. I agree. I am proposing to have SDB depending on ARQ latest SNAPSHOT and avoid having to manually update jars in the lib or lib-src directories. Manually == error prone (i.e. someone, soon or later, will forget to do that, or will do it wrong). Also, if you do not do it or forget... and the SNAPSHOT changes, you risk of not spotting problems. > >> SDB development version can choose to depend on ARQ latest stable release >> or ARQ latest SNAPSHOT. In this case if someone does something which >> would >> break SDB, Jenkins will spot it (and it will get fixed immediately... >> i.e. >> continuous integration (without manual intervention to update jars in the >> lib directory). > > ?? It did. > Yes, because we have two set of jars (a set is used by Maven and another set is used by Eclipse). This has caused me problems (more than once) when I was working on two different modules (one of which had this two set of jars). You publish a new SNAPSHOT, nothing breaks in Eclipse in the other module. But, it breaks Maven. >> >> I still think we should remove jars from the various modules. > > There is still a manual step, it is just moved to development - after > svn update, you would have to do a "mvn dependency:resolve > dependency:sources". > > I have ensured there is script, mvn-update, that does the right thing > for each module. I still think it's better to have Eclipse and Maven use the same set of jars. It avoids people making mistakes and ensure that what you see in Eclipse is always what you get with Maven from the command line and vice versa. At the moment the situation is: - ARQ --> 1 set of jars, no lib directory, .classpath points to M2_REPO - LARQ --> ditto - TxTDB --> ditto - Fuseki --> ditto While these modules are not there yet: - Jena2 --> 2 set of jars (one for Eclipse, one for Maven) - IRI - SDB - Eyeball - TDB I am in favor of bringing the situation for Jena2, IRI, SDB and Eyeball as it is right now for ARQ, LARQ, TxTDB and Fuseki. And I am ready to help (or do it) if we all agree it's a good thing. Paolo > >> >> Paolo >> >>> >>> Andy >>> > > Andy
