I have a project on Github and I have set a release with a Jar for that project. I want to include this Jar in another project as an SBT dependency. How do I set up the resolvers to look for my jar in the github repo.
You want to release your jar into a repository. One option I would recommend is bintray, see bintray-sbt which is an sbt plugin for publishing to bintray, and details how to setup your second project to fetch the publish artifact.
Related
I have a downstream project which would like to reference values defined inside the build files of an upstream project. I was thinking if there is an easy way to publish a jar with the source files of the build project itself then I could publish the build project of the upstream project and the build project of the downstream repo could depend on the build project of the upstream repo. Is it possible to do this? Is it reasonable? Are there other, potentially better solutions?
To be clear because I can see how the above might be confusing (and pardon me if I am using incorrect terminology), I am referring to the recursive nature of sbt builds and the fact that the build definition for a project is a project in itself and that's what I would like to publish, not the source files of the project itself.
I'm familiar with writing plugins in sbt and with the sbt buildinfo plugin. I'm hoping there's another way.
I have an internal SBT plugin which sets up a lot of common aspects of my build. One of those is my setup to add my Artifactory credentials and resolvers. I typically publish the plugin locally so that my build can resolve it and then pull the remaining dependencies from my Artifactory repositories.
For deploying to Heroku, I planned to copy the published artifacts from my .ivy2 repo to a subfolder of the project. However, though I can get this to work locally using both Resolver.file and Resolver.url, I cannot get this to work once I push to Heroku. I even tried it as an unmanaged dependency but still unresolved in Heroku.
Does anyone know the magic spell for achieving this on Heroku?
I have attempted following in project/plugins.sbt:
Resolver.url.("local-plugins", url(s"file///${baseDirectory.value}/plugins"))(Resolver.ivyStylePatterns)
Resolver.file("local-plugins", file("plugins")(Resolver.ivyStylePatterns)
unmanagedBase := baseDirectory.value / "lib"
I recommend two different approaches:
Use the sbt-heroku plugin instead of deploying with Git. You can use local dependencies this way.
Deploy your plugin to BinTray. It's fairly easy, free, and worth the trouble.
I revisited this again today and the following worked:
In plugins.sbt:
resolvers += Resolver.file("local-plugins", file("local-plugins"))(Resolver.ivyStylePatterns)
My project also contains a local-plugins/ directory in the working folder which holds the published artifacts.
I am trying to upload a play 2.1.3 application to our internal maven repository. I would like the zip file generated by play dist to be uploaded to the repo.
I tried following the steps mentioned in the this Google group thread but the method dependsOn does not seem to exist on TaskKey anymore!. but with no luck; publish continues to publish only the jar file.
How can I make sure the the artifact published by the publish task is the zip file generated by dist?
I ended up using the sbt-aether-deploy sbt plugin to deploy the play application to the nexus repository.
How do I configure m2eclipse ( maven plugin for eclipse ) to use a centralized maven repository that is also used in jenkins.
The default user settings in m2eclipse is something like "home/user/.m2"
How can we do something like "ssh user#192.168.1.200:/var/lib/jenkins/.m2"?
A neat and easy way to do it is to use a repository manager. Sonatype's Nexus seems to be the most popular, but there are others (e.g. JFrog Artifactory and Apache Archiva). They run as HTTP servers, and you can change your Maven configuration (both locally and for Jenkins) to use it as a mirror for any Maven repository (e.g. the Central Maven repo), or use it to host your own repositories.
There is no need to do that. Your POM files list dependencies and they list repositories. Maven will then resolve your dependencies against all known repositories (the listed ones and the "build-in" ones, like Maven central).
Maven will do this in m2eclipse, when running a Maven build. Maven will also do that when running the build on Jenkins. So if both machines can connect to all the repositories listed in your POM files, both will retrieve the same artifacts and both will do the same builds.
You should really not try to share the local copy of the artifacts. That is as bad as if I and you try to share our Maven artifacts using a network share. Maven is designed to find and manage those artifacts and you are trying to do its job with this question.
Our company uses Maven. We use the Nexus repository manager in order to store our snapshots and releases.
Currently, we are developing a product based on Eclipse. We use Tycho to do that.
The problem is the following: In our Eclipse-based product we have many features. Our idea is build each feature (or group of features) separately and put them in internal p2 repositories. When one features requires another feature, we point the target platform to necessary internal p2 repository.
Currently, we build application with Tycho. We make our features "deployable", so Tycho produces a P2 site in target. We push that P2 site to our server and then run Eclipse FeaturesAndBundlesPublisher, which merges that recently-built feature with a P2 repository. As a result, we have a internal P2 repository having all the versions of required feature.
We find that this process is too cumbersome. Is there a tool like Nexus, which would be more convenient?
UPD.:There is a discussion on Tycho Users list
With the Unzip Repository Nexus Plugin, you can use Nexus for exchanging binary artifacts between Tycho builds.
Tycho project A publishes its artifacts like a normal Maven project: The project is built with mvn clean deploy, which uploads the project's artifacts into your deploy Maven repository on the Nexus. The only special requirement is that the project builds a p2 repository. The recommended way to do this is an eclipse-repository module, but a "deployable feature" should also work in most cases.
On your Nexus, you only need the following one-time configuration: For the deploy Maven repository (or a "Repository Group" which includes that repository), you need to add a virtual repository of type "Unzip Repository". This virtual repository shows zip artifacts from the deploy repository in unpacked form.
Example: If the p2 repository zip of project A is in the deploy Maven repository at http://nexus.corp/nexus/repositories/build.milestones/corp/example/project-a/project-a-repo/1.0.0/project-a-repo-1.0.0.zip, it will be available in standard p2 repository format in the Unzip Repository at http://nexus.corp/nexus/repositories/build.milestones.unzip/corp/example/project-a/project-a-repo/1.0.0/project-a-repo-1.0.0.zip-unzip/.
Tycho project B can reference the artifacts from project A by adding the latter URL to its target platform, e.g. in a target definition file.
In the above example, project B references a release version of project A. The same approach also works for snapshots because the Unzip Repository has support for "symbolic" versions, like 1.1.0-SNAPSHOT for the last deployed 1.1.0-SNAPSHOT or even just SNAPSHOT for the overall highest version. Using these symbolic versions, Project B can then, for example in its own CI build, reference the CI build results project A by adding the resulting (stable!) p2 repository URLs in its target platform.
Disclaimer: The Unzip Repository Nexus Plugin is part of the Tycho project, of which I'm a committer.
Maybe this is a bit late, but I am currently working on an open source (EPL) repository manager which supports the workflow of deploying to a repository with maven and tycho, and consuming it as P2 repository.
It is also possible to deploy bundles created by maven (not maven tycho) and the P2 metadata will be generated automatically.
The project is called "Package Drone" and hosted on github. There is also a short introduction video.