You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by sh...@yahoo.com.INVALID on 2016/11/14 17:28:09 UTC

How can I workaround non-standard packaging types?

I'm trying to convert a maven build over to use SBT for better parallelism of a very large set of submodules, among other reasons.  SBT, as you may know uses Ivy as its dependency resolution engine.  Maven's dependency resolution seems to have been a little more forgiving about consistency of poms and there are a few things I need to work around to use our existing set of dependencies.
First, for consistency, I've had good luck using the IBiblioResolver to turn off consistency checks, so that's not an issue any longer.
However, the place where I just can't seem to find a reasonable workaround is this - several of the dependencies' poms declare <packaging>container-plugin</packaging> but deliver themselves as a .jar - how can I force the extension (if not also type) to be jar in a way that plays nice with the ivy cache?  Here are some of the things I've tried:
   
   - Subclass IBiblioResolver and adjust the ext and type in an overridden download method   
*** Fails because the cache still looks for container-plugins/artifact-version.container-plugin
   - Subclass IBiblioResolver and adjust only the ext in an overridden download method, and also make a hardlink between artifact-version.container-plugin and artifact-version.jar   
*** Fails to compile because the classPath will choose the .container-plugin and not get its classes
   - Number 2 + add rule that links any container-plugin from a location in ./lib/ so that the jars are included    
*** Actually seems to work, but is completely DISGUSTING and makes every subproject include every container-plugin that has been downloaded at that point in build.
   - Use reflection to force PomModuleDescriptorBuilder.JAR_PACKAGINGS to include "container-plugin"   
*** Successfully downloads, but then fails with NullPointerException in some caching layer of SBT:    
at sbinary.JavaUTF$StringFormat$.writes(javaprotocol.scala:156)   
...   
at sbt.Classpaths$.cachedUpdate(Defaults.scala:1493)

So, I thought I'd reach out to the community - is there a better way to configure things to rewrite the packaging of "container-plugin" to be treated like "jar" in all aspects?  Can I maybe register a ModuleDescriptorParser to or some settings that cause the substitute of the type and/or ext to be "jar"?  I'm certainly open to trying anything, and hoping for some guidance from the community as to what has the most chance of both success and lack of hackery, if not elegance.
Thanks for any help you can lend!
-SCR