On Mon, Nov 04, 2013 at 09:18:34AM +0000, Russel Winder wrote: > Whilst this may a priori be a failure of the Debian packaging rules, the > situation stems from the fact that GPars used to be a totally separate > thing from Groovy, but now the Groovy distribution includes and relies > on GPars even though it is has a separate development line. I argue that > the Debian package strategy may well be the underlying problem here > because it does not allow multiple versions of artefacts as is standard > practice in the JVM-verse. > > Whilst libgpars-groovy-java used to be a good idea, the gpars artefact > should be an integral part of the groovy package from Groovy 2.0 > onwards.
Here we disagree. I think it's perfectly reasonable to have a GPars in a package separated from Groovy. Maybe somebody could want to use GPars with a pure Java application, or in a Scala project, Clojure, etc. You should not have to install GPars along with Groovy, but of course Groovy is going to recommend GPars because enhances it. > Also worth noting that GPars 0.10 is ancient, we are now at 1.1 and > wondering when to release 1.2. That's right and that's why I decided to upload Groovy 2.1.x. I want to update all Groovy libraries so we can have up-to-date libraries in the next stable release. As we already discussed in another email thread, GPars also migrated to Gradle as build tool. So, to update GPars I see two options right now: * I wait until Gradle is based in Groovy 2.x. * I build GPars with another tool (this was already done in the past with Ant but I don't know if I have the time to review that again). Cheers, -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x6E608B637D8967E9 available at http://keyserver.pgp.com/ "Faith means not wanting to know what is true." -- Nietzsche
signature.asc
Description: Digital signature
