Some libraries don't have an already build JavaScript file in their Github repository because the authors of these libraries are against keeping build artifacts around (Sinon.JS for example). Is there a preferred way to deal with this using Bower?
I know that I could fork the repository and register my fork with the prebuilt file with Bower. I'm just not sure if this is the best/correct way to handle this.
If there's not a proper Bower package registeres, you can install from any git repo (you can specify versions if there are proper git tags), and even from a .zip or .tar.gz files if you provide an url.
This is from http://bower.io/
bower install <package>
Where <package> can be any one of the following:
A name that maps to a package registered with Bower, e.g, jquery.
A remote Git endpoint, e.g., git://github.com/someone/some-package.git. Can be public or private.
A local Git endpoint, i.e., a folder that's a Git repository.
A shorthand endpoint, e.g., someone/some-package (defaults to GitHub).
A URL to a file, including zip and tar.gz files. It's contents will be extracted.
Of course you won't get any dependency resolution this way, but you can take care of that manually adding any dependency explicitly to your bower.json file
Currently that is the best way. You can also keep it locally and reference it in 'dependencies' with full path. We're working on adding ability for author to publish components, like npm.
Related
I have made a ROS workspace and inside a package.
I did catkin_make and everything is working well.
I would like to give this package (or should I give the entire workspace?) to another person.
I am thinking to give him a zip file of the files and folders (it contains launch files, python scripts, rviz files etc) so I am expecting he will unzip it in his machine
I would like he can run the launch files without problems
What is what he needs to do for this? (of course he will have ROS installed, that is no problem)
I am thinking perhaps he should do source devel/setup.bash but is this enough?
When sharing a workspace with somebody only the source space src has to be shared. It should contain all our packages with their launch files (*.launch), Python (*.py) and C++ nodes (*.cpp, *.hpp), YAML configuration files (*.yaml), RViz configurations (*.rviz), robot descriptions (*.urdf, *.xacro) and describe how each node should be compiled in a CMakeLists.txt. Additionally you are supposed to keep track of all the Debian packages you install inside the package.xml file of each package.
If for some obscure reason there are things that I have to do that can't be accommodated in the standard installation instructions given above, I will actually write a bash script that performs these steps for me and add it either to the package itself or the workspace. This way I can automate also more complex steps such as installing OpenCV or modifying the .bashrc. Here a small example of what such a minimal script (I generally name them install_dependencies.sh) might look like:
#!/bin/bash
# Get current workspace
WS_DIR="$(dirname "$(dirname "$(readlink -fm "$0")")")"
# Check if script is run as root '$ sudo ...'
if ["$EUID" -ne 0]
then
echo "Error: This script has to be run as root '$ sudo ./install_dependencies.sh'
exit 1
fi
echo "Installing dependencies..."
# Modify .bashrc
echo "- Modifying '~/.bashrc'..."
echo "source ${WS_DIR}/devel/setup.bash" >> ~/.bashrc
echo ""
echo "Dependencies installed."
If for some reason even that is not possible I make always sure to document it properly either in a Markdown *.md read-me either in a /doc folder inside your package, in the read-me.md inside the base folder of your repository or inside the root folder of your workspace.
The receiver then only has to
Create a new workspace
Copy or clone the package files to its src folder
Install all the Debian package dependencies listed in the package.xml files with $ rosdep install
(If any: Execute the bash scripts I created by hand $ sudo ./install_dependencies.sh or perform the steps given in the documentation)
Build the workspace with $ catkin_make or $ catkin build from catkin-tools
Source the current environment variables with $ source devel/setup.bash
Make sure that the Python nodes are executable either by $ chmod +x <filename> or right-clicking the corresponding Python nodes (located in src or scripts of your package), selecting Properties/Permissions and enabling Allow executing file as program.
Run the desired Python or C++ nodes ($ rosrun <package_name> <executable_name>) and launch files ($ roslaunch <package_name> <launch_file_name>)
It is up to you to share the code as a compressed file, in form of a Git repository or a more advanced way (see below) but I will introduce some best practices in the following paragraphs that will pay off in the long run with larger packages.
Sharing a package or sharing a workspace?
One can either share a single package or an entire workspace. I personally think that most of the time one should share the entire workspace instead of the package alone even if you only cloned the other packages from a public Github repo. This might save the receiver a lot of headache e.g. when checking out the wrong branch.
Version control with Git
Arguably the best way to arrange your packages is by using Git. I'd actually make a repository for every package you create (if a couple of packages are virtually inseparable you can also bundled them to a single Git repo or better use metapackages). Then create an additional repository for your workspace and include your own packages and packages from other sources as submodules. This allows your code to be modular and re-usable: You can share only a package or the entire workspace!
As a first step I always add a .gitignore file to each package repository which excludes *.pyc files and another one to the workspace repository that ignores the build, devel and install folders.
You can add a particular repository as submodule to your workspace Git repository by opening a console inside the src folder of your workspace repository and typing
$ git submodule add -b <branch_name> <git_url_to_package> <optional_directory_rename>
Note that you can actually track a particular branch of a repository that you include as a submodule. In case you need a submodule at some point follow this guide.
If you share the workspace repository with someone they will have to have access to each individual submodule repository and they will have to not only pull the repository but also update the submodules with
$ git clone --recurse-submodules <git_url_to_workspace_repository>
and potentially update them to the latest commit with
$ git submodule update --remote
After these two steps they should have a full version of the repository with submodules and they should be able to progress with the steps listed in the section above.
1.1 Unit-testing and continuous integration
Before sharing a repository you will have to verify that everything is working correctly. This can take a decent amount of time, in particular if the code base is large and you are modifying it frequently. In the ideal case you would have to install it on a brand new machine or inside a virtual box in order to make sure that the set-up works which would take quite some time. This is where unit testing comes into play: For every class and function you program you will write a test. This way you can simply run these tests and make sure everything is working correctly. Generally these unit tests will be performed automatically and the working branches merged continuously. Generally the test routines are written with the libraries Boost::Test (C++), GoogleTest (generally used in ROS with C++), unittest (for Python) and QtTest (for GUIs). For ROS launch files there is additionally rostest. How this can be done in ROS is described here and here.
ROSjects
If you do not even want the person you are sending the code to to go through the hassle to set it up you might consider sending them a ROSject. A ROSject is an online virtual ROS environment (by the guys behind The Construct, the main source of ROS courses and of ROS tutorials on Youtube) that can be created and shared very easily from your existing Git repository as can be seen here. The simulation runs entirely in the cloud on a virtual machine. This way the potential of failure is very low but it is not a choice if your code is supposed to run on hardware and not only in simulation.
Docker
If your installation procedure is complex you might as well use a container such as a Docker.
More information about using Docker in combination with ROS can be found here. The Docker container might introduce though a bit of overhead and it is probably no choice for code which should have real-time priority in combination with a real-time patched operating system.
Debian or snap package
Another way of sending somebody a ROS package is by packing it into a Debian or snap package. This process takes a while and is in particular favourable if you want to give your code to a large number of users that should use the code out of the box. Instructions on how this can be done for Debian packages can be found here and here, while a guide for snap can be found here.
I'm trying to get Bower to install this javascript:
https://github.com/markmalek/Fixed-Header-Table
I use: bower install git#github.com:markmalek/Fixed-Header-Table.git --save
It installs the package into bower-components, and even adds it to my project's bower.json, but it doesn't add the to my html. I'm guessing it's because that particular git repo doesn't contain a bower.json telling my project which js file is the main one. So how do I install this package?
Thanks!
This answer takes your assumption that your HTML is picking up scripts loaded via Bower using the bower.json file as correct.
There are two options. The quickest is to fork the repo yourself, and in the main directory use the command bower init to create your own bower.json file in your forked version of the repo. Then, change the github url to the repo to your forked version rather than the original you have above.
The second option is to submit a pull request to the package owner adding a bower.json file so that you can continue to pull directly from his repo.
There are probably more options like manually loading the script outside of pulling from a bower.json file but the two above seem simplest.
I'm trying to create a nuget package for the localization of another package, and I'm following the satellite package approach.
I'm pretty sure to have followed these rules strictly, and the naming conventions as well, but as I download the satellite package from my nuget repo server, it's not adding the expected /it/ folder under the /lib/ folder of the main package.
The main files structure is the following
/lib/net45/myfile.dll
and the satellite package has
/lib/net45/it/myfile.resources.dll
I tried everything, and I double check my packages configurations with the AspNet.Mvc.5.1.1 package and its satellites. They're the same...
I'm wondering if the problem could be on the NuGet server (but sounds weird to me)?
The server version is v2.8.50126.400
UPDATE
So it really seems to be the Server, as if I use a local path (C:...) as repo source, the packages act as expected.
Anyway I've just used the NuGet.Server package to create the server, there's some particular configuration I missed?
The problem was the NuGet.Server .
There's a field missing during the serialization of the feed, the Language, that's why the official packages are working: on the official server the Language field IS serialized, that allow the NuGet client to move the resource assembly to the right folder under the main package's lib folder.
But on a private repository built with the NuGet.Server package this field is just missing.
I've applied a pull request on Codeplex, for the ones who have the same issue.
https://nuget.codeplex.com/SourceControl/network/forks/tanathos/nuget/contribution/6524
I am trying to use Bower to manage client side dependencies from a Java/JSP server side application.
It works and I can access client side libraries resolved via "bower install" as described in bower.json.
However, lots of unnecessary files are added to "bower_components" as declared by the dependencies used (tests, docs, examples, etc).
Q: Can I manually specify filters to include/exclude files from each dependency I declare in bower.json?
If this is not possible, it sounds like i need to resolve "bower install"'s output outside the webapp directory and create a separate (maven/grunt) copy task to create the js lib files structure I want - sounds tedious.
You can use bower-installer which allows you to copy only the files you want by specifying filters to include/exclude files from each dependency in bower.json
I have no experience with maven, so excuse me if this question is silly...
From another question (How does Grails handle plugin dependencies), I've learned that I can avoid the jar-hell in grails through maven repositories. But I now have the requirements that...
I am not allowed to use remote maven repositories
I would like to bundle the needed jars with my plugin (but low priority)
I would like to avoid the effort to install a local maven repository
I already worked with a reference to a local folder for plugin resolution. This works great.
But how do I have to structure a local folder in order to use this option:
repositories {
flatDir name:'myRepo', dirs:'/path/to/repo'
}
I mean, I could just drop the jar files to this folder, but how do I then reference those jar files? Do they have a naming schema like artifact_version.jar? Or do I have to create an XML configuration for this local repository?
Or is the effort to use a local maven repo small and maven is even already on my machine through grails?
The fact is Maven comes already with a local repository (~/.m2 on linux boxes). If you don't have access to an external repo, you just have to install your jars in the local repo, with this command
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>
is 'jar' (without quotes) and group-id and artifact-id are either determined if it's 3rd-party library (go make a search on mvnrepository.com if you don't know them for a particular library) or you put there your group and artifact ids
EDIT : In fact, the naming scheme under the repository is for the library example version 1.2 from jexample.com is usually com/jexample/example/1.2/example-1.2.jar (groupId : com.jexample, artifactId : example, version : 1.0)