+1 bump. A similar question was asked a year ago, also with no replies. Surely this must be a common requirement?

Hey guys,

I wouldn't really say it's ShrinkWrap problem per se, as Java basically takes everything under the same classpath... and since we are operating on the class level we are missing this very information from which module classes are comming from. In my humble opinion the best approach would be to simply put your integration tests in different project module and use different namespaces (e.g. package with .test. somewhere), but I understand that this might not be really applicable for all the cases as it always adds some more complexity to the structure, resources files re-use etc.

Anyways, going back to the merrit - since maven compiler puts prod and test classes in dedicated folders, we can leverage that and apply not so perfect, but working approach:

{code:java}
ShrinkWrap.create(JavaArchive.class, "test.jar")
                .as(ExplodedImporter.class)
                .importDirectory("./target/classes/com/acme/product/synchronization/job/")
                .as(JavaArchive.class);
 
{code}

You can always merge such jar with your real test archive if necessary.

Not sure if there is any additional filtering besides class name matching though (as pointed out by shonkylogic). Could be interesting case for feature request. Maybe we should raise it on ShrinkWrap Dev forum?

HTH

Wondering if we could use Class.getProtectionDomain().getCodeSource().getLocation() for something useful here.

It's good to learn sth every now and then This should work with Maven way of packaging things. I will raise this concern on ShrinkWrap dev forum right away.