ADOBE CQ5 frequent building of clientlibs folder - aem

This issue is related to frequent building of client lib folder in adobe cq5.
Whenever i updating the code in js and css file, the changes are not reflected as soon as saving the related js and css file.
i have to do this url //server:port//libs/granite/ui/content/dumplibs.rebuild.html.
After clicking the "rebuild libraries" button, then only my changes are updated in the html file.
Can i have to configure any file to bypass this process?
Thanks

Instead of invalidating and rebuilding all the libraries via the dumplibs.rebuild.html interface you can just selectively invalidate the changed clientlib manually. The cached copy of clientlibs are stored under /var/clientlibs. You can navigate to the required components' js and css files under /var/clientlibs/apps or /var/clientlibs/etc and delete them. They will get rebuilt when any page that uses these are requested.
Since only select libs are deleted and rebuilt, it's lot faster.

I use various options:
Just change the .js, .css, or .less file that is included in the library - sometimes it seems CQ will detect this and rebuild the lib without any other changes.
Open the js.txt or css.txt file for the library I want to rebuild, go to the end, then hit the enter key to add a new line at the bottom - this usually causes the lib to rebuild, and it is usually the fastest mechanism for me when I am working on UI stuff (in CRXDE Lite).
If that doesn't work, I invalidate the cache with this URL: http://localhost:4502/libs/granite/ui/content/dumplibs.rebuild.html?invalidate=true but don't rebuild the client libs (since that takes too long and rebuilds more than I need to rebuild).
If that still doesn't work I manually clear the libs from /var/clientlibs as a last resort (or restart my CQ instance if I have to do this a lot)
I wish I understood why sometimes CQ rebuilds the library and at other times does not when I seemingly perform the same steps. But regardless, I hope this will help or be of use to someone else.

Related

What should be stored in source control for an Asp.Net Core MVC application?

With the new Asp.net Core MVC projects such as:
There are a lot of unfamiliar folders there, like bower_components, wwwroot, Dependencies, etc..
What should be stored in source control?
Anything that is a project setting, or that you directly change you should store. Anything that is directly downloaded (references, bower/node) or is directly based on those (lib folder getting copied by gulp) should be ignored.
So, in your case, ignore bower, node, and project\wwwroot\lib. You want the wwwroot folder if you have custom css or js.
I went with
(With green being yes, red being no)
The only unlisted exception was the .xproj (and for TFS the .xproj.vspscc).
I deleted the folder from my local workspace (after backing up to somewhere else) and restored from source control and everything seems to behave as it should, once all the packages restored themselves.
This assumes that the gulpfile.js is configured to move the needed css, js, font components into wwwroot.
Also since I wrote this, there is a launchSettings.json within the properties folder that I've source controlled (Not sure why it's only just generated).
My .tfsignore file is currently:
project\wwwroot
!project\wwwroot\web.config
project\node_modules
project\bower_components
(which seems to be OK so far, but would potentially change if other static resources such as JS, CSS and Images were added in.)

Package development for Sublime Text 2 with multiple files without restarting

I am developing a couple of packages for sublime text, and to avoid copy and pasting massive amounts of code I began to move my classes into separate files. I have been avoiding this so far, since, in my current workflow, changes to files that are not in the main plugin file won't get updated when saved and only go into effect when I restart sublime.
Is there a way to reload a package, including all it's files, without restarting Sublime Text?
You don't actually have to restart the editor. You will have to restructure your plugins though to take advantage of this. Essentially, you can load the plugin files from some top level file. As an example, take a look at Package Control. I also do it in PersistentRegexHighlight (though the package control solution is likely more robust (I did base it on that). Still not as good as simply saving a particular file, but better than restarting! In fact, you could probably tie into the on_post_save event to automatically save the top level file when you modify a child file.
I personally found the easiest solution was to install Package Reloader, and just put a new file in the top directory of my plugin named .build. Save your top-level plugin file and enjoy not having to restart.
Virtually no restructuring of code required.
From the unofficial docs:
Sublime Text will reload top-level Python modules from packages as they change (perhaps because you are editing a .py file). By contrast, Python subpackages won’t be reloaded automatically, and this can lead to confusion while you’re developing plugins. Generally speaking, it’s best to restart Sublime Text after you’ve made changes to plugin files, so all changes can take effect.
Unfortunately, plugins are not loaded into a scope visible from the console (Ctrl`), so you can't just reload() it. EDIT But, you can call reload() from within your top-level plugin file, as detailed in #skuroda's answer.
You'll have to make the decisions on when to break classes out into separate files vs. keeping them together in one monolithic collection. Having 50 files, each with only two or three function definitions is overkill in one direction, while having 20 classes each with 10 or 15 methods all in one file is going overboard in the other, so just do what feels best for the particular project. In my experience killing/restarting ST2 doesn't take too long in any of the supported operating systems (except on XP, for some reason...), so hopefully it's not too much of a delay on your workflow. One suggestion I'd give is to create a portable installation (if you're on Windows) with just the bare essentials in extra plugins if your startup time is too long.
Good luck!

NetBeans: Code changes to javascript & css files are not reflected in browser after saving

This is driving me crazy. I'm developing an app in the NetBeans IDE in PHP, using the CodeIgnitor framework. I am making code changes to js and css files in NetBeans, saving them but the files the browser is loading do not contain the code changes. When I open the files directly outside of NetBeans, the saved changes aren't there.
I'm storing the javascript & css files in a folder called static, which is outside of the 'application' directory in CodeIgnitor. What's weird is any code changes in PHP files work fine. I'm guessing NetBeans is saving the changes to the js/css files somewhere else but can't find them on my hard drive. This just started happening, it was working 'normally' before.
Thanks for the help.
Al
I had the same problem, upon investigation, my browser cached my old style sheet that I had recently updated. Clearing the cache and refreshing showed my new styling, after around 20 minutes of frustration :D
This problem occurs due to browser cache. For chrome while testing open the developer mode by pressing the F12 key and set cache disabled in the network tab as shown in Image below. It will ensure that you will always get updated version of the page files.
Check to make sure that the files are where you think they are. I would imagine that CodeIgniter is rewriting the request to be inside your application folder and thus bypassing your specific folder.

How do I force Eclipse to rebuild if files in another project change (any change)?

I've got an Eclipse (Galileo) project (called ProguardBuilder) that runs Proguard over a set of class files in other projects and produces a jar file.
I'd like to have the ProguardBuilder project get rebuilt any time any class file in the other projects changes. AutoBuild doesn't do that; presumably it's smart enough to recognize and ignore any changes that don't affect anything externally visible.
My problem is that I don't care whether or not the change is visible, since I need to completely rebuild ProguardBuilder any time the class files it depends on change at all.
How do I tell Eclipse to do this sort of rebuild?
You might have to use an external builder. Check the documentation, because I've never done this. But the place to start is the "Builders" section of the project properties dialogue.

How can I tell xCode to recheck project resources that have been modified?

I'm working with a designer friend on an iPhone app and he likes to refine all sorts of images relating to the project we're working on. All these images have been added to the project previously (and added to the project folder by xcode) and then are modified in their new location. When I preview the images in xCode, the updated images show up but building and running in the simulator or on a device doesn't pick up the new image. In fact, if I do a clean build it seems to ignore the image all together and blank spaces appear where images should be.
Now, I can delete these files from the project and re-add them and everything works peachy again. But there are a lot of them and I'd rather not do that every time an image is updated. Is there a way to get xCode to review and "learn" about these modified images? Is there a good reason for why it's not doing that automatically?
You didn't specify how you're including those image resources into your project, but I'd guess you're including them directly. So unless there's an underlying process that's changing the file in-place (are you using an SCM like Subversion or Perforce?) you're going to be forced to manually overwrite the files whenever your artist friend updates them.
You should include art assets in the project using a folder reference instead. (I'm still assuming you have some sort of SCM set up to handle exchanging data -- if you don't, set one up ASAP.) However, there are still some outstanding Xcode bugs related to picking up changes to files in a nested folder hierarchy included by reference, but at least you can work around that by doing clean builds when necessary.