Git repository and Maven project

Git repository and Maven project

[Aleks]

Can you help to clarify such question.
We have 2 different projects.
Name of first project say "server".
Second - "client".
Every project has own maven build structure.
Server produces the war archive for deployment.
The Client project produces the client jar for testing Server application.
Aside from these projects we should store different artefacts like 
prototypes for developing pages for server project.
There are two opinions about approach to arrangement git repository.

1) Create one repository https://git.org/my-project/src
Create 3 separate folders inside of src directory. So we will have such 
structure :
root of repository https://git.org/my-project/src/
contains 2 different maven projects and folder for prototypes files
https://git.org/my-project/src/server
https://git.org/my-project/src/client
https://git.org/my-project/src/prototypes

2)Create for every maven project and prototypes separate repository.
https://git.org/my-server/src
https://git.org/my-client/src
https://git.org/prototypes/src

The root of maven project begins from src folder in every repository ( 
https://git.org/my-server/src and https://git.org/my-client/src)
The xml files and images of prototypes will be inside of 
https://git.org/prototypes/src
I believe the second approach more proper git-approach.
Such approach allows team to use such advanced git features like 
branging, merging, stash etc.

What approach is proper?


-- 

Best regards
Aleks

Re: Git repository and Maven project

[Junio C Hamano]

Aleks <oles.slosko@gmail.com> writes:

> Can you help to clarify such question.
> We have 2 different projects.
> Name of first project say "server".
> Second - "client".
> Every project has own maven build structure.
> Server produces the war archive for deployment.
> The Client project produces the client jar for testing Server application.
> Aside from these projects we should store different artefacts like
> prototypes for developing pages for server project.

It depends on how tightly coupled the versions of these three
"potentially separate but could be combined" pieces you would want
to make.  Is a particular version of the "server" software meant to
work with any random version of "prototypes"?  Is a particular
version of the "client" software meant to be used to test any random
version of "server"?

Having all three in the same repository means you are guaranteed,
and more importantly, your developers are *forced* to guarantee, a
checkout of a single commit will contain the state of these three
pieces that work well together.  A commit that changes only the
"server" subtree portion, without updating the corresponding assets
in "prototypes" hierarchy that are needed to support what was added
to the "server" part, would break the entire system, and hopefully
your QA procedure can detect and reject it.

Having all three in separate repositories means your developers can
be more loose but it may lead to QA nightmare if a proper procedure
is arranged around the entire process (which Git is only a small
part of).

> I believe the second approach more proper git-approach.
> Such approach allows team to use such advanced git features like
> branging, merging, stash etc.

There is no single "more proper git-approach"; it depends on your
requirements, which the above "how tightly coupled?" question is
an example of.  Branching, merging, etc. are orthogonal and can and
will be useful regardless of the repository arrangement you choose.