CODEWITHSUNDEEP
apacheconfigurationivy
IAmYourFaja
IAmYourFaja

Reputation: 56944

Apache Ivy Configurations

I'm slowly beginning to understand the importance of module configurations within the Ivy universe. However it is still difficult for me to clearly see how the same chunk of code could have different configurations that have different dependency requirements (the one exception is in the case of test configs that require JUnit on top of the normal dependencies -- I actually understand that 100%!)

For instance, take the following code:

package org.myorg.myprogram.core;

// Import an object from a dependency
import org.someElse.theirJAR.Widget;

public class MyCode
{
    public MyCode()
    {
        if(Widget.SOME_STATIC == 3)
            System.out.println("Fizz");
        else
            System.out.println("Buzz");
    }
}

Now aside from the fact that this is terrible code, I just don't see how my program (which, let's pretend is JARred up into MyProgram.jar) could be set to have multiple "configurations"; some of which may require theirJAR and its Widget class, and others that don't. To me, if we fail to provide MyCode with a Widget it will die at runtime, always.

Again, I understand the necessity for test configurations; just not anything else (I have also asked questions about compile- vs run-time dependencies, and I guess I also see the necessity for those as well). But beyond test configs, compile-time configs, and runtime configs, what other module configurations could you possibly need? How would MyCode need a Widget in some cases, and not in other cases, yet still run perfectly fine without a Widget?

I greatly appreciate any help wrapping my brain around this!

Upvotes: 1

Views: 581

Answers (3)

Mark O'Connor
Mark O'Connor

Reputation: 78021

You might also want to use configurations to control the contents of different distributions. For example you might want to release the jar on it's own ("master" configuration in Maven parlance) and additionally build a tar package containing all runtime dependencies, with (or without) source code.

Another use for configurations is when you target multiple platforms. I often release groovy scripts packaged to run as standalone jars or as tomcat web applications

Upvotes: 1

Sam T.
Sam T.

Reputation: 497

To add to SteveD's answer, remember that dependencies can be more than just .jar files. Some dependencies come with source and javadoc files, release notes, license files, etc. Multiple configurations of the dependency might let you select the subset of files you wish to resolve.

Upvotes: 1

SteveD
SteveD

Reputation: 5405

Hibernate is a good example. Hibernate supports multiple cache implementations to act as its level-2 cache. You don't want to transitively depend on all the possible caches, only the one you use.

In general, we use the typical compile, test, runtime set of configurations.

Upvotes: 2

Related Questions