Creation of project manifest file as a first class feature.

[Rohan Gore]

In many projects specially the projects with version control systems like Git and CI/CD in place, the expectation from the devs is to commit and push the package.xml file as well specific to their changes so that the deployment would be a selective one rather than CI system relying on a full manifest file with * and tries to deploy every file every time as a build and deployment process. It would be extremely convenient to have package.xml being created by selecting the files and having an option 'create manifest (for the selected components)' and save it to the location of your choice or merge with the some existing package.xml file in the project folder. This will allow the devs to generate/merge this package.xml before committing and pushing their code to the remote repo and thus facilitating selective deployments.

[Alex Sutherland]

I would like to concur with Rohan - our development team already relies on package.xml for very explicit collaboration on a sizeable project within a very large enterprise environment. We would like to be able to right-click on a metadata component in the project tree and say "add to package.xml" or something like that.

[Scott Wells]

While there's no first-class option for this, you can simulate the desired behavior by configuring your metadata subscription as Package.xml, right-clicking on your src directory, and clicking Illuminated Cloud>Add to Metadata Subscription. If you don't have an existing package.xml file, one will be created for you. If you do have one, it will be updated for the contents of the local project. If metadata types have existing wildcards, they will be respected; if not, explicit entries are added. As a result, if you do this from scratch the manifest will be fully blown out with no wildcards. You can use that as a starting point, though, and collapse types which support wildcards and should be wildcarded into wildcard entries. From that point on IC will help you maintain that package.xml file as files are added to and removed from the project.

Not the first-class feature being requested here, but it's a reasonable stand-in until I get to this story.

[Alex Sutherland]

Thanks for the explanation of that feature @RoseSilverSoftware , that gets us closer to what we're looking for!

[Scott Wells]

@alexsutherland, I think this gets very close to what you've requested. Assuming you're using a Package.xml metadata subscription, by default IC will automatically manage entries in the corresponding package.xml file for you.

This behavior can be configured under Illuminated Cloud>Configure Application in the Validation and Deployment tab by changing the setting for When files are added and removed [Always Update|Prompt|Never Update] (Prompt is the default). If you wanted this to be 100% under your control, you'd change that to Never Update and then you can right-click on any selected files/directories under a source root and use Illuminated Cloud>Add to Metadata Subscription to add those files/directories to the appropriate location in the package.xml.

Let me know if that's not what you're requesting. It's a little different from what @rohmaxgore has requested which is more of a package.xml generator from a project as a one-off rather than as your metadata subscription (or at least that's how I understood his original request).

[Alex Sutherland]

Indeed it does! I didn't want to create a duplicate feature request (and wasn't sure I knew the functionality well enough yet), so that's why I figured it was better to add my comment here, and I'm glad I did!

I do think that Rohan's feature request is a good one as well however, and I'm sure that we would find use for it amongst our various projects.

[Peter Lin]

Thank you, @RoseSilverSoftware, for the detailed explanation which is a pretty good solution already. Like it very much!

[Scott Wells]

Closely related to #1797 but not quite the same. Might make sense to tackle them at the same time, though.

[Scott Wells]

Issue #1966 was marked as a duplicate of this issue.

[Scott Wells]

Issue #2525 was marked as a duplicate of this issue.