Custom/invalid ivy.xml parsing


(Daniel) #1

Hi,

I work in a corporate environment which has a lot of ‘customized’ stuff, specially ivy.xml for internal artifacts.
I’m trying to migrate a project from its ivy/ant build to a gradle (3.0) one, but the dependency resolution for internal artifacts is not working properly. I get errors like

Could not resolve xx:yyyyy:1.0.
Could not parse Ivy file http://internalArtifactory.com/maven-repos/xx/yyyyy/ivy-1.0.xml
xml parsing: ivy-1.0.xml:3:161: cvc-complex-type.3.2.2: Attribute ‘build’ is not allowed to appear in element ‘info’. in http://internalArtifactory.com/maven-repos/xx/yyyyy/ivy-1.0.xml

It seems that in early versions of gradle we could use this approach to workaround (Get XML parsing error on Ivy file after upgrading from gradle 1.7) but it has been deprecated.

Is there any way to make the dependency resolution work with these ‘enriched’ ivy.xml files?

Below is what I found about the subject and tries so far.

Currently I disabled the ivy.xml for these artifacts and manually copied the transitive deps from those broken xmls to my gradle files, so it is working. But this isn’t sustainable, of course.

I’ve seem some suggestions on spinning up a new dependency repository with fixed ivy.xml files, but given my environment, this could take a really long time, so I’m looking for local alternatives.

I’ve also tried using DependencyResolutionListener to, after the version is resolved, parse the ivy.xml and add the dependencies on it, but you can’t add deps to a config after it is already resolved (and I need the resolution to happen first to get the correct version)

There’s a “resolve” property on IvyArtifactRepository that seems to be related to what I need by the description, but since it is read only, I’m not sure if it can help in this case.

Regards,
Rodrigo


(Daniel) #2

Worked a little on this again today, so ended up doing a (ridiculously ugly) workaround:
1 - Disabled the ivy.xml retrieval for those problematic libs (thankfully they are all on the same group and artifactory)
2 - Created a task that resolved the ‘compile’ configuration, iterates over the results and process those declared dependencies that belong to that problematic group
3 - For each problematic first-level dependency, it downloads the ivy.xml and extracts the dependencies from it, and then add those dependencies into a new configuration (since compile is already resolved and can’t be changed)
4 - Add all declared first-level dependencies and the new found transitive dependencies on this same new configuration
5 - Change the classpath of all tasks (compile, compileTestJava, etc) to use this new config instead of the default

It worked, but IntelliJ doesn’t perceive those ‘dynamically resolved configuration’, so it doesn’t include the transitive deps on its workspace classpath.

At least the command line is working, I guess :stuck_out_tongue: