I'm work on a managed package in a developer org and I'm using the migration tool to move the contents to an Enterprise Edition org provisioned from the partner portal.
I was able to pull my package down with an 'ant retrieve' I setup. I removed the namespace from the XML since I don't need that for now.
I then try to deploy it and it keeps failing on fields that aren't even part of my package.
At first it was failing on the leadSource picklist value fields (I did not customize these). Apparently the default picklist values are different between the origin (developer org) and the EE org. I removed those from my Contact.object and now its complaining about lastReferencedDate on several of my custom objects. Has anyone else encountered these types of errors or know how to resolve them? I have a feeling I'm falling down a slippery slope of just trying to strip stuff out one error at a time.
Update
I stripped out all of the problem fields/picklist values that weren't related to my package from the metadata.
I then had to remove all of the available in fieldset entries in my object XML. Apparently thats not allowed in EE orgs: http://boards.developerforce.com/t5/Apex-Code-Development/Field-set-issue/m-p/716451#M133498
The last remaining error is:
- connectedApps/Synapse.connectedApp — Error: You cannot provide a Consumer Key
Its my understanding that this technically has to only live in 1 org to function, is that correct? It looks like thats the case based on the responses here: Connected App in Managed Package
Best Answer
Moving out of your Packaging Org. You will eventually reach a point where what you have extract is a unmanaged version of your package contents, which can be made to be compatible with a subsequent deployment back to your packaging org, which i'm guessing is what you have later in mind? I have done this before, when I've out grown developing in a packaging org, but rather I've done it with a view to populating a source control system and using that as the central definition of truth for my app.
Developer Workflow from Source Control. You can still use your sandbox orgs for your developers, but have them deploy using the Salesforce Migration Toolkit from your source control system. When your ready you can do a deploy to your packaging org from source control.
Validating Source Control Contents. Note that you can extend this to a continue integration build approach and effectively use the test deploy aspect of the toolkit to confirm your current state of source control is compatible with your packaging org (without actually committing to it until your ready).