mvn install -pl with -am/-amd usage

mvn install -pl with -am/-amd is very powerful. I first came to know about this usage in this article.

One use case that I can think of is this. Assume we are making changes in project D. It depends on projects E, F, G, & H. Now assume we have done update of our local codebase from repo and it caused changes in all of the projects in our local codebase (to keep our scenario simple). Now to build project D, we can run "mvn install -pl <groupId:artifactId of project D> -am" which will make sure maven runs the E, F, G & H first before running our target project D.

-amd option is useful in the following scenario. Assume project X is where we are making changes and project A, B, C depend on X. Now we are making changes in project X, and we want to check whether project A, B, C are still compiling fine. Now we can run "mvn install -pl <groupId:artifactId of project X> -amd" which will do the job. 

These commands has to be run from the root of the code repo (or ... which I leave it as an exercise. It has something to do with lowest common denominator).

Junit and TestNG - An important difference to be noted

Assume the tests are run sequentially to keep things simple. Have a look at the following code:

a) Using Junit

import java.util.ArrayList;
import java.util.List;

import org.junit.Before;
import org.junit.Test;

public class JunitExample
{
    private List<Integer> ints = new ArrayList<>();
   
    @Before
    public void initialize()
    {
        ints.add(1);
        ints.add(2);
        ints.add(3);
    }

    @Test
    public void test1()
    {
        ints.add(4);
        System.out.println(ints);
    }
   
    @Test
    public void test2()
    {
        ints.add(5);
        System.out.println(ints);
    }
}

Running the tests sequentially outputs
[1, 2, 3, 4]
[1, 2, 3, 5]

b) Using TestNG

import java.util.ArrayList;
import java.util.List;

import org.testng.annotations.BeforeTest;
import org.testng.annotations.Test;


public class TestNGExample
{
    private List<Integer> ints = new ArrayList<>();
   
    @BeforeTest
    public void initialize()
    {
        ints.add(1);
        ints.add(2);
        ints.add(3);
    }

    @Test
    public void test1()
    {
        ints.add(4);
        System.out.println(ints);
    }
   
    @Test
    public void test2()
    {
        ints.add(4);
        System.out.println(ints);
    }
}

This outputs,
[1, 2, 3, 4]
[1, 2, 3, 4, 4]

Surprised?. This is because Junit creates a separate instance of test class for each and every tests that are present. When test1 begins to gets executed ints consisted of [1, 2, 3] and when test2 begins to gets executed too it consisted of [1, 2, 3]. No surprises here. We ended up with [1, 2, 3, 4] on both these cases.

But in case of TestNG, there is only one instance of test class that gets created and that will be used by all test methods. So, before test1 got executed, ints were [1, 2, 3] and by the time test1 got completed, ints were [1, 2, 3, 4]. Now when test2 begins to get executed ints are already [1, 2, 3, 4] and we add up 4 again to ints. So, finally we ended up with [1, 2, 3, 4, 4].

When the tests are run in parallel, in case of TestNG, the behavior is undefined if instance variables are used without considering multithreading scenarios.

svn checkout and update --depth/--set-depth option usage

Assume you have a project structure as this: You have a core-spoke model. The spokes depend on core piece. Different teams of developers are working with different sets of core and spoke projects. You have this project in SVN repository.

CodebaseRoot -> Core
                          -> Core1
                          -> Core2
                          -> .........
                          -> Core k
                       -> Spoke
                          -> Spoke1
                          -> Spoke2
                          -> ..........
                          -> Spoke n

Where each spoke component is dependent on some/all of the core components.

Assume this is a large codebase and you might need to work only with subset of spoke and core components. You need not checkout the whole codebase.

Selectively checking out the codebase can be done using the following steps: Be under the directory where you want to check out the code.

a) Run svn co --depth=immediates at <CodebaseRootURL>
    Now you have a local copy containing only Core and Spoke empty directories.

b) Run cd Core. Then run svn up --set-depth=infinity with <CodebaseRoot>/Core URL.
    This will checkout the core code piece completely. You can selectively checkout  too. For now let us assume that our spoke projects depend on all core pieces.

c) Run cd ../Spoke. Then run svn up --set-depth=immediates with <CodeBaseRoot>/Spoke URL. Now the set-depth=immediates option is used as this will checkout empty directories of all spoke directories.

d) Assume you are working only in project Spoke m. Run cd Spoke m. Then run svn up --set-depth=infinity with <CodeBaseRoot>/Spoke/Spoke m URL. This will checkout the whole spoke m project.

Hopefully this helps.