CODEWITHSUNDEEP
antivy
David W.
David W.

Reputation: 107090

Ivy: Jar Required for Processing, but not Compiling

I have a project that depends upon two jars that are produced by us. I've placed those two jars in our repository, Ivy downloads them, and everything is fine with the compile and building the initial jar.

However, we have another jar that is an obfuscator we need to run against this jar. This is also in our repository, but it isn't needed for the compile. Instead, I simply run it as a program against the freshly built jar.

How should I classify this obfuscation jar's configuration? I can't say it's compile since it's not needed for the compilation. And, it shouldn't be in the runtime configuration either. That leaves us with provided, _optional, _master, or test.

I could create a special configuration for Jars that are required for building the software, but aren't required in the classpath, but I don't want to break our standard and create more than the basic configurations.

What's the best way to handle this?

Upvotes: 1

Views: 121

Answers (2)

oers
oers

Reputation: 18714

If you need this jar only for your build-process an inline retrieve will do the job! It will help you to retrieve artifacts without the need of an ivy file.
This is really useful for jars needed for tasks, that you execute but have nothing to do with the artifact per se (findbugs, etc ..).

<ivy:retrieve organisation="foo" module="bar" inline="true" pattern="${my.install.dir}/[artifact].[ext]"/>

Another alternative is an inline ivy cachepath, where the jar is taken from the cache directly and not retrieved to your project.

<ivy:cachepath
  organisation="org" module="module" 
  revision="latest.integration" 
  inline="true" pathid="project.compile.sourceprocessing.classpath"/>

Upvotes: 2

Mark O&#39;Connor
Mark O&#39;Connor

Reputation: 78021

Ivy configurations are designed to be flexible. Of course it makes perfect sense to standardize on the Maven scopes (especially when pulling from Maven repos) but I see no reason to limit your build, especially for dependencies only used by your build.

I typically create an extra configuration called "build" dedicated to pulling down items like ANT task jars:

<configurations>
   <conf name="compile"  description="Compile dependencies"/>
   <conf name="runtime"  description="Runtime dependencies" extends="compile"/>
   <conf name="test"     description="Test dependencies" extends="runtime"/>
   <conf name="provided" description="Dependencies provided by target platform"/>
   <conf name="build"    description="Dependencies used by ANT build process"/>
</configurations>

Upvotes: 2

Related Questions