Retrieving Components into Sources Created outside of IC

[Petr Švestka]

Hi Scott,

Another issue. Here's a detailed list of steps:

1. new project
2. subscription: selected
3. none actually selected
4. not retrieve now
5. enable VCS (Subversion)
6. checkout from VCS (Subversion)
7. destination src
8. e.g., 2 classes and 2 VRs with an appropriate package.xml
9. not create new project from the fetched sources
10. Option A
    1. project settings | facets | select something not fetched from Subversion
    2. retrieve metadata
    3. retrieval scope window appears – toggling with (Local Only, Local + Server, Server Only, Subscribed Only) never displays sources fetched from Subversion
    4. selected components from the org is retrieved and components from Subversion is kept, but package.xml is basically rewritten rather than merged
11. Option B
    1. project settings | facets | select the package.xml fetched from Subversion
    2. retrieve metadata
    3. only classes are retrieved, VRs aren't and the "Local + Server" settings display the whole object file instead of VRs only

So the question is – can we make IC so that it's able to merge components from an org into sources created elsewhere?

The basic scenario:

1. get sources from VCS
2. add/merge components as fetched from org
3. commit changes to VCS

[Scott Wells]

Petr, you can do this today, but order does matter due to some restrictions in IntelliJ IDEA's own rules around VCS integration. I just did this with a Git repository using the following steps:

1. File>New>Project from Version Control>Git
2. Specified the URL/credentials of the Git repository and the local project directory into which I want it checked out.
3. After the branch is cloned into the selected directory, the new project is opened.
4. Illuminated Cloud shows "Invalid configuration for module '<moduleName>': module must have at least one source root". Clicked Resolve and confirmed the source root.
5. Illuminated Cloud now shows "Invalid configuration for module '<moduleName>': module must have the IC module type/facet/configured connection/etc.". Clicked Resolve and configured a connection to my org. IntelliJ also tells me that it's going to convert the module type.
6. Illuminated Cloud now shows "Invalid configuration for module '<moduleName>': module must have an OST/SDK.". Clicked Resolve and it automatically generated the OST and configured that as the module's SDK.
7. I'm now able to use IC to manage metadata components in the org and in Git from the same module/project.

The reason you have to do things in this order is that IntelliJ IDEA's VCS integration feature won't let you check out sources into an existing directory. You could do that from another tool or the CLI and then register it with the IDE, but you can't do it entirely from within the IDE. As a result, IC automatically detects that a non-IC module contains Salesforce metadata and guides the user through conversion to an IC module.

[Petr Švestka]

Thank you Scott. I followed the above steps with mixed results:

• In point 7, when I select and retrieve new components, the newly formed package.xml contains only what I asked to be retrieved. Not the contents that I fetched from GIT/SVN unless I merge manually or reselect them before retrieval. Is this expected?

• Also, not everything I selected for retrieval was actually retrieved. E.g., SVN sources included a Custom Settings Field, a bunch of classes. I selected a Page and a Validation Rule to be retrieved. The VR never got retrieved.

I'll do more testing once I see a commit in our repo.

[Scott Wells]

Regarding the package.xml contents, that's what Salesforce is returning in the API response because the package.xml used for the retrieval includes exactly what you're requesting vs. the full subscription. Otherwise the full subscription would be returned. I agree that this can be confusing, though, and at one point I was removing the incomplete package.xml during partial retrieves to ensure that folks didn't have to worry about it. Sounds like I may need to go back to that.

As for the missing validation rule, have you selected the validation rule in your subscription? I imagine you have, but I figured I'd ask the easy question first. I'll also look at whether I can reproduce this locally and will follow up with you here.

[Scott Wells]

I just ran a quick test of this where I added a validation rule to one of my custom objects. Then I went into the subscription config, refreshed, expanded the ValidationRule metadata type, and selected the newly-created validation rule. Then I performed a retrieve on the parent custom object and the validation rule was properly included in the retrieved .object file and was easily merged into my local copy of that file. Can you verify that this is how you have things configured?

[Scott Wells]

FYI, I create new issue #259 to cover removal of the package.xml file from comparison when doing partial metadata retrieval.

[Scott Wells]

Petr, I'm hoping (pretty sure?!) that the remaining problems in this issue were resolved with the recent enhancements to support explicit selection of child metadata types in the deploy/retrieve dialogs. Please feel free to reopen with a description of the remaining problems if necessary.