I have brought down a copy of a Salesforce org from a Git repository.
When attempting to deploy it to a sandbox I'm getting the following error (suitably anonymised):
<sf:deploy username="${sf.username}" password="${sf.password}" serverurl="${sf.serverurl}" maxPoll="${sf.maxPoll}" deployRoot="Salesforce\src" checkOnly="true"/>
Result:
*********** DEPLOYMENT FAILED ***********
Request ID: 0AfO00000062GMVKA2All Component Failures:
1. classes/FooBeforeInsertUpdateABCDEFGHIJOrder_Tst.cls -- Error: Must specify the metadata file
2. classes/afterBeforeInsertUpdateDeleteAccount_Tst.cls -- Error: Must specify the metadata file
3. classes/beforeDeleteABCDEFGHIJKLTransaction_Tst.cls -- Error: Must specify the metadata file
4. classes/AfterBeforeInsertUpdateABCDE_Tst.cls -- Error: Must specify the meta data file
Note: I came to this as an existing project and disavow the trigger structure and naming conventions.
What is odd is that the expected .cls-meta files definitely exist in the deployRoot classes folder next to the corresponding .cls file.
The .cls-meta for all the affected apex classes appears as:
<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
<apiVersion>33.0</apiVersion>
<packageVersions>
<majorNumber>1</majorNumber>
<minorNumber>1806</minorNumber>
<namespace>loan</namespace>
</packageVersions>
<status>Active</status>
</ApexClass>
At first I thought it was the apiVersion being 33.0 while the package.xml residing in the src directory had <version>31.0</version>
. However, changing the version defined in the package had no effect on the deployment errors. That, and there are other .cls-meta files that successfully deploy and also have v33.0.
I've confirmed that the target org has the loan
managed package installed with v 1.1806.4 and first installed version of 1.1799. Again, there are also other Apex Classes with exactly the same .cls-meta files, including the packageVersions elements that are successfully deploying.
Using MavensMate with "mm_compile_with_tooling_api" : false
I was able to deploy one of the problem Apex classes to the Sandbox. This makes me think the issue is around the Force.com Migration tool creating the package zip from the file system.