Why do we need some many hashed paths for the AppMeasurement.js

Hi Thomas,

Just out of curiosity, did I understand the major concern correctly that the folder structure can't be deleted and created automatically (e.g. by a script) in the CMS while unzipping the archive?

The top level path can be actually set is the Environment configuration in the "Self-hosted Path to Library" field. This will mean that the path you mentioned will be a subfolder. For example, you can set the self-hosted path to "/launch-folder/". Then all paths generated by Launch will be referring to it as a top path. So by unpacking the archive to /launch-folder/ you do not need to change anything else on the CMS level as I understand.

Let me know if I'm missing anything.

In AEM the only ZIP files that can be uploaded and unzipped automatically are so called content packages with a defined structure, I created an idea a while ago that they should provide an option to generate such an AEM compatible ZIP; it is the same company after all...

The top level path is ok that is working as expected, but is also a bit limitted as it is the path you define from where the script is loaded, but in AEM this is not the same as where the script is stored in JCR.

Sorry, I'm not super familiar with AEM, but the first two hashed paths are your Company ID (CO1234) and Property ID (PR1234).  Those should never change.  The third is your Build ID (BL1234) and that will change each time you do a build.  The 4th is an Extension Package ID (EP1234) that will change whenever you upgraed your extension.

However the .zip package should also contain symlinks at the root level that link down to the main Launch Library.  That .zip package is designed so that you can reference the symlinks in your published HTML and never have to make individual changes for each build.

Also the Main Library will reference AppMeasurement when it needs it, can you explain a bit more about why you need to reference AppMeasurement directly?

I'm having the same exact issue (with the same security concern).. Visual Studio 2017 and MSBuild don't like paths longer than 260 characters. So if I include these files as is, they take up 202 characters. Which doesn't leave much flexibility for the file location in windows. AKA, one developers computer may work, while another won't compile because of the character issue. (yes, there is a win 10 fix, and no...it didn't work for me, and yes, even if it did, we would need to get corporate IT to fix which would take forever).

So I see you are saying the folders matter, but I found that the actual launch-XXXX.min.js file that we needed was in 3 different locations within the archive. And that all three .min. files are identical. So instead of using the one at the root of the downloaded file, I just copied the files that were in the build folder into my site. I then had the two launch-XXX files (one min, one non-min), and two RC files. There was also a folder for hostedLibFiles which i copied directly. This reduced the character for the longest deepest file from 202 to 97. A much more manageable number.

At first this didn't work, but then I went into the launch and changed the path, removed the extra folders...and bam. It looks like it works. The files load properly and they seem to be firing correctly in Adobe Experience Cloud Debugger.

Now my question is, outside of this being a manual process to reduce the urls, if htis works, why can't it just be the standard? When you download to run local, just download the build folder? (with the correct paths). Or is this really not working, but just looks like it is?

I don't need to reference it directly, but the full path to it is configured in the launch script: hostedLibFilesBaseUrl

So we either have to change the generated file manually after downloading it or create a new folder (or move rather move the existing one) after each build.

I understand the hashes for company and property and even build for a CDN. But if you download it, it would be way easier to just have it flat, e.g. launch.js and AppMeasurement.js in the same root folder of the ZIP.

I'll talk to Engineering about this.  A very similar problem came up in one of our Slack channels recently (may be the same issue actually).  Changing the structure of the Archive seems like it would be challenging for backward compatibility reasons, but maybe there's something we can do.

Maybe just add another option, e.g. "Flat Archive"

There you can add all the scripts to the ZIP without any folders and generate the path for this hostedLibFilesBaseUrl to only what you configure.

Or even create a new Adapter which only generates a flat zip to download...

Has there been any update to this, we are facing the same issue.

We are pulling down the archive, deploying it via our build pipeline however fails due to the folder character limit.. Have a look at the `hostedLibFilesBaseUrl` and you will see how unreasonably long the path is.

We could automate the replacing the paths if we had some reference to the keys used for naming the folders.

You can easily replace the first two hashed parts as they never change. As thebenrobb wrote they represent company and property. The third hash is like a build number and changes with every build. The last hash one only changes if you update the Analytics Extension.