Is anyone looking at ways to integrate Ivy more fully into Fedora? I ask because I'm working on packaging sbt[1], which uses Ivy for dependency management; my current approach involves patching sbt to ignore Ivy descriptor files (so it can build with RPM-managed dependencies), but this feels suboptimal and results in some other headaches. So if you're working on Ivy in Fedora (or if you're interested in talking about sbt in Fedora), I'd like to hear from you!
thanks, wb
[1] see http://chapeau.freevariable.com/2013/08/making-fedora-a-better-place-for-sca... for a discussion of what this involves
On 08/06/2013 08:26 PM, Will Benton wrote:
Is anyone looking at ways to integrate Ivy more fully into Fedora? I ask because I'm working on packaging sbt[1], which uses Ivy for dependency management; my current approach involves patching sbt to ignore Ivy descriptor files (so it can build with RPM-managed dependencies), but this feels suboptimal and results in some other headaches. So if you're working on Ivy in Fedora (or if you're interested in talking about sbt in Fedora), I'd like to hear from you!
I haven't actually tested how reliable it is, but the ant task `ivy:convertpom' can be used to convert a pom.xml file into an ivy.xml file. This can be done automatically, thus instantly giving every package ivy support.
I am not convinced that the fact that sbt requires the ivy.xml file to be present is not a bug. That should be taken up with upstream. For example, gradle also uses ivy internally, but it doesn't require the ivy.xml file and so it can be used without patching the resolver code, so I don't think that it's an issue with ivy itself. Rather, it appears to be hardcoded in the sbt code with no option to disable it.
One obvious concern is that since dependency information is not available, the build may fail. But it's a lot easier to add a dependency or two to the build file than to patch the code, especially since every major Java build tool (save for ant, and especially sbt) has a horrible circular dependency on itself and the bootstrap binaries are generally not able to be patched.
----- Original Message -----
From: "David Walluck" david@zarb.org To: java-devel@lists.fedoraproject.org Sent: Tuesday, August 6, 2013 8:19:55 PM Subject: Re: [fedora-java] Ivy integration
On 08/06/2013 08:26 PM, Will Benton wrote:
Is anyone looking at ways to integrate Ivy more fully into Fedora? I ask because I'm working on packaging sbt[1], which uses Ivy for dependency management; my current approach involves patching sbt to ignore Ivy descriptor files (so it can build with RPM-managed dependencies), but this feels suboptimal and results in some other headaches. So if you're working on Ivy in Fedora (or if you're interested in talking about sbt in Fedora), I'd like to hear from you!
I haven't actually tested how reliable it is, but the ant task `ivy:convertpom' can be used to convert a pom.xml file into an ivy.xml file. This can be done automatically, thus instantly giving every package ivy support.
This is interesting; thanks! How much of an effort would it be to generate Ivy metadata for every Java package in Fedora? (I agree that having better metadata in Fedora is the best way forward.)
I am not convinced that the fact that sbt requires the ivy.xml file to be present is not a bug. That should be taken up with upstream. For example, gradle also uses ivy internally, but it doesn't require the ivy.xml file and so it can be used without patching the resolver code, so I don't think that it's an issue with ivy itself. Rather, it appears to be hardcoded in the sbt code with no option to disable it.
Yes, this behavior is intentional, although it looks like upstream might be willing to accept a patch adding a setting to make descriptor files optional (as they are by default in Ivy):
https://groups.google.com/forum/?fromgroups#!searchin/simple-build-tool/ivy/...
I have such a patch but haven't submitted it upstream yet; I will after I get a bootstrapped package built.
best, wb
On 08/07/2013 09:47 AM, Will Benton wrote:
This is interesting; thanks! How much of an effort would it be to generate Ivy metadata for every Java package in Fedora? (I agree that having better metadata in Fedora is the best way forward.)
My guess would be that it can be added to the %add_maven_depmap macro. I am not sure if official ivy.xml files exist as they do in maven central. Another argument for auto-conversion is that the ivy.xml files will pick up any changes or patches made the the pom.xml file automatically. Otherwise, it's going to require ivy.xml files to be added as a Source and sometimes patched by hand.
If you want to test how will the automatic conversion works, I would just create a build.xml and script that will convert all your poms in your build root and then point sbt to this and see how well it works.
I have been looking at a more general method that could take a Fedora-style layout and create the proper maven and ivy layout on the fly, say, in /var. At least this is the best option unless Fedora adopts this as a goal and adds the support directly to every package.
https://groups.google.com/forum/?fromgroups#!searchin/simple-build-tool/ivy/...
I have such a patch but haven't submitted it upstream yet; I will after I get a bootstrapped package built.
Thanks. A workaround is partially described there. Apparently, there's a way to override this behavior with a settings file, which hopefully means that you only need to bootstrap once. Otherwise, you'd have to go through a two-step bootstrap process. The first step would use the normal online build to produce a patched sbt, and then the second step would bootstrap with the patched sbt.
Upstream apparently wants everyone to require an ``real'' ivy repository. This will also disallow flat files which is what my main use case was when I ran across this issue myself. In gradle, there's a separate resolver built on top of ivy for flat dir layouts. Obviously, flat dirs are neither a maven nor ivy repo and so it should be expected that there would be no ivy.xml files present there. In fact, the default ivy.xml name means that it's ill-suited for a flat layout. At least the maven pom names are unique.
java-devel@lists.fedoraproject.org
-
David Walluck -
Will Benton