Christopher Hoskin <[email protected]> writes: > Dear Felix,
hello Christopher, > Another option would be for me to switch to using maven to build > batik. I've had a go at this here: > > https://anonscm.debian.org/cgit/pkg-java/batik.git/?h=maven-build > > In this case, batik-i18n and batik-constants are created as jars in > their own right under /usr/share/java rather than being bundled into > other jars. Upstream supports building with maven, although I presume > they are still using ant for their own binaries as they don't have > batik-i18n and batik-constants jars? Thank you for analyzing and fixing the issue with freeplane. I will fix this in the new release which is already in the pipeline. > I haven't uploaded the maven build as I don't know if this approach > might have a negative impact on other reverse dependencies expecting > the ant layout build? I would stick with the old (ant) build system, as this means much less work fixing the r-deps. But whatever you choose is ok for me. We still should test-build all r-deps to see whether they build though. >> batik-i18n gets included in the batic-util.jar, but the pom file for >> batic-util includes: >> >> <dependency> >> <groupId>${project.groupId}</groupId> >> <artifactId>batik-constants</artifactId> >> <version>${project.version}</version> >> </dependency> >> <dependency> >> <groupId>${project.groupId}</groupId> >> <artifactId>batik-i18n</artifactId> >> <version>${project.version}</version> >> </dependency> >> >> So my first thought is that this is a problem with the upstream pom files. >> >> If I comment out these dependencies and add jython to the build >> dependencies for freeplane, then the freeplane package builds okay. Do the people on d-java agree that this is a good solution? It seems good to me. One suggestion: If you update a library, it would be good to test whether any r-dep fails to build. There are not many for the case of batik. Cheers and Best Regards, -- Felix Natter debian/rules!
