Right now, whenever I execute the sbt docker command of the sbt-docker plugin within my project, it generates the artifacts (dockerfile and jars) under the [app-route]/target/docker/ folder.
Is there a way to change that "default" route, so It can generate the artifacts elsewhere? Let's say, in [app-route]/docker instead?
You can change the staging directory by setting target in docker, for example target in docker := "docker".
Thanks to the creator of the sbt-docker plugin that answered the question here.
Related
We have a Scala project which we are building via CI tool (TeamCity/Jenkins). We are looking for an ability to set the build version of the artifact from the build job itself and not depend on the entry in build.sbt file. To give a reference, for java maven builds we can use goal set-version where the artifact version is set, irrespective of what we have in pom.xml. we are looking for something similar for a SBT build as well.
I'd reccoment to take a look at next sbt plugins:
https://github.com/dwijnand/sbt-dynver
https://github.com/sbt/sbt-git
Our team uses sbt-dynver to create version from Git, because it is easier. I'd recommend to build version on top of git tags information rather then using CI tool (TeamCity/Jenkins) information - like build number, because you can build same version twice for instance.
Also, consider using https://github.com/sbt/sbt-buildinfo - additionally, so to expose build version though API or print to output to quick identify currently deployed app version.
This isn't really the right forum for this kind of recommendation, but you could start by looking a sbt-git which will set version numbers based on GIT tags.
One option your have, is to add this to your build.sbt:
version := sys.env.getOrElse("ARTIFACT_VERSION", "0.0.0-SNAPSHOT")
Then setting the version you want at the environment variable ARTIFACT_VERSION.
I want to make a custom buildpack on bluemix, as part of it I am trying to add my own jar file as a javaagent. I used to work with Tomcat where I just added the extra agent to the catalina.sh script.
On bluemix those are the steps I took:
I create new project and uploaded my code.
I cloned the default java buildpack to my own git repository.
On the repository I added the .jar file on /lib/java_buildpack folder.
Now is the step I have trouble with, I located the:
java_opts.add_javaagent(#droplet.sandbox + 'javaagent.jar')
function call which according to the comments should so exactly what I am looking for.
the issue is that when I check the function I see that it calls the following function:
qualify_path(path, root = #droplet_root)
"$PWD/#{path.relative_path_from(root)}"
I cant figure out where is this #droplet_root position is, if I could find it I could upload my jar file there.
I tried adding the relative position like this:
java_opts << "java_buildpack/myAgent.jar"
But it didnt work.
Any suggestions on how it might be achieved? where should I place the file or is there any other way?
Forking the buildpack is one way to achieve this. You can implement this as a "framework" in the Java buildpack. Here are a few samples you can refer to which also adds an agent jar:
https://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/framework/new_relic_agent.rb
https://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/framework/jrebel_agent.rb
Another little hacky way is to simply add the agent jar to your application package, and then add a Java option to enable the agent, using the JAVA_OPTS environment variable. That requires you to find out the path where the agent jar ends up in the running application container. You can browse to it by using "cf files". This will have a dependency on the internal structure of the droplet so it may get broken if the buildpack changes the droplet structure.
I want to be able to compile my project once and pass it through multiple build steps on a CI server. But SBT puts files in a staging area like the one below.
/home/vagrant/.sbt/0.13/staging/
This means the project is not stand-alone and for every CI step it is going to compile it again.
How can I tell SBT to keep things simple and stand-alone and to make sure everything it needs is inside the project directory?
FYI, the staging area is used for the target files when the source folder is not read/write. Making the source folder read/write should fix this.
If you pass -Dsbt.global.staging=./.staging to sbt when starting it up, the staging directory will be .staging in the project's directory.
I figured that out by looking at the sbt source and patching that together with how Paul P's sbt runner passes the value for the sbt boot path.
If that doesn't accomplish what you want, then you might be able to make something go with a custom resolver. The sbt Build Loaders page talks about creating a custom resolver that lets you specify more detail about where dependencies are written. If my solution doesn't get you what you want, you'd probably need to do something like that.
As a scaffolding tool, the official release has a size of 238MB , which is too big and I already have an repo on my local, why activator ships another repo and continue downloading the existing dependencies into it?
The launcher is actually really small, < 50K, is it possible to use it like sbt, just use the activator launcher to achieve the same functions as in the full release?
Yes. The repository is only their for convenience. The actual size of the "bootloader" of Activator is something like 2Mb. If you delete the "repository" directory from the activator zip, then everything will still work, but dependencies will be downloaded on demand.
Another hidden feature is if you download a particular template from the website (see go to http://typesafe.com/activator/template/activator-akka-spray and click the download link), you'll get a a launcher for activator which is standalone.
The activator.bat/activator/activator-launcher-<version>.jar files are the only portion of the distribution you really need to run.
I'm evaluating Maven 3 at work. For several example projects I have to deploy them to a server (no repository), but that's not the problem.
In my current example-project I'm trying to upload only the "jar-with-dependencies".
and exactly that's my problem.
It all works fine, except that the main-artifact AND the jar-with-dependencies (created by the assembly-plugin) are uploaded.
How do I prevent Maven or rather the deploy-phase from uploading the main-jar and only upload a given or specified file (in this case, the assembly-file "jar-with-dependencies")?
Referring to the question Only create executable jar-with-dependencies in Maven, I can't just alter the packaging-setting to pom, because it will also prevent the assembly-plugin from adding my classes to the JAR file. It only creates a JAR file with the files of the dependencies.
I hope I'm clear about my problem, and you can help me ;)
if you just looking how to add a file to be deployed you can take a look here:
http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html
May be this helps. If not express your needs more in detail.
There seems to be no way to configure the deploy plugin to filter out some of the artifacts from a project and selectively deploy the others. Faced with a similar problem, we solved this with the ease-maven-plugin. It fit well into our release process but might not be the right choice for everyone as it mandates a two-step approach. During the build you would make a list of all artifacts and filter out those that you want deployed. In a second step, you then run mvn deploy on a separate project (or separate profile) in which the list of artifacts is attached to the project as the only artifacts which then get deployed. See the examples in the source code of the ease maven plugin to better understand how it works.
The original version is not able to filter out specific artifacts of a project. I have forked the project and added patches that add this.