Why do we need some many hashed paths for the AppMeasurement.js | Community
Skip to main content
New Participant
March 12, 2019
Solved

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

  • March 12, 2019
  • 16 replies
  • 10919 views

Due to legal reasons we cannot use the CDN to get our launch scripts. So we download the generated files with the archive option in the environment. This was always a bit cumbersome because the top level paths always changed with each build and the inner path with each version of the AnalyticsExtension.

So we had something like this:

/BLe4b698d19ee94cf8b785407ccb4b97b1/hostedLibFiles/EP23d75a37c9fa4adb8bac5e48782e354a/AppMeasurement.js

Today I'v built the library again for dev using the latest extension version and the path exploded to this:

/CO43553243d83145ca9145261e586d2a23/PRc77ae538547743d6a733621fe60bd876/BLd0c019fe63cc434fad86cb9a55e49dc1/hostedLibFiles/EPd2399f7c689a4ae38db44080f8c6e80b/AppMeasurement.js

I assume all these hashed path will change with every build. So we have a, sorry me french, shitload of work each time we update our launch scripts. As we cannot simply extract the zip to an apache, we need to upload it into a CMS (even AEM) and recreate all this folders anew.

And as a side issue, even Windows (maybe the integrated ZIP) complains with too long paths when I try to extract it somewhere deeper then than one level below the disk.

Is this really neccessary or can this please be changed back? I don't care about these folders if I am not using a CDN, so we wouldn't need any hash at all; except for maybe caching reasons, but the top one would be enough for that.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by thebenrobb

We did decide to make a product change to shorten the hashes as well.  Instead of using IDs in the folder name, we've generated shorter tokens (still representing the same things of company, property, build, and extension) and using those instead.  This will not reduce the number of folders/hashes, but will greatly reduce their length.  We will also be better documenting the structure of those archive files explaining what is in them and why.

16 replies

jantzen_b
Employee
March 24, 2020
Do any of the answers below answer your initial question? If so, can you select one of them as the correct answer? If none of the answers already provided answer your question, can you provide additional information to better help the community solve your question?
thebenrobb
Employee
June 27, 2019

@charlk79482207

Realistically, probably the 3rd or 4th week of July.  Code is written, but there's a company holiday for 5 days in July, and we're going to do significant testing with this change before release.

thebenrobb
Employee
June 27, 2019

@giuseppes41275613

Impossible for us to say for two reasons:

  1. We have a known folder structure, but we don't know where on your filesystem you're putting our file(s), so we can't know the overall length
  2. Extension developers can provide their own JavaScript files inside of their Extensions (with arbitrary names), and those will be included as well

What I can tell you is that the longest possible paths we'll give would be:

  • 13 characters for the company token and a slash
  • 13 characters for the property token and a slash
  • 13 characters for the build token and a slash
  • 15 characters for "/hostedLibFiles"
  • 33 characters for the extension ID that is providing the hostedLibFile and a slash
  • the arbitrary number for the file name the extension developer provided which will obviously vary by which extensions you've installed

Altogether that's 87 + the unknown length of any library files provided by extensions.  If we say 25 is a reasonable median (no idea if this is true), then you're looking at ~112.

New Participant
June 25, 2019

Thanks for the response, when would this be available?

New Participant
June 25, 2019

Thanks for the update, though I still hope a flat version will be provided in the future. Or an option to generate an AEM content package. Just to save us from manual tasks after each build.

giuseppes412756
New Participant
June 25, 2019

Thanks Rob. Would that ensure that it'll always stay under the 256 character length for any file to publish?

thebenrobb
thebenrobbAccepted solution
Employee
June 25, 2019

We did decide to make a product change to shorten the hashes as well.  Instead of using IDs in the folder name, we've generated shorter tokens (still representing the same things of company, property, build, and extension) and using those instead.  This will not reduce the number of folders/hashes, but will greatly reduce their length.  We will also be better documenting the structure of those archive files explaining what is in them and why.

New Participant
June 25, 2019

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.

New Participant
June 25, 2019

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.

New Participant
May 7, 2019

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...