On Monday, March 3, 2014 8:57:44 PM UTC+1, Eric Kolotyluk wrote:
>
> In simple terms I understand that using one git repo per project is the 
> most sane choice. 
>
> But when I have Maven Projects that have one or more hierarchies of 
> modules, I am not sure the best choice of managing a git repo. I have 
> looked at the module support in git, and frankly is scares me, and I worry 
> I might go insane if I attempt to use it. Too many opportunities to screw 
> up...
>
> For example, let's say I have a Maven project like
>
> My Project POM
>     Module 1 POM
>     Module 2 POM
>     Module 3 POM
>         Module A POM
>         Module B POM
>         Module C POM
>
> One choice is to put all of "My Project" in a single repo, but if the 
> project gets really big, or I want to release some modules on their on 
> version schedule, things could get hairy.
>

Here's the clue. All modules that share release schedule/versioning CAN be 
in the same repository. All modules that have distinct schedules SHOULD be 
in separate repositories.
 

>
> The other choice is to put some modules in their own git repo, but then 
> what happens with the parent POM? I guess one solution is to refer to the 
> Parent POM via Maven coordinates, than directly via the file system.
>

The "module parent" (meaning the top-most pom in the repo) should be part 
of the repo, naturally. If it again has a parent, it is usually the 
company-parent pom by absolute version (non-snapshot), which has its own 
repository, with nothing much in it except the pom itself and maybe some 
site stuff. I would try very hard to avoid referring to a (snapshot) parent 
outside the repository on the file-system.

That being said, I have gone down that road before: We have a project that 
combines many Git repositories in one project - they all have the same 
release-cycle and are tightly coupled to eachother, but are split up for 
build practicalities and architectural tidyness (one is for the Windows 
client build, another is for server-side, etc). We used 
gitslave<http://gitslave.sourceforge.net/>to keep these repos bundled. 
Alternatives for this are 
myrepos <http://myrepos.branchable.com/>, git 
submodules<http://git-scm.com/docs/git-submodule>, 
git-repo <https://code.google.com/p/git-repo/>. You can also stitch repos 
together on demand using git 
subtree<https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt>
.
 

> Silly question, does anyone else get in confusing discussions with people 
> when talking about git repos and maven repos, and people just say "repo?"
>

It'll pass once people are used to both :) 

Also: Remember that a parent-pom is not always the same as a "reactor pom" 
(the ones with <modules> in it). Sometimes you can have "build-helper poms" 
that are not parents, they're just a utility to easier work with a bunch of 
Maven projects, but be careful with this trick as it kind of violates what 
people expect to find in a Maven project.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to