I'm having some issues since I've changed the vendor folder path for a symfony2 project. (Its currently outside of the project)
But right now the symlinks (phpunit, doctrine, etc) inside the bin folder are wrong.
When composer runs in which part or what actually creates the symlinks that appear in the bin folder (like phpunit) that point to lib in the vendor folder? Where those paths are comming from?
Thanks
Just delete the vendor directory and run ./composer.php install and you'll get the symlinks back. I couldn't find a way to force recreation of the bins
Related
I change the code in repo carbon-apimgt, and i run command "mvn clean install -Dmaven.test.skip=true" , I get a jar from target, what's next to apply this change?
Plugins directory is where we keep all the jars of components that are used in the product. Patches directory is used to track the changes done to each jar. What it does is, when you add a directory (eg: patch0001/) and add a jar to this new directory (eg: patch0001/org.wso2.carbon.apimgt.api_9.0.174.jar), this will replace the same-named jar that is found in the plugins directory.
Before this replacement, the server will first backup all the jars that are found in the plugins directory to a new folder patch0000 inside the patch folder.
At each startup, server will first apply the jars in the patch0000 directory and start replacing the jars by increasing the counter of each patch folder. (eg: patch0000, then patch0001, patch0002 up to patch9999).
This is the difference between the plugins directory and patch directory. If you replace a jar in the plugins directory, this is not a backward compatible change. However, if you replace a jar using this patch mechanism, whenever you remove the patch0001 directory from the system, this change will be reverted and the original jar will be preserved.
I'm currently trying to migrate an old ASP.NET WebSite project to Visual Studio 2015. I'd like to use NPM/Gulp to automatically compile LESS files to CSS (this task was done by WebEssentials in VS 2013).
I added a package.json file to the project to load the required components. This creates a node_modules folder in the root of the WebSite project, and this is where my problem starts:
Since WebSite projects don't have a project file, all files (and sub-directories) found in the project root folder, are automatically part of the project. Due to the deeply nested directory structure inside node_modules, this leads to errors because of too long path names.
An easy workaround is to set the hidden attribute on the node_modules folder (but this has to be done manually by each developer).
Is there a way to tell NPM to put the node modules into another directory e.g. one level above the project (..\node_modules) where the solution file is?
Or is it possible to set the hidden attribute on a folder from a gulp-task (which runs when the project is loaded)?
Based on #Rik's answer, I was able to solve the problem:
Instead of adding the package.json and gulpfile.js into the WebSite project, I added them at the solution level (as solution items). This means, that the node_modules folder is now in the solution directory at the same level as the WebSite project(s).
The only other change was to modify the paths in gulpfile.js accordingly.
You might want to check out npm 3.0+. It installs the modules in a maximally flat structure. It should reduce the paths lengths in the module directory.
From the release notes
Flat, flat, flat!
Your dependencies will now be installed maximally flat. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR
dependencies will be installed in your project's node_modules folder
with no nesting. You'll only see modules nested underneath one another
when two (or more) modules have conflicting dependencies.
#3697 This will hopefully eliminate most cases where windows users ended up with paths that were too long for Explorer and other
standard tools to deal with.
#6912 (#4761 #4037) This also means that your installs will be deduped from the start.
#5827 This deduping even extends to git deps.
#6936 (#5698) Various commands are dedupe aware now.
This has some implications for the behavior of other commands:
npm uninstall removes any dependencies of the module that you specified that aren't required by any other module. Previously, it
would only remove those that happened to be installed under it,
resulting in left over cruft if you'd ever deduped.
npm ls now shows you your dependency tree organized around what requires what, rather than where those modules are on disk.
#6937 npm dedupe now flattens the tree in addition to deduping.
https://github.com/npm/npm/releases/tag/v3.0.0
For upgrading the windows installation check out this package npm-windows-upgrade
I'm new to node.js, sails.js and grunt.js.
When I run "sails lift" it does not create the .tmp folder and copy the assets to that folder.
However, when I run "grunt" in the project folder, the .tmp folder does get created and the assets do get copied over.
Anyone have suggestions on how to fix so "sails lift" works without calling "grunt"?
Check if the sails process has the right privileges and you're not running short of space.
Also, try manually deleting the .tmp folder and lifting again. Sometimes there can be issues with automatic file removal if any of the files are in use.
When I release my Qt project, I want to redistribute the QtCore5.dll and Qtxxx.dll files.
How can I make myapp.exe to find them automatically?
The best way of doing this seems to be by editing a qt.conf file placed in the same folder as my executable.
myapp.exe is in c:\myapp\bin folder
The dlls are in c:myapp\common folder
"Better" way is to put your qt.conf into your resources :/qt/etc/qt.conf. This way has highest priority for resolving platform dependencies.
In our project we use cmake to generate necessary qt.conf file: in debug mode we put path to installed Qt binaries and in release - to local (deploy) folder.
Qt5xxx.dll files are linked, so you should place it in same folder, or make them available throught PATH environment variable. If you really want such exotic redistribution system (please, say real reason) - you may create your own platform-specific launcher, that will load necessary .dll's from any path.
Just put all required dll files into the same directory as your executable.
Note, that there are more files to distribute than just Qt*.dll - you will need proper plugin from platforms subdirectory and many more. Read Qt documentation on deploying application under Windows - it will teach you all required files.
I'm building a C++ project under Eclipse and my release folder should include a static sub-folder with some files inside it, those are required by executable during runtime. The problem is that this folder is automatically deleted before every build - entire release folder is completely wiped out and I'm losing all the files inside it.
Solution is simple - need to place rm.exe from mingw utilites on path and Eclipse will delete only specific build files instead of removing entire release folder.