Re: [fedora-java] Ivy integration
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/i...
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.