I'm trying to figure out how to properly setup an ejabberd project that allows for easy compilation of custom beam files- so far, we've been using an existing project that is cumbersome to manage, and uses erlide as the IDE.
I would like to set up the project in a way that I can use a more helpful IDE like vscode, and somehow streamline the compiling and copying of the beam files and updating the module on the server.
Writing code in Elixir is fine as well- I just want the project to be set up in a way that is dev friendly.
Apologies if the question is too broad, but I'm not exactly sure how else to best phrase it. If you feel like I'm missing something in my current flow, please let me know, as I've basically inherited this project. If there are any clarifications required, let me know as well.
Thanks.
easy compilation of custom beam files
somehow streamline the compiling and copying of the beam files and updating the module on the server.
If the task is about compiling and loading additional modules, a running ejabberd node can compile, load and start additional modules in runtime, see
https://docs.ejabberd.im/developer/extending-ejabberd/modules/#ejabberd-contrib
Usually the modules come from
https://github.com/processone/ejabberd-contrib
but you can tell ejabberd to download other modules from other git repositories, or you can copy modules source code and tell ejabberd to install them. And those modules can be written in Erlang or Elixir. Full example: https://docs.ejabberd.im/developer/extending-ejabberd/elixir/#elixir-module-in-ejabberd-contrib
Basically:
you write the module in your development machine, test it...
when happy with the source code, copy mod_whatever.erl to the production machine, $HOME/.ejabberd-modules/sources/mod_whatever as explained in the example mentioned earlier
run ejabberdctl module_install mod_whatever
In step 2, instead of copying the source code yourself, you can have a git repository just for your module, tell ejabberd the module's git URL, similarly to https://github.com/processone/ejabberd-contrib/tree/master/extra
BTW, for step 3, starting in ejabberd 22.10, there's a page in ejabberd webadmin to install and uninstall those modules (copying the files requires manual administration of course).
I would like to set up the project in a way that I can use a more helpful IDE like vscode
What a coincidence, these days I'm playing with VSCode variants (VSCode, VSCodium, Coder's code-server and Github Codespaces) and how to develop ejabberd using them. This is useful for step 1 that I mentioned earlier (write module and test it). If you are interested in ejabberd + VSCode, tell me.
Related
I've created a tiny project [0] to reproduce an error in a controlled environment. The facts, I'm using jenkins to build my project, a big one, I'd like to make some parallel builds. Let me make it graphically
[MyBasicPackage] -----> [MyPackageTester] ------> [MyBasicApp]
.
.
+-----> [...]
+-----> [...]
this is the organization I've made on [0], I have a class TMyUnit (MyBasicPackage) registered on spring container to be tested. I build it and generate its .dcu, .bpl, and so on.
The second stage I build my MyPackageTester that requires MyBasicPackage. Finally I build the app that requires MyPackageTester. So far so good.
When I try to build my MyBasicPackage on, say PC-00, get the artifacts and try to build the the MyPackageTester on PC-06 (same arch, same OS, same IDE, same spring4d version), and a nice error arise:
Unit TMyUnit was compiled with a different version of Spring.Container.Registration
so, I update my spring4d on both machines (PC-00 and PC-06) and build them. Run... and same error arise.
check the library path options (C:\Program Files (x86)\Embarcadero\Studio\14.0\Componentes\spring4d\Library\DelphiXE6\Win32\Debug), delete dcu files and build them once again on both machines, same error.
copy dcu files from PC-00 to PC-06 to avoid any kind of system configuration and the same error arise.
Probably I'm trying to do something that's not possible so far. I've googled a couple of days without luck.
Any ideas?
Please feel free to fork or pull request the example ;)
Regards
[0] https://github.com/graguirre/DelphiDepencyExample
In your case you need to build with the Spring.Core runtime package. Not only will that prevent this error but your code will actually work.
If you do not then all modules will hold their own version of the GlobalContainer instance you are using and nothing will work.
Maybe one solution is put all your libraries in a centralized repository and pull them to compile your projects. It should resolve the different version error.
I am using ASP.Net MVC 5 and also taking advantage of WebEssentials LESS and bundle features.
WebEssentials is setup to create minified css and js files on save. This is a feature I want because I can monitor the output and it lowers the application startup time (not using Asp.Net MVC bundles).
How can I automatically get my app to use the minified version of the files when it is deployed without having to manually change the file names?
So, for example, from:
<link href="somestyles.css" .. >
to:
<link href="somestyles-min.css" .. >
I did read that I could combine WebEssentials and Asp.Net MVC Bundles, providing I disabled the minification option in Asp.Net MVC Bundles. This would then substitute the MIN files in production (web.config [debug="false"]).
Is this my only option or is there a better way to achieve this?
This is definitely not the only way. Another way would be to completely disconnect all Microsoft-based tools (ie bundling, web essentials, etc) and use a Javascript Task Runner. Then the compiling of supersets and pre-processers, minification and whatever other front-end heavy lifting can be in one place. It can also be based on the environment.
So let's address some of your specific concerns.
Task running in the flavor of nodejs and gulp
Download nodejs
After downloading, open up a command prompt and navigate to your project source. For example:
cd "C:\Users\beloud\Documents\Visual Studio 2013\Projects\YourProject"
Initialize a node project by running npm init. This will ask you a bunch of questions about your project. After completion, it will create a file, package.json, which will track your node dependencies and project details.
Now we need to install a few packages. In the command prompt, enter the following commands:
npm install gulp -g
npm install gulp --save-dev
npm install gulp-less --save-dev
npm install gulp-minify-css --save-dev
npm install gulp-if --save-dev
We install gulp globally, so we can use it anywhere (it will add a path for you). Then we install a handful of packages locally to our project that will be doing that actual work (minifying, processing, etc).
Create a file in the same directory as your package.json named gulpfile.js.
Now we need to create our actual tasks. In gulpfile.js, add the following:
//these are the modules that we'll be using in our task
var gulp = require('gulp'),
less = require('gulp-less'),
gulpif = require('gulp-if'),
minifycss = require('gulp-minify-css');
var isDebug = true; // I usually have a config.js file that has this and some handy static paths that I'll be referencing regularly. Then I just require it above.
gulp.task('default', function() {
return gulp.src('Content/less/**/*.less')
.pipe(less())
.pipe(gulpif(isDebug === false, minifycss())) //the first argument is the condition, the second is the method to call if the condition is true
.pipe(gulp.dest('Content/css'));
});
Run gulp in command prompt. That will run the default task. Basically, it will look for any less files in all directories under Content/less, compile them to css, minify them if isDebug is false and output it to Content/css.
Let's make it a little bit more awesome by adding a watch. Add the following to gulpfile.js:
gulp.task('watch', function() {
// Watch .less files
gulp.watch('Content/less/**/*.less', ['default']);
});
Upon running gulp, the task will stay alive until manually terminated. It will watch for changes made to any less file in Content/less and will re-run the task upon saved changes.
Now, you just need to include the name of the css file as it will remain the same, regardless of the environment.
This is a very basic example of using a task runner to achieve what you're trying to do. You can do a whole lot more with nodejs, gulp and everything else I've referenced. I would personally suggest this because, it is way more powerful than the one-off tools you're currently using and Visual Studio 2015 is already heavily relying on this new methodology so you'll most likely have to learn this anyways.
You can learn more by following this really amazing tutorial, Getting started with gulp, by Mark Goodyear.
Grunt (and gulp) support is added in the next Visual studio. This is the javascript developers tools for doing the same thing - bundling for production.
Grunt can create a build version that is not minified for testing but minified for production. I might take some more time and effort but it is the future instead of the MS try they did with bundling. You can already use grunt if you have Node.js installed and be ready for the future.
There is plenty of getting started resource out there. See also Introducing Gulp, Grunt, Bower, and npm support for Visual Studio
Is this my only option or is there a better way to achieve this?
It's not your only option, but since you are working in the realm of MVC it's one of the better options. Since it is designed to be leveraged at different levels, such as individual pages as well as layouts, it will take care of generating the appropriate link.
In general, I would recommend you use a server side bundling framework oriented to MVC so that it can handle the link generation and gives you an intuitive API.
SquishIt is an open-source framework that integrates well with MVC, and is also capable of being switched based on criteria such as a debug flag to generate the original source versus minified versions.
Both SquishIt and the new builtin MVC bundles are fairly similar in terms of what they are meant to accomplish.
I'm new in JAVA\Grails\Groovy. Just began to create simple apps.
I've got a task to create grails app that:
1) shows a list of source zip files on a remote server, that is available by FTP and SSH
2) shows a list of destination remote servers with predefined target folders, that are available only by SSH
3) after choosing source zip and dest server it copies zip to target server\folder and unzippes. Progress bar must be shown.
4) performs some additional commands, such as ls or something like that
All configurations must by either in config files or in the database.
No information should be hardcoded in app.
Please help me to choose approach, plugin or framework.
Any help would be appreciated
I've used JSch a lot for SCP file transfer and remote exec using SSH and works very well. You could use it directly like you would in a Java app, by adding a dependency for the jar in BuildConfig.groovy
compile 'com.jcraft:jsch:0.1.51'
but the most trivial Google search I could manage that included "Grails" and "SSH" tells me that there's this plugin which looks great, and this plugin which also looks great, and this blog post which looks great, and also this plugin which uses a different library but also looks great.
Those options cover the ssh and scp/sftp parts, and you can use the JDK support for Zip files, e.g. java.util.zip.ZipFile and the other related classes in that package, to unzip the files. The rest is pretty straightforward, but if you need more help ask more questions (one question per question).
Do you use CEAN, copy the source and compile them, copy the BEAM files, or something else. I need to distribute some Erlang code and I'm not sure which to choose.
I've been working on EPM, an Erlang package manager. It pulls from GitHub. It's non-invasive and doesn't require installing anything on your system other than downloading an escript. It works as follows:
jvorreuter$ ./epm install ibrowse mochiweb
epm v0.1.0, 2010
===============================
Install the following packages?
===============================
+ epm-mochiweb-master
+ cmullaparthi-ibrowse-master
([y]/n) y
+ downloading http://github.com/epm/mochiweb/tarball/master
+ running mochiweb build command
+ running mochiweb install command
+ downloading http://github.com/cmullaparthi/ibrowse/tarball/master
+ running ibrowse build command
+ running ibrowse install command
You can read more about it at http://www.jkvor.com/erlang-package-manager
The linked blog post is blank as of August 2013. The GitHub repository is at https://github.com/JacobVorreuter/epm
I clone the git repository, build it, and add the directory to my ERL_LIBS path. I hack the source for my private customizations. For those commits that are sensible, I publish.
I am a much happier developer after finding git and being able to manage my own changes and still be able to get upstream changes that I can rebase my stuff on.
I realize that this looks raw for end users, but I am my own end user.
If I would ship something to other end users I would look into using .ez zip archive files that the erlang code loader can use. See section "Loading of Code From Archive Files" on that page. Then provide a script that invokes erl with the correct arguments.
If the repository isn't available as a git, I git-svn clone it. If I can't do that, I tend to stay away from it.
I use faxien (a package manager for Erlang releases and applications) from the Erlware project: http://www.erlware.org. It and sinan are essential tools for Erlang development :).
I use Agner on Mac, Linux, and Unix; and CEAN on Windows. CEAN's the only Erlang package manager with Windows support.
I package them on a Debian repository on Launchpad.
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").