We're working on a project that has some Clojure-Java interop. At this point we have a single class that has a variety of dependencies which we put into a user library in Eclipse for development, but of course that doesn't help when using Leiningen (2.x). Most of our dependencies are proprietary, so they aren't on a repository somewhere.
What is the easiest/right way to do this?
I've seen leiningen - how to add dependencies for local jars?, but it appears to be out of date?
Update: So I made a local maven repository for my jar following these instructions and the lein deployment docs on github, and edited my project.clj file like this:
:dependencies [[...]
[usc "0.1.0"]]
:repositories {"usc" "file://maven_repository"}
Where maven_repository is under the project directory (hence not using file:///). When I ran "lein deps"--I got this message:
Retrieving usc/usc/0.1.0/usc-0.1.0.pom from usc
Could not transfer artifact usc:usc:pom:0.1.0 from/to usc (file://maven_repository): no supported algorithms found
This could be due to a typo in :dependencies or network issues.
Could not resolve dependencies
What is meant by "no supported algorithms found" and how do I fix it?
Update2: Found the last bit of the answer here.
add them as a dependency to your leiningen project. You can make up the names and versions.
then run lein deps and the error message when it fails to find it will give you the exact command to run so you can install the jar to your local repo then sould you decide to use a shared repo you can use this same process to put your dependencies there.
#Arthur's answer is good but I figured I'd flesh it out a bit more since it leaves some details lacking.
Always keep in mind Repeatability. If you don't make it so that anyone who needs access to the artifacts can get access to the artifacts in a standard way, you're asking for support hell.
The documentation on deployment is a good place to go to find out everything you need to know about deploying your artifacts. Since you're in a polyglot environment you probably can't have lein take care of deploying all your artifacts but at least you can get your clojure specific jars up into S3 or even a file share if you like. The rest of your artifacts will have to use Maven or Ant directly to upload the artifacts to the Maven repo on the file server or S3. At my current company we are using technomancy's excellent s3 wagon private to great effect for hosting our closed source artifacts and clojars for hosting anything that we can open-source.
What #Arthur is referring to is doing a lein install. All that does is install a copy of the current project into your local .m2 directory so that other projects on your box can reference them. Unless you have configured your install of maven to use a shared directory for your .m2 folder (maybe not a bad idea in your environment?), this will mean that anyone else who checks out your project will not be able to build it. If you wanted to go this route, you need to set the localRepository node in your $M2_HOME/conf/settings.xml to be the shared location that the rest of your team has access to. See the docs for more information.
YMMV but I've found it best to use Maven rather than Leiningen when you are working with Polyglot Clojure / Java projects.
It's mainly because the Java based tools (Eclipse etc.) understand Maven projects but don't really understand Leiningen projects. It's getting slowly better with the excellent Counterclockwise Clojure plugin, but the integration still isn't quite good enough yet for an efficient IDE based workflow.
On the repository side of things, I'd suggest setting up a private shared Maven repository. You're going to need it sooner or later if you plan to manage a complex set of dependencies within your team: might as well bite the bullet and get it done now.
Related
When there is just one go repository and it imports only public dependencies, deploying to (for example, a Docker container on AWS) is extremely straightforward.
However, I have a question about how to use subpackages with go.
Suppose we have a monorepo with 3 packages.
/src
- /appA
- /appB
- /someSharedDep
How are deployments typically built so that you deploy appA and someSharedDep to one server and appB and someSharedDep on another server?
I imagine there needs to be some creative employments of our friend the GOPATH, but some help on the topic would be appreciated.
Bonus points if we're talking about an elastic beanstalk deployment.
Suspicions
I have some thoughts on how to approach the problem now (and I'll add more or submit an answer if this becomes more complete).
Use vendoring, this means you have the source code of all your dependencies checked into your own repo. It doesn't sound good (esp. if you're used to NodeJS) but it works.
Now that you use vendoring, vendor your own submodules into the ./vendor folder in the application. Yes you will have copies of the same code in two places but whatever.
Create automated scripts to help manage some of these things. I'm still looking for tools that make vendoring more convenient.
Some problems I still face:
When vendoring, sometimes the dependency has files that have a main() function or declare package main, usually in an ./example subfolder. These have to be removed manually. I don't like editing the working source of someone else's project though!
I'm new to build tools and gradle. I'm currently developing for android. I've found a library on Github I would like to use in my app.
What is the best way to create this dependency? The library doesn't have ant, maven or even gradle support.
Some options that came to my mind:
1) Fork the repo and add gradle support.
2) Clone the repo and add maven support then add it to the local maven repo.
What do the experts think how to handle such dependencies?
If the library only publish sources, not binaries, you don't have any other option rather than build it yourself.
Once you did that, you can host the binary in binary repository (like Artifactory) for sharing it with your colleagues, or even publish it on a distribution platform (like Bintray) for anyone who want to use it. For the later, you'll be able to pass the ownership (and the maintenance burden) to the original author in any moment.
I am trying to compile some projects on the twitter storm platform using leiningen. The servers I am working on do not have access to internet. I was wondering if it is possible to work offline by making a local repository by downloading all dependencies.
Short answer is yes, you should be able to do this by just putting the dependencies where lein expects to find them and then it will use them instead of going out to download them. That said, I've never tried this.
It looks like the answer to this question pretty much points to how to do it:
Run lein deps on a machine that is connected to the Internet
Copy $HOME/.m2/repository to your server
and that should take care of it. However, I have not tried this, so there may be some problem with this method that I have not foreseen.
I need to use the mongo-storm library and Clojars doesn't have it. So I cloned the project, compiled and copied the jar to my lib folder by hand. But it is a team project and it is unacceptable for every member to do those steps by hand.
Are there any better and standard ideas on how to solve this issue?
Your team should have a private repository for this purpose. S3 is an ideal substrate for this, and you can use the s3-wagon-private Leiningen plugin to deploy and consume artifacts to/from a secured S3 bucket:
https://github.com/technomancy/s3-wagon-private
If the project has a license that allows it (if it's open source) you are allowed to push your own unofficial version to Clojars yourself using your own group ID. Clojars reserves the "org.clojars.username" group IDs for this purpose. This is described in https://github.com/ato/clojars-web/wiki/tutorial and https://github.com/technomancy/leiningen/blob/master/doc/DEPLOY.md .
The best way would probably be if you could contact the author and to urge him/her to do a proper release. (Also, the readme doesn't tell what license the project has.)
A solution that doesn't require setting up a private repository would be to leverage the checkouts capability in leiningen.
Ideally, if your team is using a maven based dependency management system (like Leiningen), you would have a repository manager set up. You can then deploy the library to your team's repository manager.
Most repository managers have Maven Central already included and make it easy to both add additional repositories to proxy (e.g. Clojars) and host your own repositories (for mongo-storm and the project being developed).
After getting one set up, one of the things you'll want to make sure your team does is either set as a repository proxy or as an additional repository to pull jars from.
You can find a list of repository managers on the maven site.
Question 1:
I am about to deploy my first Django website and I was wondering what tools are recommended to gathering all your Django files.
Like for example I don't need my sass and coffeescript files I just want the compiled css and js files. I also want to use the correct production settings file.
Question 2:
Do I put these files ready for deployment into their own version control repository? I guess the advantage is that you can easily roll back changes?
Question 3:
Do I run my tests before gathering the files or before deploying?
Shell scripts could be a solution but maybe there is a better way? I looked at jenkins/hudson but that seems more like a tool that sits on top of the tools that I am looking for.
For questions one and two, I'd recommend using a version control system for this. I'm sure you're already using some sort of version control, so you can just say which branch of your repository you would like to deploy. And yes, this makes rollbacks incredibly easy. Probably the most popular method for Django deployment is to package your files using git, and then deploy these files and run any deployment scripts using fabric.
Using git, packaging your files using your local repository would look something like:
git archive --format=tar HEAD | gzip > my_repo.tar.gz
Alternately, you can first push your changes to a github repository, and then in your deployment script just clone your repository from your production server.
For your third question, if you use this version control method for packaging your files, then just make sure when you are testing you have the deployment branch checked out.
I'll typically use Fabric for deploying most Django projects:
http://docs.fabfile.org/en/1.0.0/?redir
It has a decent api for communicating with remote servers and it's all in Python – bonus!
You don't need to store your concatenated media files in a separate repo. They're only needed for production. In that case I've found libraries like django-mediasync and django-compress to be useful. They both provide template tags/settings that can concatenate and cache your static files for you depending on the DEBUG setting/environments (production vs development).
You can run your tests whenever. Some people will run them as a version control hook to prevent broken code from being checked in or during deployment, stopping the deployment in case of test failure.