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
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.
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.
I just encountered the same problem today with Gradle 1.12! All of our locally-generated ivy.xml files contain the “build” attribute, but Gradle only chokes on a handful of them, the rest seem fine. Did you ever come up with a better solution that the ugly workaround?
I also posted another query today indicating that, though a google guava jar was mentioned 14 times in the debug log, it was not downloaded and added to the CLASSPATH, resulting in a compilation error.
The point is, unless you got a private response (which I have not yet gotten), it seems that the folks at Gradle are not monitoring this Forum, or at least not as well as I would expect. If not, what’s the point of it?
This is the Gradle Community Forum. Gradle developers might respond some of the time, but it is not an official support channel. You may get a response from a member of the community, if they’ve experienced the problem, or they’re interested in doing some research to figure out what is going on. Just like StackOverflow, the easier you make it to reproduce your problem, the more likely someone will spend their free time trying to help out. However, it’s never guaranteed that a member of the community is willing to do that or that the response is prompt.
I do understand that, thanks, just not sure how else to get some insights my issue, was wondering if the fellow got a private response with information as to how to address his issue.
Unfortunately, I didn’t get any insight or private messages on that issue.
I don’t remember what became of it either, sorry
Do note that we worked at the same company at the time this was posted (aug 2017), so whatever I did you may have more access to it than I (if you still working there)
That is hilarious, I thought your name sounded familiar. Yes, still here, still fighting the good (?) fight, probably encountering the same issue you did with the same body of code. Yes, I’m having a terrible time trying to get some help on some of this stuff, though I did find another post that worked around the issue you brought up by using a URLResolver with “validate=false” instead of the native ivy{} block, so I’m kicking that a bit.
Hope all is well in your world, what are you up to these days?
