Automatically adding the test class can cause duplicate class problems

[tevans78]

Automatically adding the test class to the application archive can result in duplicate classes within the application. In some cases, such as when the test class contains CDI beans, having duplicate classes within the same application causes deployment errors.

arquillian-core/container/test-impl-base/src/main/java/org/jboss/arquillian/container/test/impl/client/deployment/DeploymentGenerator.java

Line 171 in 31fd0ee

classContainer.addClass(testCase.getJavaClass());

[bartoszmajsak]

Thanks @tevans78 for reporting it. Would you be so kind and provide reproducer to ask? This will help us work on the fix.

I don't dare to ask you to deliver an actual patch, but if you could that would be more than awesome. You can obviously count on our help!

[tevans78]

@bartoszmajsak bit tricky to provide a standalone test case that you can easily run but I can refer you to the microprofile tck code where we found the problem
https://github.com/eclipse/microprofile-config/blob/f8782a9fc6f5fc3d7b31b8e8a34fed47a472e136/tck/src/main/java/org/eclipse/microprofile/config/tck/ClassConverterTest.java#L55

The test uses shrinkwrap to create a war with a jar inside. If you look at line 55, you can see two classes being added to the jar .addClasses(ClassConverterBean.class, ClassConverterTest.class). The problem is that ClassConverterBean.class is a CDI bean, nested inside the test class, ClassConverterTest.class, line 94.

When arquillian adds the test class into the application archive (war) as well, we end up with the test class and it's CDI bean in two places inside the war. This leads to CDI bean resolution errors.

There is a work-around, to not nest the CDI bean inside the test class, but that isn't always ideal.

[hutchig]

This also occurred here - eclipse/microprofile-config#145

[spyrkob]

@bartoszmajsak don't know if it's still useful but here's a simple reproducer: https://github.com/spyrkob/test

Looking at the DeploymentGenerator maybe the solution would be to check if the test class is already in one of embedded archives? Something like master...spyrkob:issue-157 (very hacky;))