Deployment is changing package contents in the org; unchangeable in a patch org

[Scott Wells]

From Twitter:

Hi, I have a problem with patch organization. I deployed several components and package description + settings page wiped out. I can't restore them in UI in patch organization - there is no Edit button in the package details page. Retrieve metadata shows the only difference in the package.xml - settings page + description,it's fine locally, but clean remote. btw, it always wipes out settings and description which is very annoying but at least can be fixed, but not for a patch org. Even if you deploy only one component it deletes description, settings page for the package. result is - remote package.xml is altered.

[Scott Wells]

Okay, I've successfully reproduced this. Still looking for how best to address it since the APIs for development packages are quite lean. I definitely agree that this is a significant issue for those working with packages, though, and it's a very high priority item for me.

I'm not sure if you have a package.xml that describes the correct package contents in your patch org, but if so, if you use the Force.com Migration Tool (ant sf:deploy) to deploy against that package.xml, it will put your patch org back into a good state in terms of the package manifest.

I'll keep this issue updated as I learn more.

[Scott Wells]

Okay, I'll be releasing a build tomorrow that addresses this, but with a small caveat. The short version is that there are no documented APIs that allow me to get the information I need to build a proper package.xml for deployment against a development package in the org. When I query DevelopmentPackageVersion, the description always comes back null, so I have no way to set it to the proper value on deployment. There's also no API to enumerate the contents of development packages. As a result, I'm no longer setting the package name on deployment, though retrieval will still work properly against the configured package. The main down-side to this is that if you create new metadata in Illuminated Cloud, it won't be automatically added to the selected development package after deployment; instead you'll need to manage the package manifest from within the org itself. I regret the down-side, but it's far better than corrupting the package manifest, especially in a patch org where it can't be repaired easily!

I'll continue working with Salesforce on ways that this might be addressed so that it works as intended. Thanks much for bringing it to my attention, and my apologies for the issues it's caused you and your team.

[Scott Wells]

Delivered in 1.6.8.7.

[Ivan Shcheklein]

Scott, thank you for the prompt response and fix of the problem. I'll test a new version. Regarding SF ant tools and package.xml. I'm getting: staticresources/bundle.resource-meta.xml -- Error: Required field is missing: content when I try to deploy. Plugin doesn't show any difference when I try to retrieve (except changes in the package.xml of course). How did you manage to push it?

[Scott Wells]

Ivan, just to clarify, are you talking about when you treat bundle.resource as a static resource bundle directory in Illuminated Cloud? If so, at deployment time I recreate bundle.resource from the bundle directory and include that in the deployment package, and at retrieval time I detect that the static resource is being managed locally as a bundle directory and extract the contents before comparison. You'd need to have your ant build script do the same if you're working with resource bundles. If you're talking about something other than resource bundles, can you please describe the layout of these static resources? Thanks!

[Ivan Shcheklein]

Okay. I got the state of the package.xml back. Thank you.