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
Related
As my microservie project grows, I want some suggestion on how to organize the microservice repo.
Project layout:
xxx-parent/
gates/
zuul/
gateway/
configs/
config-server/
config-files/
registers/
eureka/
apps/
user-service/
wallet-service/
order-service/
...
The parent and 2nd levels are maven pom projects, the 3rd levels are packaged as jar.
Options:
Each sub module in all 3 levels as a separate git repo.
This is what I do now, it's easy to work with CI/CD like jenkins.
But as projects grow, to get the whole project, need to clone many times.
Whole project as a single git repo.
Easy to clone, but coupled in CI/CD or task assignment, also easy to get git conflicts.
parent as a repo, each 2nd level and its 3rd levels as a repo.
This is a trade off for 1 and 2.
How do you do this in your projects?
I have been working with Git (Bitbucket), and I know how to link multiple remote repositories to one local repository, as I have seen in many tutorials available online, like this https://jigarius.com/blog/multiple-git-remote-repositories and this https://www.cloudsavvyit.com/2464/how-to-use-git-with-multiple-remote-repositories/
What I am trying to achieve is little different. I have two remote repositories, say repo1 and repo2. Both repositories contain 3 branches - master branch, release/1.0 branch, and release/2.0 branch. My project is a generic Java application. repo1 contains only java files, while repo2 contains only JAR files, which are binary files.
I don't have any dependency management system like maven. I am trying to achieve this - When I switch to release/1.0 branch, my java files will change according to repo1 and the JAR files should also change according to repo2. Similarly, when I switch to release/2.0 branch, my java files should change according to repo1 and the JAR files should also change according to repo2. JAR files are different in release branches.
I will not be pushing JAR files to repo2, I don't have such a use case. I will be pushing only Java files, that too, to repo1.
Is this possible? or is there any workaround to achieve this?
Thanks.
You could do it using scripts. On this repository there is a bunch of examples for copying:
The script you could do, could be named like checkout-branch,and the argument $1 would be the branch you need to checkout.
#!/bin/sh
# checkout branch from different remote repositories
git checkout repo1 $1 && git checkout repo2 $1
Then you can use it on your console like:
./checkout-branch.sh release/2.0
Remember to change the permissions on the file to be able to execute it,
make the script executable with command
chmod +x <fileName>
PD: for pushing, deleting etc, you could do the same.
If you have your files properly seperated, you could use a git submodule.
Basically you add repo2 as a dependency to repo1, within git. This way you have all your files locally, but seperated into two repos. When you make a new branch for repo1 though, you'll also have to make a new branch for repo2 and link it in the new repo1 branch.
Usually this works like a dependency normally would: Your submodule is a specific commit of repo2. When you want to update, you update to a new commit. So you'd have to work around this to achieve your specific use case.
Edit:
For starters, you can add a submodule to your repo using git submodule add http://repo2.git, which would make a new folder repo2, which will be the root of your repo2. In there you can work as if in the other repo. Your repo will only have the config for that added.
When you want to update, you go to the repo1 root and update the submodule with git submodule update --remote.
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?
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 have separated the code that I have been making up to this point from a single maven project to multiple maven projects. The projects that I have ended up with can be used by future projects, they are pretty much libraries. I have been using a single Git repository up to this point since everything was in one project. However after the modularisation I wonder if I should create a Git repository for each Maven project. I think that is the correct way to do it, but I would like to hear what others think of that. Since the projects could work as standalone components they also deserve their own Git repository? Another option would be to develop all the projects in the same Git repository for the project that I currently work on.
Since the projects could work as standalone components they also deserve their own Git repository?
This is actually one of the main criteria for defining a git repo, which will represent a coherent group of file with its own independent history (including its set of branches and tags)
This has the additional advantage that some other project depending on some but not all your components won't have to clone the full unique git repo (which would contain everything, included components not needed).
That other project can clone and benefit from the exact subset of components needed.
This is called the component approach, as opposed to the system approach.