I am happy to see this discussion, and so many responses. We have
struggled with it for years, and never found a great solution. Sounds like
we do what many others are doing:
- We have many shared internal libraries amount multiple products.
- We divide each logical set of libraries into their
Am 12/01/16 um 10:02 schrieb João Cabrita:
[...]
> Each of the applications live in a separate repository
[...]
> The libraries also have a repository each
[...]
That's due to the SCM in use. Yes. This is something to keep in mind as
well. What can be one (big) repository using subversion,
Florian,
the use case you're describing is similar to what I'm using at my current
job: we have 3 applications and a bunch of internal libraries that are used
by those applications and, in some cases, applications developed by other
teams in the company.
Each of the applications live in a
Am 11/30/16 um 19:18 schrieb Florian Schätz:
>> A library project to be
>> shared between multiple applications each having its own release-cycle
>> should not be part of a multi-module project used to build such an
>> application and should be an independent project with its own
>> release-cycle.
I've worked on several large 'enterprise' projects, several could have
been 4-6 projects in their own right so maybe 12 ear's, one had 120
pom files. Lucky it got refactored and split into I think 40 repos.
I would suggest;
) branching, using git flow method.
) jgit-flow plugin
An alternative, which I never fully explored, is the CI/CD approach.
Don't use the release plugin. Use -D, or an extension, to set a
unique, non-snapshot, version for each build, and then use version
ranges for the dependencies. I built an experimental extension at my
last job to automatically set
Hi,
On 30/11/16 19:18, Florian Schätz wrote:
A library project to be
shared between multiple applications each having its own release-cycle
should not be part of a multi-module project used to build such an
application and should be an independent project with its own
release-cycle.
While
A library project to be
shared between multiple applications each having its own release-cycle
should not be part of a multi-module project used to build such an
application and should be an independent project with its own
release-cycle.
While this is of course a good idea, especially when
Am 30.11.2016 um 15:06 schrieb Florian Schätz:
> Deployment should be automatic, not requiring many steps, but obviously
> it gets a little bit complicated since, for example, when we want to
> release an RC1, we would also (preferably) automatically release an RC1
> of the shared code modules
Hello Oliver (and everyone else),
can you tell us who do you define a "bigger project"?
Well, bigger project in this case would be starting with two web
applications, with some shared code (thus best put into separate modules
that get developed along the main applications). More
Hi Flo,
can you tell us who do you define a "bigger project"?
Oliver
Am 30.11.16 um 08:27 schrieb Florian Schaetz:
Hello,
are there some good guides about structuring bigger maven projects
(including shared code, easy deployment & versioning, etc.)? There's
much about t
Hello,
are there some good guides about structuring bigger maven projects
(including shared code, easy deployment & versioning, etc.)? There's
much about the basic stuff, default folders, etc. but somehow, I seem to
keep missing the articles (and books) about the "big picture&qu
12 matches
Mail list logo
