If you want to add your classes (or any other resources) to your ShrinkWrap archive to a non-root location, you can use the following:

public static JavaArchive deploy() {

   // This is the classes and resources archive
   JavaArchive ar;
   ar = ShrinkWrap.create(JavaArchive.class, "resources.jar")

    * The 'ar' archive will be added to the 'yourDir', so you'll
    * end with test.jar#/yourDir/TestClassPackage/TestClass.class
   JavaArchive endArch;
   endArch = ShrinkWrap.create(JavaArchive.class, "test.jar")
                       .merge(ar, "yourDir");

   endArch.merge(ar, "yourDir");

   return endArch;

When you create a deployment using Arquillian (great test runner for testing your Java EE code in the container of your choice: jBoss, Glassfish, OpenEJB, … either in embedded, managed or remote mode) remember that the name of the deployment archive file is the exact filename that will be executed in the container.

It does make a difference if you use *.war or *.jar for your deployment, so beware the following construct if it’s not exactly what you intended to do:

public static JavaArchive deploy() {
    JavaArchive ar;
    ar = ShrinkWrap.create(JavaArchive.class, "YourTests.war")

    return ar;

In this case you can end with ClassNotFoundException for YourTestClass.
Just use the archive format you need (in this case I needed a *.jar and not a *.war) as this does make a difference for the application server.

When you create a *.jar file using jar command-line tool, it is worth to remember that the order of arguments does matter, so:

jar cmvf projects/myTags/etc/MANIFEST.MF myTags.war myTags

means that you must firstly provide the manifest file (m), than the JAR filename (f).

If you use the same order of arguments but change the switches like this:

jar cvfm projects/myTags/etc/MANIFEST.MF myTags.war myTags

the command will not be executed. According to the switches, your first argument should be the JAR filename (f) and then manifest file (m).