Re: libbatik-java: Changed artifacts?
Christopher Hoskin <mans0954@debian.org> 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!
Reply to: