Static Resource Bundles

[Phil W-S]

If I have a ZIP file as a static resource, I know IC provides a means to convert this into a static resource bundle (albeit without integration with VCS, I note).

What I wanted to understand is whether this required you to do something special in the deployment processing or whether the meta API handles this automagically when there is a sub-folder in staticresources. Basically, wanting to know if this would mess up use of an old-fashioned Ant/script based deployment.

[Scott]

Phil, all you have to do is set the MIME/content type for the resource to application/zip and IC will recognize it as an archive-type static resource and offer the option to convert it into a resource bundle. Generally you'll want those in a separate source root (this is configurable in IC under Validation & Deployment settings). IC will create and register the source root for you when you convert your first resource into a bundle.

You can absolutely add those files to version control and I would recommend doing so as the master version of the static resource's contents.

By default any time you save a file under a resource bundle IC will automatically recreate the corresponding static resource file and deploy it for you. Again, this is configurable in the same location, but IMO enabling it results in the most intuitive workflow. Similarly IC recognizes wen a retrieved static resource file is managed locally as a bundle and extracts it for you, either for comparison (Retrieve for Merge) or for update (Retrieve/Refresh). The goal is that it should be a very seamless experience of working with resource bundles.

Obviously if you go this route and you have some type of non-IDE automation for deploying your metadata, you'll need to augment those processes for resource bundles. For example, if you use the Force.com Migration Tool (ant tasks), you'd just need to have a pre-sf:deploy step that archives your resource bundles into the corresponding static resource files. That way you'll have the same experience in your scripts as you do in the IDE.

Hopefully this answers your questions, but let me know if you it doesn't and/or it leads to additional ones.

Regards,

Scott

[Phil W-S]

Thanks Scott.

You more than answered the question.

In terms of the VCS integration, what I found was that using "Convert to Static Resource Bundle" did mark the original ZIP-based .resource file as deleted (for git at least) but did not automatically perform a "git add" for the files (so leaving the files as unversioned).

I did note that this operation automatically put the "exploded" ZIP content in a sub-folder in the staticresources folder for the project, with the sub-folder named after the original resource file (without the .resource extension). This seems fine to me. I didn't set up a separate source tree for it (and it makes sense to me to have it all in the one staticresources structure).

You answered the question; our old, IC-independent, scripts will no longer work and would need to be updated to allow them to work with these bundles (if we ever decided to perform deployment from outside IC in the future - e.g. for automated/scripted deployments or whatever).

It seems a great shame that the Salesforce meta API doesn't handle this directly by treating folders within staticresources as placeholders for ZIP files.

That said, I'm very happy to have this feature available in IC, despite the "incompatibility" with other IDEs and deployment scripts.

[Scott]

Phil, the behavior you're describing occurs when you don't configure IC to use a separate source root. I would highly recommend that you do configure it to do so. It will ensure that IC won't "pollute" the contents of your sacred src directory with things that won't deploy unassisted outside of IC. When you configure IC to use a separate source root it leaves the original static resource file in place and extracts the archive into a peer directory called resource-bundles, then manages the reconstitution of the static resource as needed. You would then check in both the resource bundle directory and the static resource file.

The in-place behavior is more legacy from the initial implementation. I then added the preferred option described above that is both less intrusive and compatible with some other tools that support resource bundles for teams who use heterogeneous tooling. Like I said, I would highly recommend you switch to using a separate source root and I think you'll find a much better experience overall.

For what it's worth, SFDX does support exploded static resources directly, so it's very much on Salesforce's radar...only for DX right now.

Let me know if this additional info doesn't give you the experience you're wanting.

Regards,

Scott

[Phil W-S]

Ah, I see. So the idea is to retain both the .resource file and the exploded files. And to put them both into version control?

The latter I don't like; once "bundlized", the "truth" is the set of files rather than the equivalent ZIP. I view the ZIP file as "compiler output". In the Java world, it is a bad idea to version control the JARs generated by the build for a whole bunch of different reasons, but mostly because this a) unnecessarily wastes storage space in your version control system and b) causes issues with concurrent changes as the files will clash and cannot be safely merged (since they are binary).

I think I prefer the default behaviour, even though this is incompatible with other IDEs and script-based deployments.

[Scott]

It's totally up to you as IC does support both models. Honestly I think that as long as you update your automation scripts for whichever you choose, you end up in the same place. I agree that checking in both is probably unnecessary. I agree that you shouldn't include derived/generated files in version control. The only thing that makes this different is that the resulting static resources are in fact part of the "source tree" from a Salesforce perspective. Having said that, I wouldn't check in the generated files either.

In the end as long as every mechanism you have for working with the source tree understands the relationship between the resource bundle directory and the corresponding resource file that's used for deployment, you'll be good to go. And of course you'd want to add the generated static resource file to version control ignore/exclude config to ensure that it's never accidentally committed to the repo.

Sounds like you have your head wrapped around the options and their respective implications. Hopefully the feature helps your team to manage the contents of those resources!

Regards,

Scott

[Phil W-S]

Apologies, (hopefully) one last set of questions on this topic:

If I set up the mechanism the way you suggested, but didn't check in the resource-bundles directory and content, would I have the best of both worlds? Will IC automatically extract the files into the resource-bundles directory if they are missing, and ensure that any changes to the files made in there are pushed into the ZIP resource (which we could continue to version control)? Or does this rely on the extracted files being available all the time?

Also, note that we don't put any of our IDEA project files/directory into version control at this point - mainly because we all have unique Salesforce connection names (perhaps we should remedy this). Is this going to cause problems if we then create static resource bundles? I.e. does something get specifically set somewhere in the project structure or is this inferred from having the directory structure?

[Scott]

No problem on the questions. Keep 'em coming as long as you have them!

IC won't automatically create resource bundle directories for you. Its only record of a static resource file being managed as a bundle is the presence of that bundle under the configured resource bundle directory, either resource-bundles (separate source root) or src/staticresources (same source root). If you didn't check in the resource bundle directories but did check in the static resources AND you wanted to work with resource bundles during development, each developer who works with that content would need to convert to a resource bundle explicitly. You'd also want to add resource-bundles to your version control exclude/ignore config.

IMO the ideal way to work with resource bundles is to check in both the contents of the src and resource-bundles directory but don't check in any .resource files that are created from resource bundles. Explicitly add those .resource files to your .gitignore/etc. to ensure they're never accidentally added to version control. Update your automation scripts to copy the contents of src into a working directory, e.g., work/src, and to generate .resource files for all resource bundle directories under work/src/staticresources, and deploy from there. That way your src directory is (mostly) sacred from a version control management perspective, and both the IDE and the build scripts take care of creating your .resource files from your resource bundle directories.

If you do use version control I highly recommend checking the IDE config files in. I've tried to document what should and should not be checked in and how best to share config through version control in the FAQ under Can I manage the IDE project files in version control? Which files should or should not be checked in?. That's the exact process that we follow in my day job and it works very well for us. It also facilitates branch/org switching very nicely because the config is checked in with the branch, so when you switch branches you automatically switch to the correct config.

Regards,

Scott