I just recently updated some javascript files in a CQ5.6 instance. I deleted the vars/clientlibs folder so that CQ would regenerate the appropriate files on next page load. When it regenerated them it still included the original javascript. I double checked and both the authoring and publishing instances had the new javascript so I do not know where it is holding onto the old stuff.
So, where does CQ cache the files that it generates its var files from?
CQs clientlibs are cached by the HtmlLibraryManager. Use jad, JDecompiler to see it's implementation.
One workaround I found is to rename the node of the clientlib. So if it is myClientLib, just rename it to myClientLib_somethingelse, then it will use the new js (It cleans HtmlLibraryManager's cache for the clientlib). After then you can rename it back.
Update:
I forgot to mention an url where you can rebuild the clientlibs and here you can also invalidate the cache: /libs/granite/ui/content/dumplibs.rebuild.html. It sometimes fails, but maybe it will work. :D
It is also an useful url for checking clientlibs: /libs/granite/ui/content/dumplibs.html
After deleting the /var/clientlibs cache you may also want to try restarting the Adobe Granite UI Commons (com.day.cq.cq-widgets) bundle from the /system/console/bundles view.
That bundle provides the com.day.cq.widget.impl.HtmlLibraryManagerImpl service, which is responsible for compiling the clientlibs and could theoretically hold some in-memory cache as well.
At one point this was definitely true for the JSP compiler, where removing the /var/classes/org/apache/jsp folder was not enough to force a recompile without also restarting the JSP scripting support bundle.
This is a generic problem, and it will be worst when CSS/JS got cached on client browser. I would recommend to use ACS Commons, Versioned Clientlibs feature in your site to add version number in css/js files. Please refer: http://adobe-consulting-services.github.io/acs-aem-commons/features/versioned-clientlibs.html
Related
I have stored a JavaScript file in a TYPO3 extension (under Resources/Public/Css/JavaScript/Backend/Iconpack.js), which is used as a JavaScript module in the backend.
However, when developing the extension, I packed the file full of console.log() to allow debugging, and also to better document certain things.
Of course I want that in the final extension as well as when downloading via composer, only a minimized version of this JavaScript is loaded, but not the original source file.
On the other hand, of course, I want the original source file to be stored somewhere in the git repository, so that you can actually continue working on it.
In the frontend, I would normally just store Iconpack.js, for example, in the same folder, create a minimized version from it, i.e. Iconpack.min.js, and use this minimized file.
But unfortunately that doesn't work in this case, because the file path for JavaScript modules is also the namespace.
What would be the best way to solve this?
To summarize:
The minimized version should be able to be used directly in the backend via Iconpack.js.
The namespace should be TYPO3/CMS/Iconpack/Backend/Iconpack and not TYPO3/CMS/Iconpack/Backend/Iconpack.min or similar.
The source file should not end up in TER or be loaded via composer.
But the source file should be accessible via Github.
I was able to find out that I can at least prevent a certain file from being loaded via composer with .gitattributes.
Unfortunately, that doesn't solve the question of where I should best place it so that other developers have it easier and it's clear that it's the source file.
Currently I only have the minimized version stored in git for this reason, but that makes little sense for an open source repository: https://github.com/quellenform/t3x-iconpack/tree/main/Resources/Public/JavaScript/Backend
Ideas?
I am new to ExtJs.
When practicing in eclipse do we need to include the entire library(52 MB approx) in the appropriate location?
Is there any shorter version of this library?
Can I delete some files in the library which are not important?
What are the necessary .js files to be included for building a sample MVC pattern, CRUD operation support application in ExtJs 4.2?
For my setup, I include the /ext directory in my project, however I exclude it from the build path so that it doesn't slow Eclipse down. See Eclipse: Javascript validation disabled. but still generating errors?
Then, if you don't even want to see the directory in your workspace, you can create a working set.
I wouldn't recommend deleting/excluding ExtJS source files from your project, especially if you are using Sencha Cmd and/or using dynamic loading in your application.
If you really want to include the bare-minimum, you could get away with using ext-all.js, ext-all.css, and making sure you have all of the ExtJS image files.
I completed my very first project in zend framework!! Thanks to stackoverflow community!!
While uploading files, i didn't know how to include zend library so i uploaded the whole library in the /library folder of my project base.
Is there a way to determine which library is used and which in not (like compilation that automatically copies dependent files to library folder incase webhost does not provide zend library ..)? i would be awfully bad to manually add each file and test weather the particular library is added or not.
This answer essentially says don't worry about including the whole library. I usually put the whole library in the project library folder, just like you did.
But if it is truly problematic to include the whole library, you could take a look at Jani Hartikainen's Packageizer which, at least in a previous form that I played with, allowed you to specify the components you needed and it would chase the dependencies and wrap them in a neat little package.
Disk space is cheap. Just have the entire ./Zend library directory (and maybe ./ZendX, if you are using that) into your own library directory where it will used. With autoloading, nothing that isn't being used will take up any significant memory. taking even 5 minutes trying to figure out is time (and therefore money) that is more usefully spent writing code.
I wonder if it would be worthwhile/reliable to subclass the autoloader for this and have it optionally log each class it loads during site operation (sort of how Zend_Translate can log untranslated strings).
You could have it turned off normally but in your testing environment you would turn it on (via your application.ini), and have it build your dependency list while your unit tests are running.
I'm developing a web app.
If I include a jQuery plugin (or the jQuery file itself), this has to be put under my static directory, which is under SCM, to be served correctly.
Should I gitignore it, or add it, even if I don't plan on modifying anything from it?
And what about binary files (graphic resources) that might come with it?
Thanks in advance for any advice!
My view is that everything you need for your application to run correctly needs to be managed. This includes third-party code.
If you don't put it under SCM, how is it going to get deployed correctly on your production systems? If you have other ways of ensuring that, that's fine, but otherwise you run the risk that successful deployment is a matter of people remembering to do all the right things, rather than some automated low-risk "push the button" procedure.
If you don't manage it under SCM or something similar, how do you ensure that the versions you develop against and test against are the same? And that they're the same as production? Debugging an issue caused by a version difference you don't notice can be horrible.
I generally add external resources to my project directly. Doing so facilitates deployment and ensures that if someone changes the version of this file in your project, you have a clear audit history of what happened in case it causes issues in the code that you've written. Developers should know not to modify these external resources.
You could use something like git submodules, I suppose, but I haven't felt that this is worth the hassle in the past.
Binary files from external sources can be checked in to the project as well, although if they're extremely large you may want to consider a different approach.
There aren't a lot of reasons not to put external resources like jQuery into your repo:
If you pull it down from jQuery every time you check out or deploy, you have less control over which version you're using. This holds true for most third-party libraries; you probably don't want to upgrade your libraries without testing with your code to see if it breaks something.
You'll always have a complete copy of your site when you check out your repository and you won't need to go seeking resources that may have become unavailable.
For small (in terms of filesize) things like jQuery and images, I'd just add them unless you're really, really concerned about space.
It depends.
These arguments relate to having a copy of the library on your system and not pulling it from it's original location.
Arguments in favour:
It will ensure that everything needed for your project can be found in one place when someone else joins your development team. I've lost count of the number of times I've had to scramble around looking for the right versions of libraries in order to be able to get something working.
If you make any modifications to the library you can make these changes to the source controlled version so when a new version comes out you use the source control's merging tools to ensure your edits don't go missing.
Arguments against:
It could mean everyone has a copy of the library locally - unless you map the 3rd party tools to a central server.
Deploying could be problematical - again unless you map the 3rd party tools to a central server and don't include them in the deploy script.
Using online interfaces to a version control system is a nice way to have a published location for the most recent versions of code. For example, I have a LaTeX package here (which is released to CTAN whenever changes are verified to actually work):
http://github.com/wspr/pstool/tree/master
The package itself is derived from a single file (in this case, pstool.tex) which, when processed, produces the documentation, the readme, the installer file, and the actual files that make up the package as it is used by LaTeX.
In order to make it easy for users who want to download this stuff, I include all of the derived files mentioned above in the repository itself as well as the master file pstool.tex. This means that I'll have double the number of changes every time I commit because the package file pstool.sty is a generated subset of the master file.
Is this a perversion of version control?
#Jon Limjap raised a good point:
Is there another way for you to publish your generated files elsewhere for download, instead of relying on your version control to be your download server?
That's really the crux of the matter in this case. Yes, released versions of the package can be obtained from elsewhere. So it does really make more sense to only version the non-generated files.
On the other hand, #Madir's comment that:
the convenience, which is real and repeated, outweighs cost, which is borne behind the scenes
is also rather pertinent in that if a user finds a bug and I fix it immediately, they can then head over to the repository and grab the file that's necessary for them to continue working without having to run any "installation" steps.
And this, I think, is the more important use case for my particular set of projects.
We don't version files that can be automatically generated using scripts included in the repository itself. The reason for this is that after a checkout, these files can be rebuild with a single click or command. In our projects we always try to make this as easy as possible, and thus preventing the need for versioning these files.
One scenario I can imagine where this could be useful if 'tagging' specific releases of a product, for use in a production environment (or any non-development environment) where tools required for generating the output might not be available.
We also use targets in our build scripts that can create and upload archives with a released version of our products. This can be uploaded to a production server, or a HTTP server for downloading by users of your products.
I am using Tortoise SVN for small system ASP.NET development. Most code is interpreted ASPX, but there are around a dozen binary DLLs generated by a manual compile step. Whilst it doesn't make a lot of sense to have these source-code versioned in theory, it certainly makes it convenient to ensure they are correctly mirrored from the development environment onto the production system (one click). Also - in case of disaster - the rollback to the previous step is again one click in SVN.
So I bit the bullet and included them in the SVN archive - the convenience, which is real and repeated, outweighs cost, which is borne behind the scenes.
Not necessarily, although best practices for source control advise that you do not include generated files, for obvious reasons.
Is there another way for you to publish your generated files elsewhere for download, instead of relying on your version control to be your download server?
Normally, derived files should not be stored in version control. In your case, you could build a release procedure that created a tarball that includes the derived files.
As you say, keeping the derived files in version control only increases the amount of noise you have to deal with.
In some cases we do, but it's more of a sysadmin type of use case, where the generated files (say, DNS zone files built from a script) have intrinsic interest in their own right, and the revision control is more linear audit trail than branching-and-tagging source control.