I have two gradle projects: the larger system and the smaller pre-existing (our internal code, nontheless) connector library, which I want to use in it. Both have their own git repos on bitbucket, but there's no artifactory to just pull the library as a dependancy. I've tried using git sumbodule, but couldn't get it quite right: I don't want to mix two projects' src folders, but without that I can't import submodule classes. How do I do this using gradle and/or git?
Related
My team uses a GitHub.com organization to keep all of our source code in private repos. (Prior, our old workflow was emailing Dropbox links). Most of the time each repo is one separate project with no dependancy of any other (the only dependancies are on third-party open source libraries). Or if there is some dependancy, then the .java files have just been copy pasted into the other project.
I've recently been splitting up some of my code into reusable modules, but I don't know any way to do the dependancy management when I use the libraries I'm creating in another project.
I know with Gradle you can add a git repo like this:
gitRepository('https://github.com/user/project.git') {
producesModule('user:project')
}
but I don't know if there's a way to make it work with private repos, and I don't know if there's a way to specify versions.
My currently solution is to just build the library JAR, and keep track of the binary version with GitHub release tagging, and when I need to use the library in another project, I download the desired version of the JAR (typically the most recent) and add it to a local /lib/ folder in the other project and import the JAR into the module path as a local JAR. Of course I need to go through the whole process again manually if I want to make a change to the library.
I also heard you can set up private Gradle or Maven servers and some companies do that, but I guess that would mean migrating away from GitHub.com?
Is there any way to make this work (either Gradle or Maven, it doesn't matter) to manage dependancies between GitHub private repos?
Can someone tell me, what is the most sensible way (or ways) to solve this?
Thanks.
What you need is a very typical maven/gradle based setup where
each of your projects will be producing an artifact with a coordinate
of the form group:name:version
your projects do not have to be explicitly aware of each other. They depend on the artifacts produced by other projects. This is called binary dependency
for a project to locate a binary dependency, you will need a central registry where you can publish all your artifacts to. GitHub has a product called GitHub Package for precisely this purpose.
If you don't want to use GitHub Package yet, or your setup (number of projects, size of each projects, size your team) is small enough, you can locally checkout all the projects and include them into a gradle composite build so that binary dependencies will be substituted with local project dependencies. The good thing about the composite build is that when you decide to invest in a package registry, your build.gradle requires no change at all.
BTW, where you run your private package registry does not really matter. You can use the GitHub Package, or some other hosted services, or even run e.g. jfrog artifactory on your own server. It is completely unrelated to where you host your source code, so you dont need to migrate away from GitHub in any case.
I am using eclipse BndTools with a few dedicated workspaces each stored in a single git repo and I've been quite happy sofar.
I've been sharing projects between workspaces by copying them. But recently decided to pull common code into a shared code git repository. In eclipse this is trivial, just use subfolders in your workspace, one per repository.
However to my surprise bndtools demands that I place one cnf project next to my projects in the filebase. At the same time I can only have one cnf project in my workspace. Which effectively means ALL my projects should be peers.
Which in turn means I cannot use multiple git repositories as they cannot share the same directory. Unless I split each project into it's own repository and with 50+ projects this is clearly not where I want to go.
I know eclipse can do this, but is there a way to get bndtools to play ball?
Which effectively means ALL my projects should be peers.
...
Which in turn means I cannot use multiple git repositories as they cannot share the same directory. Unless I split each project into it's own repository
This is where submodule is coming for rescue.
Submodules allow foreign repositories to be embedded within a dedicated subdirectory of the source tree, always pointed at a particular commit.
How to use submodules
# Create each project in its own repository
# now add the desired submodule to your project
git submodule add <url>
# now init/update one by one or recursively all at once
git submodule init
git submodule update
I am developing a project in java, using eclipse, making backup by git (Bitbucket), and I decided to use build it using gradle.
Some of my source code can be used by other project, so I want to move them to other project and manage with another git repository. I want to add them as a dependency to the original project. What should I have to write in build.gradle?
Here are the docs you need. Basically you need to create a standalone gradle project from the separate part. And then with the usage of settings.gradle create a multi project build. Maybe git modules will be also useful.
I'm setting up a new Java project on GitHub, and I'll have some Apache Commons libraries as dependencies.
What are the best practices to establish that my project needs those jar files? Should I upload the dependencies to my GitHub repository (ugly)? Or use a Maven-like tool for that?
Or is there a way to link a file in another git repository? Apache provides git repositories for they libraries. They are read-only, but I'm o.k. with that, since I just want to use the jars. The bad thing is that they contain all the sources, and I just care about the compiled jar. It seems we can't git submodule just a file.
The two approaches are:
declarative and component-based, where you declare (describe) what components (jars, exe, other binaries) you need for your project to (compile, execute, deploy, etc.), and you use a third-party tool (like Maven/Nexus) to bring those components on demand.
So they aren't versioned in your repo. They are declared/described (like in a pom.xml, if you were to use Nexus)
See also "Difference between Git and Nexus?".
inclusive and system-based, where you complete your project with other project sources/binaries, in order to get in your repo everything you need right after the clone step (no need to call a third-party tool or to do anything: every other part of your system in there).
With Git, especially if those "other parts" are in a git repo (like the apache libs one), then you would declare those sub-repos as submodules of your main repo.
That way, all you keep in your main repo is a special entry (gitlink, mode 160000) referencing a specific SHA1 of another repo (but you can make that submodule follow a branch too, a bit like svn external).
And with sparse checkouts in submodules (as in this example), you even can update those modules for them to checkout only the part of the repo you want (like just the jars, not the sources).
Note that you aren't supposed to store any delivery that you would produce (like jars of your own) in your GitHub repo.
You can associate those deliveries to GitHub releases though.
I can't figure out an appropriate way to structure git repositories to handle library dependencies between git repositiories.
I have a number of Java projects that rely on another, frequently updated project that's included in them as a .jar library. I now want to migrate them all to github.
Can I set up the projects in github so that whenever I push project A, then all other projects can pull the new version of projectA.jar automagically? They don't rely on any source files, they just need the latest libraray jar. Currently it's done by an ant script that tries to copy the latest jar from the other project at each build.
Changing your project over to Maven may be a big help; .jar files would no longer be stored in version control.
You would need to open project A, run 'mvn install' to produce the library files on your PC, and then you could use project A's libraries from project B.
Another alternative is to run your own Maven artifacts server, such as Artifactory, Nexus, etc... Project B would look at the artifacts server to see if project A's files are available.