I like Yeoman's features like the Package Manager (Bower), Livereload integration, Compass, etc.
Therefor, I'd like to use it to handle my public website. However, instead of using the "app" folder, I would like to put everything at the root.
I've changed the references in the grunt configuration file but still get errors when installing new package and building.
Is it possible to change the project structure?
Not as easy as it could be at the moment, but we're working on making it easily customizable.
Though I don't think you would need to. You develop in the /app folder and deploy the contents of the built /dist folder. That way it's still in the root on your server.
Related
I want to make Dart app that has flexible deployment. It can be started as a web server or standalone app in browser as well. My directory structure:
bin
- httpserver.dart
lib
- commonlib.dart
web
- web.html
- web.dart
pubspec.yaml
I wanto start either httpserver.dart providing web's content or web.html directly in Chromium. I have troubles with the lib visibility from bin/httpserver.dart. using the "import 'package:prj/commonlib.dart'" does not work. But from the web.dart is works fine.
Please advice how to share libs among bin's and web's code. Or I should I make structure of dirs somehow different?
Note: there is no packages sub-dir in the bin directory created by pub get. I am using dart sdk 1.7.2.
Thank you, Ladislav.
In the bin directory there should be a packages symlink created automatically but it is not in subdirectories of prj/bin. If the symlink isn't created just create it manually.
My problem is I can't link to the bower_componets folder.
I am using web-starter-kit, and basically took those files into my dev environment/folder structure. I know that defeats the purpose of WSK, however I created a gulp work flow and wanted to try it out.
This is what i get in the console.
And this is my folder structure...
I am positive based on where the 'bower_components' folder exists this should be the path.
<script src="../../app/_bower_components/flowtype/flowtype.js"></script>
e.g. Start out of in development, then out of builds and dive into 'app'
Is there a bower config file that I am supposed to create?
The app I work on needs to use the wpftoolkit.extended.dll (i.e. no source, no msi/installer, we've only got the dll). So far we've placed the dll in a c:\libs folder on both the dev's laptop and the teambuild server and it built ok on both; now for deploying we want to add it to an installer (.vdproj) and we think we'll need it in tfs's repository somewhere. However, when tested the app now only builds on the dev's laptop and not on the teambuild server (looks like a relative path thing).
So... rather than fixing the actual problem, I'm wondering what's the best/cleanest/commonlyAccepted way to do this? where should I keep the dll in the repository and where should I place the dll on the host we're deploying to?
You should use folder structure on the source control like the following
/Main Contains the .sln file
/Source
/MyApp1 Contains MyApp1.sln file
/Source Contain folder for all
/ClassLibrary1 Contains ClassLibrary1.csproj
/MyApp1Web Contains Default.aspx
/Build Contains build output (binaries)
/Docs Contains product docs etc
/Tests
**/3rdpartyDlls** Contains all vesions of third-party dlls
For more information about the source control folders and best practices, it's recommended to read the book patterns & practices Team Development with TFS Guide (Final Release)
When managing a grails plugin in Intellij Idea (I'm using version 10.5.2 on OSX, if it matters), I can't get it to add the *GrailsPlugin.groovy file to the classpath in a way that it can be recognized by unit tests run from the IDE. The tests run fine from the command line using grails test-app; I just want IDEA to be able to run them too.
The problem is that the *GrailsPlugin.groovy file is at the top level directory in the plugin, which is not marked as a source directory in IDEA. I definitely don't want to make it a source folder, since that will screw up lots of things such as the package path to all of my regular source files (amongst many other issues).
I've tried adding *GrailsPlugin.groovy to my Settings->Compiler Resource Patterns, but to no avail. Since the file isn't in a source folder, it's ignored.
I tried creating a source folder that has a symlink to the *GrailsPlugin.groovy file, but that introduces all kinds of synchronization issues.
Anyone have any ideas?
I have an erlang application I have been writing which uses the erldis library for communicating with redis.
Being a bit of a newbie with actually deploying erlang applications to production, I wanted to know if there was anyway to 'bundle' these external libraries with the application rather than installing into my system wide /usr/lib/erlang/lib/ folder.
Currently my directory structure looks like...
\
--\conf
--\ebin
--\src
I have a basic Makefile that I stole from a friend's project, but I am unsure how to write them properly.
I suspect this answer could involve telling me how to write my Makefile properly rather than just which directory to plonk some external library code into.
You should really try to avoid project nesting whenever possible. It can lead to all sorts of problems because of how module/application version is structured within Erlang.
In my development environment, I do a few things to simplify dependancies and multiple developed projects. Specifically, I keep most of my projects sourced in a dev directory and create symlinks into an elibs dir that is set in the ERL_LIBS environmental variables.
~/dev/ngerakines-etap
~/dev/jacobvorreuter-log_roller
~/dev/elib/etap -> ~/dev/ngerakines-etap
~/dev/elib/log_roller -> ~/dev/jacobvorreuter-log_roller
For projects that are deployed, I've either had package-rpm or package-apt make targets that create individual packages per project. Applications get boot scripts and init.d scripts for easy start/stop controls but libraries and dependancy projects just get listed as package dependencies.
I use mochiweb-inspired style. To see example of this get your copy of mochiweb:
svn checkout http://mochiweb.googlecode.com/svn/trunk/ mochiweb
and use
path/to/mochiweb/scripts/new_mochiweb.erl new_project_name
to create sample project of the structure (feel free to delete everything inside src afterwards and use it for your project).
It looks like this:
/
/ebin/
/deps/
/src/
/include/
/support/
/support/include.mk
Makefile
start.sh
ebin contains *.beam files
src contains ***.erl files and local *.hrl files
include contains global *.hrl files
deps contains symlinks to root directories of dependencies
Makefile and include.mk takes care of including appropriate paths when project is built.
start.sh takes care of including appropriate paths when project is run.
So using symlinks in deps directory you are able to fine tune the versions of libraries you use for every project. It is advised to use relative paths, so afterwards it is enough to rsync this structure to the production server and run it.
On more global scale I use the following structure:
~/code/erlang/libs/*/
~/code/category/project/*/
~/code/category/project/*/deps/*/
Where every symlink in deps points to the library in ~/code/erlang/libs/ or to another project in the same category.
The simplest way to do this would be to just create a folder named erldir and put the beams you need into it and then in your start script just use the -pa flag to the erlang runtime to point out where it should fetch the beams.
The correct way (at least if you buy into the OTP distribution model) would be to create a release using reltool (http://www.erlang.org/doc/man/reltool.html) or systools (http://www.erlang.org/doc/man/systools.html) which includes both your application and erldis.
Add the external libraries that you need, anywhere you want them, and add them to your ERL_LIBS environment variable. Separate the paths with colon in unix or semicolon in dos.
Erlang will add the "ebin"-named subdirs to its code loading path.
Have your *.app file point out the other applications it depends on.
This is a good halfway-there approach for setting up larger applications.
Another way is put your lib path in ~/.erlang.
code:add_pathz("/Users/brucexin/sources/mochiweb/ebin").
code:add_pathz("/Users/brucexin/sources/webnesia/ebin").
code:add_pathz("./ebin").
code:add_pathz("/Users/brucexin/sources/erlang-history/ebin/2.15.2").