Support retrieval of managed package

[Alexander Johannes]

There seems to be no obvious way to subscribe to a managed package for a particular project. When i select All/Package during project creation, IC retrives far more components than added to the available managed package.

It would be perfect, if i can select a available package and just subscribe to its components. Metadata retrieval should also honor the selected package.

I'm using the force.com migration tool with a handbuilt build script, which is exactly doing that. But i like IC gaining support for this as well. Do not hesitate to contact me, if you need further technical details.

[Scott Wells]

Alexander, what types of metadata are you wanting to retrieve from the installed managed package? The reason that IC doesn't in general allow retrieval of package content is because you can't in turn deploy it without errors. The notable exception to that is packaged custom objects which you need to retrieve so you can add custom fields, validation rules, etc., and IC does support retrieval of those. The interfaces for packaged Apex classes and custom objects are included in the OST so that they can be used for code completion and such. I currently don't generate the interfaces for packaged global Visualforce or Lightning components, though. That's something I've been meaning to address but just haven't gotten around to it yet.

Please let me know what you're wanting from the package that wouldn't be covered by the things described above and, if you don't mind, why you need those locally so I can understand how best to accommodate the need.

[Alexander Johannes]

Scott, sorry for the long pause to reply.

We are using packages to deploy/retrieve metadata to simplify the configuration. Components, which are not part of the package are irrelevant for local tools (e.g. Version Control, Editors, IC). But if a component is added to the subscribed package, it will show up automatically after a retrieve, without any local configuration changes.

Short example from last week, which caused high friction within IC:

We added a new custom object to a Dev Org. The object was also added to the managed package of this org. A retrieve with ant got hold of the new metadata (e.g. src/objects/, src/package.xml, src/translations/).

Now the steps i needed to take in IC in order to get hold of the new object:

1. Configure Module, Refresh selected Metadata Components
2. Retrieve Metadata
3. 'Review' retrieve result and 'merge' from left to right
4. Rebuild OST

This is way too much effort for something, that can be fully automated.

[Scott Wells]

Thanks for the update, Alexander. If you don't mind, I'm going to repeat back my understanding of what you're trying to do to make sure that I'm considering things properly. Don't hesitate to let me know where I'm misinterpreting.

It sounds like you guys are working against a shared development organization in which you're collaborating on the contents of a managed package. This isn't an installed managed package, but rather an under-development managed package in a packaging org. Hopefully that's correct because the rest of what I'm going to say is predicated upon it.

Someone modeled a new custom object in this shared package development org and developers wanted to pull a local copy of the .object file for that custom object into the local filesystem. This works without any additional effort via the Force.com Migration Tool, presumably because your package.xml is already set up properly to include the new custom object once it's been added. However, in order to have access to the new custom object from within Illuminated Cloud, you're needing to follow the steps outlined in your previous comment which are unnecessarily onerous.

Okay, so hopefully what I've written here is correct. I'm going to provide a response based on it, but if it's WAY off the mark, just let me know.

You can configure your metadata subscription three different ways:

1. All/Package - Use this when you either want everything in the org (almost never) or have selected a development package from the org and want to deploy/retrieve against that development package. Based on the description I gave above, this would be a good option for you because it's "self-maintaining" based on how Salesforce sees the contents of the selected development package.
2. Package.xml - Use this when you have a carefully hand-tailored package.xml file for your project that's also used by automated processes. Again, this seems like a good option assuming that other tools that use package.xml already "do the right thing" at any given time.
3. Selected - Use this when you want to maintain a custom subscription to the metadata only for the IDE.

Which type of metadata subscription are you configured to use right now?

As for step 4, rebuild OST, if it's just custom objects/fields you can rebuild only the SObjects in the OST when needed. Additionally if you pull down the .object file(s), IC will automatically rebuild the SObject portion of the OST when it deploys the .object files.

Okay, I'll pause there since it's quite possible that my core understanding is completely off and nothing below that is relevant! Please let me know your thoughts after reviewing this.

[Alexander Johannes]

Scott, sorry for not mentioning the whole prerequisites and leaving you guessing a little bit. You almost got it right ;).

The DevOrg in question is indeed a packaging-org with a managed package under development. It is solely used by one developer (rule of thumb for our dev-process: one DevOrg per Developer per Release). The package.xml used during ant retrieve is containing the name and namespace prefix of the managed package. It does not contain any wildcard selections. Ant will automatically detect additions to the package (e.g. new Objects, Fields, Classes) and add them to the local file structure and package.xml.

---

All/Package

This retrieves way too much components. After setting up a new project with that option, the first retrieve (during setup) does also not retrieve everything. When i do a manual retrieve afterwards, it pulls even more components from the Org. I frankly see not option on how to limit this to the contents of the available managed package. The project settings for IC do not show me the managed package.

When i add a new custom object to the package, a new retrieve gets hold of that. The OST does not get rebuilt for that object afterwards.

Package.xml

This seems to be to limited, because i need to edit the package.xml to get hold of new components.

Selected

This was the option used, when describing my steps.

[Scott Wells]

Alexander, with the current build you go into the configuration screen for your Salesforce connections and under the Advanced section you can tell it to enumerate the development packages from the org:

You can then associate your local modules with the development packages in which you want their source files deployed. In your case it sounds like you'd just associate your one module with the one development package.

Once these are queried from the server, you'll also see them available for selection from the subscription editor:

Once so configured, it retrieves using single-package-by-name retrieval options.

This overall flow will be quite simplified in an update I'm planning to release later this week, by the way. Please let me know if configuring it that way doesn't give you what you need.

[Alexander Johannes]

Scott, this configuration does indeed what i expect. Since this is rather complex, i'm looking forward to the new version.

[Alexander Johannes]

Somewhat complex, but possible. Better UI on the horizon.