Re: Structuring bigger Maven projects

[Christian Schulte]

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.
> 
> While this is of course a good idea, especially when starting to create 
> new applications, the library projects will grow with the applications 
> and not independently of them. We cannot start by first investing months 
> to create the perfect will-work-for-ten-years library and only then 
> start coding the application that will, in the first months, only use 
> 10% of all these features. So, realistically, during a development 
> cycle, both the application and the library will grow... (which doesn't 
> mean that we cannot separate them)

That's what I was referring to with "inheritance vs. aggregation". In a
multi-module project you get versioning "for free" by using the
release:prepare release:perform goals. Maintaining the build is not a
one time task. You adjust things over time until you get things
structured the way it fits your situation perfectly. To not be trapped
later, you need to carefully decide the artifact coordinates in use and
the way versions will be assigned. If a shared library has been part of
a multi-module project together with an application, extracting it later
should not have an impact on the rest of the build. It should carry it's
own version from day one. It should carry it's own coordinate namespace
from day one. Once in a multi-module project, you will soon start to
inherit groupId and version. That can lead to having to update each and
every application POM when extracting that library later. Starting some
application from scatch today, keep in mind you will re-structure your
build over time until things have been sorted out. If you know from day
one that a specific module/project will have it's own release-cycle
sooner or later, be prepared for that from day one.

Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Need to fully understand bad implications of combined aggregator and parent pom

[Curtis Rueden]

Hi David,

> The fact is, when I ensured that both the local and intranet repo is
> EMPTY of build artifacts, including the parent pom, the child modules
> fail to build because they can't find the parent pom, which just
> resides in the parent directory of each child module.

I have never had that problem with multi-module projects that use a
combined parent/aggregator in the top-level directory. This sounds like a
bug to me. Can you please create an SSCCE / MCVE? Then maybe the community
can comment further on what is going wrong for you.

Regards,
Curtis


--
Curtis Rueden
LOCI software architect - http://loci.wisc.edu/software


On Wed, Nov 30, 2016 at 7:59 PM, KARR, DAVID  wrote:

> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Wednesday, November 30, 2016 5:10 PM
> > To: Maven Users List 
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > Correct we dont ever enter relativePath. The implicit one should work
> > and should never see warning that a module can't find its parent
>
> Uh, whatever.  You're clearly disagreeing with me, so saying "correct"
> just confuses things.
>
> The fact is, when I ensured that both the local and intranet repo is EMPTY
> of build artifacts, including the parent pom, the child modules fail to
> build because they can't find the parent pom, which just resides in the
> parent directory of each child module.
>
> I never tried adding a ".. to all of the
> parent pom references, but I was able to get it to work by splitting out
> the parent pom responsibilities into a separate child module pom, and
> having all the references specify the relative path to that.
>
> > On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID  wrote:
> >
> > > > -Original Message-
> > > > From: Dan Tran [mailto:dant...@gmail.com]
> > > > Sent: Wednesday, November 30, 2016 3:17 PM
> > > > To: Maven Users List 
> > > > Subject: Re: Need to fully understand bad implications of combined
> > > > aggregator and parent pom
> > > >
> > > > I concur with Ben,  aggregator module is banned at my work. Top
> > > > level parent hosts all modules
> > >
> > > So does this mean that you utilize "relativePath" in the child
> > > module's parent definitions?  Otherwise, the child modules are being
> > > built before the POM for the top-level POM is installed (which happens
> > > at the end of the build).
> > >
> > > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID  wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > > > To: Maven Users List 
> > > > > > Subject: Re: Need to fully understand bad implications of
> > > > > > combined aggregator and parent pom
> > > > > >
> > > > > > You do have relativePath set correctly for the separate parent
> > > > > > from aggregator?
> > > > >
> > > > > Not sure whether you're addressing Benson or me, but setting
> > > > > relativePath is definitely a requirement, and I think the error
> > > > > message you get is pretty clear when you don’t have it, so I
> > > > > imagine
> > > > that's not Benson's issue.
> > > > >
> > > > > In my case, I did some cut/pasting and some global replaces to
> > > > > separate the POM into parent and aggregator, and now my build
> > > > > works from the top with empty repositories.
> > > > >
> > > > > I don't use the site plugin.
> > > > >
> > > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > > > 
> > > > > > wrote:
> > > > > >
> > > > > > > My experience is precisely the opposite of yours. The most
> > > > > > > common practice is for the parent to be the aggregator; it's
> > > > > > > hard to get the site plugin, for example, to work right with
> > > > > > > your preferred structure where they are different.
> > > > > > >
> > > > > > > I have built many projects with the the one-parent structure,
> > > > > > > and they typically have interdependencies between the modules,
> > > > > > > and they work fine.  Can you boil this down to a failing case
> > > > > > > on github? Can you share some poms?
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID 
> > > > wrote:
> > > > > > > > A while ago, I started working on an existing project with
> > > > > > > > many
> > > > > > > developers.  The codebase has a large multi-project Maven
> > build.
> > > > > > > The top directory is both an "aggregator" and "parent" POM, as
> > > > > > > it has a
> > > > > > "modules"
> > > > > > > list, and all of the child modules have it as their parent
> > > > > > > POM, for dependencies and plugins.
> > > > > > > >
> > > > > > > > I've always believed this is a defective architecture.  I
> > > > > > > > believe that
> > > > > > > the 

RE: Need to fully understand bad implications of combined aggregator and parent pom

[KARR, DAVID]

> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Wednesday, November 30, 2016 5:10 PM
> To: Maven Users List 
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
> 
> Correct we dont ever enter relativePath. The implicit one should work
> and should never see warning that a module can't find its parent

Uh, whatever.  You're clearly disagreeing with me, so saying "correct" just 
confuses things.

The fact is, when I ensured that both the local and intranet repo is EMPTY of 
build artifacts, including the parent pom, the child modules fail to build 
because they can't find the parent pom, which just resides in the parent 
directory of each child module.

I never tried adding a ".. to all of the parent 
pom references, but I was able to get it to work by splitting out the parent 
pom responsibilities into a separate child module pom, and having all the 
references specify the relative path to that.

> On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID  wrote:
> 
> > > -Original Message-
> > > From: Dan Tran [mailto:dant...@gmail.com]
> > > Sent: Wednesday, November 30, 2016 3:17 PM
> > > To: Maven Users List 
> > > Subject: Re: Need to fully understand bad implications of combined
> > > aggregator and parent pom
> > >
> > > I concur with Ben,  aggregator module is banned at my work. Top
> > > level parent hosts all modules
> >
> > So does this mean that you utilize "relativePath" in the child
> > module's parent definitions?  Otherwise, the child modules are being
> > built before the POM for the top-level POM is installed (which happens
> > at the end of the build).
> >
> > > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID  wrote:
> > >
> > > > > -Original Message-
> > > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > > To: Maven Users List 
> > > > > Subject: Re: Need to fully understand bad implications of
> > > > > combined aggregator and parent pom
> > > > >
> > > > > You do have relativePath set correctly for the separate parent
> > > > > from aggregator?
> > > >
> > > > Not sure whether you're addressing Benson or me, but setting
> > > > relativePath is definitely a requirement, and I think the error
> > > > message you get is pretty clear when you don’t have it, so I
> > > > imagine
> > > that's not Benson's issue.
> > > >
> > > > In my case, I did some cut/pasting and some global replaces to
> > > > separate the POM into parent and aggregator, and now my build
> > > > works from the top with empty repositories.
> > > >
> > > > I don't use the site plugin.
> > > >
> > > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > My experience is precisely the opposite of yours. The most
> > > > > > common practice is for the parent to be the aggregator; it's
> > > > > > hard to get the site plugin, for example, to work right with
> > > > > > your preferred structure where they are different.
> > > > > >
> > > > > > I have built many projects with the the one-parent structure,
> > > > > > and they typically have interdependencies between the modules,
> > > > > > and they work fine.  Can you boil this down to a failing case
> > > > > > on github? Can you share some poms?
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID 
> > > wrote:
> > > > > > > A while ago, I started working on an existing project with
> > > > > > > many
> > > > > > developers.  The codebase has a large multi-project Maven
> build.
> > > > > > The top directory is both an "aggregator" and "parent" POM, as
> > > > > > it has a
> > > > > "modules"
> > > > > > list, and all of the child modules have it as their parent
> > > > > > POM, for dependencies and plugins.
> > > > > > >
> > > > > > > I've always believed this is a defective architecture.  I
> > > > > > > believe that
> > > > > > the top-level directory should have an "aggregator" POM that
> > > > > > just lists the modules to build, and a subdirectory of the
> > > > > > top-level directory should have a project that just defines
> > > > > > the parent POM, which defines dependencies and plugins for
> subprojects to use.
> > > > > > >
> > > > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > > > been able
> > > > > > to cite specific problems with the other approach, besides the
> > > > > > fact that module changes and dependency/plugin changes go in
> > > > > > the same file, which is still a "cleanliness" argument.
> > > > > > >
> > > > > > > Today I think I saw a real reason why the present
> > > > > > > architecture is a
> > > > > > problem, but I need to be certain the problem I'm seeing is
> > > > > > caused by this, and that the better architecture fixes this
> > > > > > 

Re: Need to fully understand bad implications of combined aggregator and parent pom

[Dan Tran]

Correct we dont ever enter relativePath. The implicit one should work and
should never see warning that a module can't find its parent

On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID  wrote:

> > -Original Message-
> > From: Dan Tran [mailto:dant...@gmail.com]
> > Sent: Wednesday, November 30, 2016 3:17 PM
> > To: Maven Users List 
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > I concur with Ben,  aggregator module is banned at my work. Top level
> > parent hosts all modules
>
> So does this mean that you utilize "relativePath" in the child module's
> parent definitions?  Otherwise, the child modules are being built before
> the POM for the top-level POM is installed (which happens at the end of the
> build).
>
> > On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID  wrote:
> >
> > > > -Original Message-
> > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > > To: Maven Users List 
> > > > Subject: Re: Need to fully understand bad implications of combined
> > > > aggregator and parent pom
> > > >
> > > > You do have relativePath set correctly for the separate parent from
> > > > aggregator?
> > >
> > > Not sure whether you're addressing Benson or me, but setting
> > > relativePath is definitely a requirement, and I think the error
> > > message you get is pretty clear when you don’t have it, so I imagine
> > that's not Benson's issue.
> > >
> > > In my case, I did some cut/pasting and some global replaces to
> > > separate the POM into parent and aggregator, and now my build works
> > > from the top with empty repositories.
> > >
> > > I don't use the site plugin.
> > >
> > > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > > 
> > > > wrote:
> > > >
> > > > > My experience is precisely the opposite of yours. The most common
> > > > > practice is for the parent to be the aggregator; it's hard to get
> > > > > the site plugin, for example, to work right with your preferred
> > > > > structure where they are different.
> > > > >
> > > > > I have built many projects with the the one-parent structure, and
> > > > > they typically have interdependencies between the modules, and
> > > > > they work fine.  Can you boil this down to a failing case on
> > > > > github? Can you share some poms?
> > > > >
> > > > >
> > > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID 
> > wrote:
> > > > > > A while ago, I started working on an existing project with many
> > > > > developers.  The codebase has a large multi-project Maven build.
> > > > > The top directory is both an "aggregator" and "parent" POM, as it
> > > > > has a
> > > > "modules"
> > > > > list, and all of the child modules have it as their parent POM,
> > > > > for dependencies and plugins.
> > > > > >
> > > > > > I've always believed this is a defective architecture.  I
> > > > > > believe that
> > > > > the top-level directory should have an "aggregator" POM that just
> > > > > lists the modules to build, and a subdirectory of the top-level
> > > > > directory should have a project that just defines the parent POM,
> > > > > which defines dependencies and plugins for subprojects to use.
> > > > > >
> > > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > > been able
> > > > > to cite specific problems with the other approach, besides the
> > > > > fact that module changes and dependency/plugin changes go in the
> > > > > same file, which is still a "cleanliness" argument.
> > > > > >
> > > > > > Today I think I saw a real reason why the present architecture
> > > > > > is a
> > > > > problem, but I need to be certain the problem I'm seeing is caused
> > > > > by this, and that the better architecture fixes this problem, and
> > > > > whether there is a simple workaround in the meantime.
> > > > > >
> > > > > > I've been modifying the build to use a completely new intranet
> > > > > > maven
> > > > > repo and completely different groupids for the build artifacts.
> > > > > >
> > > > > > I saw errors like this (with elisions):
> > > > > > ---
> > > > > > [INFO] Reactor Summary:
> > > > > > [INFO]
> > > > > > [INFO] big-parent .
> > > > > > FAILURE [
> > > > > 5.230 s]
> > > > > > [INFO] some-other-module...
> > > > > > SKIPPED [INFO]
> > > > > > another-module.. SKIPPED
> > > > > > [INFO]
> > > > > > .SKIPPED
> > > > > > [INFO]
> > > > > --
> > > > > 
> > > > > --
> > > > > > [INFO] BUILD FAILURE
> > > > > > [INFO]
> > > > > --
> > > > > 
> > > > > --
> > > > > 

RE: Need to fully understand bad implications of combined aggregator and parent pom

[KARR, DAVID]

> -Original Message-
> From: Dan Tran [mailto:dant...@gmail.com]
> Sent: Wednesday, November 30, 2016 3:17 PM
> To: Maven Users List 
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
> 
> I concur with Ben,  aggregator module is banned at my work. Top level
> parent hosts all modules

So does this mean that you utilize "relativePath" in the child module's parent 
definitions?  Otherwise, the child modules are being built before the POM for 
the top-level POM is installed (which happens at the end of the build).

> On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID  wrote:
> 
> > > -Original Message-
> > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > > Sent: Wednesday, November 30, 2016 1:01 PM
> > > To: Maven Users List 
> > > Subject: Re: Need to fully understand bad implications of combined
> > > aggregator and parent pom
> > >
> > > You do have relativePath set correctly for the separate parent from
> > > aggregator?
> >
> > Not sure whether you're addressing Benson or me, but setting
> > relativePath is definitely a requirement, and I think the error
> > message you get is pretty clear when you don’t have it, so I imagine
> that's not Benson's issue.
> >
> > In my case, I did some cut/pasting and some global replaces to
> > separate the POM into parent and aggregator, and now my build works
> > from the top with empty repositories.
> >
> > I don't use the site plugin.
> >
> > > On Wed 30 Nov 2016 at 03:28, Benson Margulies
> > > 
> > > wrote:
> > >
> > > > My experience is precisely the opposite of yours. The most common
> > > > practice is for the parent to be the aggregator; it's hard to get
> > > > the site plugin, for example, to work right with your preferred
> > > > structure where they are different.
> > > >
> > > > I have built many projects with the the one-parent structure, and
> > > > they typically have interdependencies between the modules, and
> > > > they work fine.  Can you boil this down to a failing case on
> > > > github? Can you share some poms?
> > > >
> > > >
> > > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID 
> wrote:
> > > > > A while ago, I started working on an existing project with many
> > > > developers.  The codebase has a large multi-project Maven build.
> > > > The top directory is both an "aggregator" and "parent" POM, as it
> > > > has a
> > > "modules"
> > > > list, and all of the child modules have it as their parent POM,
> > > > for dependencies and plugins.
> > > > >
> > > > > I've always believed this is a defective architecture.  I
> > > > > believe that
> > > > the top-level directory should have an "aggregator" POM that just
> > > > lists the modules to build, and a subdirectory of the top-level
> > > > directory should have a project that just defines the parent POM,
> > > > which defines dependencies and plugins for subprojects to use.
> > > > >
> > > > > Although I feel this is a "cleaner" architecture, I've never
> > > > > been able
> > > > to cite specific problems with the other approach, besides the
> > > > fact that module changes and dependency/plugin changes go in the
> > > > same file, which is still a "cleanliness" argument.
> > > > >
> > > > > Today I think I saw a real reason why the present architecture
> > > > > is a
> > > > problem, but I need to be certain the problem I'm seeing is caused
> > > > by this, and that the better architecture fixes this problem, and
> > > > whether there is a simple workaround in the meantime.
> > > > >
> > > > > I've been modifying the build to use a completely new intranet
> > > > > maven
> > > > repo and completely different groupids for the build artifacts.
> > > > >
> > > > > I saw errors like this (with elisions):
> > > > > ---
> > > > > [INFO] Reactor Summary:
> > > > > [INFO]
> > > > > [INFO] big-parent .
> > > > > FAILURE [
> > > > 5.230 s]
> > > > > [INFO] some-other-module...
> > > > > SKIPPED [INFO]
> > > > > another-module.. SKIPPED
> > > > > [INFO]
> > > > > .SKIPPED
> > > > > [INFO]
> > > > --
> > > > 
> > > > --
> > > > > [INFO] BUILD FAILURE
> > > > > [INFO]
> > > > --
> > > > 
> > > > --
> > > > > [INFO] Total time: 8.063 s
> > > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final
> Memory:
> > > > > 41M/1093M [INFO]
> > > > --
> > > > 
> > > > --
> > > > > [ERROR] Failed to execute goal on project some-other-module:
> > > > > Could not
> > > > resolve dependencies for project
> > > > 

RE: How does the jar plugin produce a "*-tests.jar" when I don't specify that?

[KARR, DAVID]

> -Original Message-
> From: Laird Nelson [mailto:ljnel...@gmail.com]
> Sent: Wednesday, November 30, 2016 3:36 PM
> To: Maven Users List 
> Subject: Re: How does the jar plugin produce a "*-tests.jar" when I
> don't specify that?
> 
> On Wed, Nov 30, 2016 at 3:19 PM KARR, DAVID  wrote:
> 
> > The POM for "artifact1" has two dependencies on "artifact2".  One is
> > the "default" artifact, and another is a jar artifact that is only
> > used for unit tests.
> >
> 
> …and that's the issue.  See
> https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html;
> note in particular the "classifier" property (
> https://maven.apache.org/plugins/maven-jar-plugin/test-jar-
> mojo.html#classifier
> ).
> 
> Some other information is here:
> https://maven.apache.org/guides/mini/guide-attached-tests.html

Ok, thanks.  That explains why I get "*-tests.jar".  I still need to understand 
why that other developer is not getting that jar generated.  More debugging to 
do.

Re: How does the jar plugin produce a "*-tests.jar" when I don't specify that?

[Laird Nelson]

On Wed, Nov 30, 2016 at 3:19 PM KARR, DAVID  wrote:

> The POM for "artifact1" has two dependencies on "artifact2".  One is the
> "default" artifact, and another is a jar artifact that is only used for
> unit tests.
>

…and that's the issue.  See
https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html; note
in particular the "classifier" property (
https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html#classifier
).

Some other information is here:
https://maven.apache.org/guides/mini/guide-attached-tests.html

Best,
Laird
--
http://about.me/lairdnelson

How does the jar plugin produce a "*-tests.jar" when I don't specify that?

[KARR, DAVID]

I'm working with a user who is getting an error from a build that looks like 
this:
---
Could not resolve dependencies for project 
::bundle:2.0.0-SNAPSHOT: Could not find artifact 
::jar:tests
--

I elided the groupId and artifact ids, but the trailing part of the artifact 
reference was ":jar:tests".  I need to understand this "tests" thing.

I'm building the same branch, and I don't see this error, so I need to 
understand what's going on here.

The POM for "artifact1" has two dependencies on "artifact2".  One is the 
"default" artifact, and another is a jar artifact that is only used for unit 
tests.

The dependency elements in the POM for "artifact1" look like this:
---

...
artifact2
2.0.0-SNAPSHOT


...
artifact2
2.0.0-SNAPSHOT
test-jar
test

---

In the POM for "artifact2", there is the following plugin definition:
---

org.apache.maven.plugins
maven-jar-plugin
2.2



test-jar




---

Notice that the only place you see "tests" so far is in that error message 
(which my colleague gets, but I do not).

I then looked in the "target" directory for "artifact2", and I saw the 
following:
-
artifact2-2.0.0-SNAPSHOT.jar
artifact2-2.0.0-SNAPSHOT-tests.jar


Ok, there's the "tests".  The question is, how did I end up with "*-tests.jar"?

I'm also unsure of the proper way to generate an "auxiliary" jar like this. 
Perhaps this should be refined to be more robust?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Structuring bigger Maven projects

[John Patrick]

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 (https://bitbucket.org/atlassian/jgit-flow), not
maven-release-plugin

) deployment, now only using Ansible as finding easier to use than chef/puppet

) versioning, using
http://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html
have a release profile in the companies parent pom

) for code quality, using atlassian stash which is forcing 1
successful build and 1 approver before for code to be merged into
develop, successful build also means code, test, findbugs etc.

) cim, still using jenkins v1, not upgraded to v2 yet. have a mix of
jobs, most deployable artifacts have a pipelines checking develop and
waiting for 15 mins before kicking off a build to allow multiple
merges, then automatically building, deploying and configuring using
ansible to the development environment, running qa step(s) either
cucumber or selenium, if they all pass then automatically creating a
release candidate and closing the release branch and merging into
master

) 1 git repo for each deployable artifact
) git repo for shared code/framework, logically group so not all in 1
repo but not all with their own repo.

) each logical cucumber project was it's own git repo, so if it
changed it was easier to automatically trigger it's execution

) jenkins or what every cim you pick, use multiple slaves to run the
tasks, yes you could get everything running on the master jenkins node
but it will quickly become overload.

) this is how I do release, with the mvn -Pdo-release -N validate, it
will bump the version numbers create the release branch, automatically
finish it, tag it, so develop branch always see -SNAPSHOT's and master
never sees -SNAPSHOT's http://pastebin.com/DbAGACk7


John


On 30 November 2016 at 18:44, Karl Heinz Marbaise  wrote:
> 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 this is of course a good idea, especially when starting to create
>> new applications, the library projects will grow with the applications
>> and not independently of them. We cannot start by first investing months
>> to create the perfect will-work-for-ten-years library and only then
>> start coding the application that will, in the first months, only use
>> 10% of all these features. So, realistically, during a development
>> cycle, both the application and the library will grow... (which doesn't
>> mean that we cannot separate them)
>>
>> Which leads me, for example, to the problem that I still want to
>> automate as much as possible. I would like, for example, to click one
>> button in my build server, perhaps enter some parameters and get a new
>> release candidate of the libraries from the current release branch,
>> update the dependency version of the application to this rc version,
>> make the application an rc (from the application's release branch),
>> install them both into the repository, tag the current status on git and
>> deploy the rc application onto the server.
>>
>> Especially for bigger projects, I want to keep the amount of manual work
>> needed as small as possible. As much building should be done
>> automatically, if possible. And I would like not having to code a
>> jenkins or maven plugin for that purpose (but of course, I would, if
>> needed, no problem there).
>
>
>
> You can simply use maven-release-plugin (in Maven itself) which you can used
> to  fully automatically create releases of your project...This will need
> only a plugin in Jenkins which handles all those stuff...correctly
> configured things like scm entries in your pom file tagging in Git will be
> done as well
>
> Sometimes you might need to improve that using the versions-maven-plugin in
> combination with some pipeline steps in Jenkins...which prevents some
> drawbacks of the maven-release-plugin
>
>
> May be you need to think about using the Maven integration in Jenkins or
> using freestyle projects or better start using pipelines ...(I often
> observed performance drawbacks in relationship with Maven integration in
> Jenkins)...
>
>
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Need to fully understand bad implications of combined aggregator and parent pom

[Dan Tran]

I concur with Ben,  aggregator module is banned at my work. Top level
parent hosts all modules

On Wed, Nov 30, 2016 at 1:47 PM, KARR, DAVID  wrote:

> > -Original Message-
> > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> > Sent: Wednesday, November 30, 2016 1:01 PM
> > To: Maven Users List 
> > Subject: Re: Need to fully understand bad implications of combined
> > aggregator and parent pom
> >
> > You do have relativePath set correctly for the separate parent from
> > aggregator?
>
> Not sure whether you're addressing Benson or me, but setting relativePath
> is definitely a requirement, and I think the error message you get is
> pretty clear when you don’t have it, so I imagine that's not Benson's issue.
>
> In my case, I did some cut/pasting and some global replaces to separate
> the POM into parent and aggregator, and now my build works from the top
> with empty repositories.
>
> I don't use the site plugin.
>
> > On Wed 30 Nov 2016 at 03:28, Benson Margulies 
> > wrote:
> >
> > > My experience is precisely the opposite of yours. The most common
> > > practice is for the parent to be the aggregator; it's hard to get the
> > > site plugin, for example, to work right with your preferred structure
> > > where they are different.
> > >
> > > I have built many projects with the the one-parent structure, and they
> > > typically have interdependencies between the modules, and they work
> > > fine.  Can you boil this down to a failing case on github? Can you
> > > share some poms?
> > >
> > >
> > > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID  wrote:
> > > > A while ago, I started working on an existing project with many
> > > developers.  The codebase has a large multi-project Maven build.  The
> > > top directory is both an "aggregator" and "parent" POM, as it has a
> > "modules"
> > > list, and all of the child modules have it as their parent POM, for
> > > dependencies and plugins.
> > > >
> > > > I've always believed this is a defective architecture.  I believe
> > > > that
> > > the top-level directory should have an "aggregator" POM that just
> > > lists the modules to build, and a subdirectory of the top-level
> > > directory should have a project that just defines the parent POM,
> > > which defines dependencies and plugins for subprojects to use.
> > > >
> > > > Although I feel this is a "cleaner" architecture, I've never been
> > > > able
> > > to cite specific problems with the other approach, besides the fact
> > > that module changes and dependency/plugin changes go in the same file,
> > > which is still a "cleanliness" argument.
> > > >
> > > > Today I think I saw a real reason why the present architecture is a
> > > problem, but I need to be certain the problem I'm seeing is caused by
> > > this, and that the better architecture fixes this problem, and whether
> > > there is a simple workaround in the meantime.
> > > >
> > > > I've been modifying the build to use a completely new intranet maven
> > > repo and completely different groupids for the build artifacts.
> > > >
> > > > I saw errors like this (with elisions):
> > > > ---
> > > > [INFO] Reactor Summary:
> > > > [INFO]
> > > > [INFO] big-parent . FAILURE
> > > > [
> > > 5.230 s]
> > > > [INFO] some-other-module... SKIPPED
> > > > [INFO] another-module.. SKIPPED
> > > > [INFO] .SKIPPED
> > > > [INFO]
> > > --
> > > --
> > > > [INFO] BUILD FAILURE
> > > > [INFO]
> > > --
> > > --
> > > > [INFO] Total time: 8.063 s
> > > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final Memory:
> > > > 41M/1093M [INFO]
> > > --
> > > --
> > > > [ERROR] Failed to execute goal on project some-other-module: Could
> > > > not
> > > resolve dependencies for project
> > > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not
> > > find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > > mycomp-public-group (
> > > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/myco
> > > mp-public-group/)
> > > -> [Help 1]
> > > > [ERROR]
> > > > ---
> > > >
> > > > The "big-parent" module is the top-level directory that is both the
> > > aggregator and parent pom.
> > > >
> > > > Conceptually, I think this is happening because Maven is trying to
> > > evaluate dependencies before those dependencies are built.  Again, I
> > > think the "separated" architecture will resolve this, but before I
> > > implement that, I need to understand exactly what is going on here.
> > > >
> > > > In my local workspace, I got around this 

Re: Structuring bigger Maven projects

[Benson Margulies]

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 a rev property from the current git
commit, but it wasn't entirely satisfactory.


On Wed, Nov 30, 2016 at 1:44 PM, Karl Heinz Marbaise  wrote:
> 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 this is of course a good idea, especially when starting to create
>> new applications, the library projects will grow with the applications
>> and not independently of them. We cannot start by first investing months
>> to create the perfect will-work-for-ten-years library and only then
>> start coding the application that will, in the first months, only use
>> 10% of all these features. So, realistically, during a development
>> cycle, both the application and the library will grow... (which doesn't
>> mean that we cannot separate them)
>>
>> Which leads me, for example, to the problem that I still want to
>> automate as much as possible. I would like, for example, to click one
>> button in my build server, perhaps enter some parameters and get a new
>> release candidate of the libraries from the current release branch,
>> update the dependency version of the application to this rc version,
>> make the application an rc (from the application's release branch),
>> install them both into the repository, tag the current status on git and
>> deploy the rc application onto the server.
>>
>> Especially for bigger projects, I want to keep the amount of manual work
>> needed as small as possible. As much building should be done
>> automatically, if possible. And I would like not having to code a
>> jenkins or maven plugin for that purpose (but of course, I would, if
>> needed, no problem there).
>
>
>
> You can simply use maven-release-plugin (in Maven itself) which you can used
> to  fully automatically create releases of your project...This will need
> only a plugin in Jenkins which handles all those stuff...correctly
> configured things like scm entries in your pom file tagging in Git will be
> done as well
>
> Sometimes you might need to improve that using the versions-maven-plugin in
> combination with some pipeline steps in Jenkins...which prevents some
> drawbacks of the maven-release-plugin
>
>
> May be you need to think about using the Maven integration in Jenkins or
> using freestyle projects or better start using pipelines ...(I often
> observed performance drawbacks in relationship with Maven integration in
> Jenkins)...
>
>
> https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
> https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Need to fully understand bad implications of combined aggregator and parent pom

[KARR, DAVID]

> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Wednesday, November 30, 2016 1:01 PM
> To: Maven Users List 
> Subject: Re: Need to fully understand bad implications of combined
> aggregator and parent pom
> 
> You do have relativePath set correctly for the separate parent from
> aggregator?

Not sure whether you're addressing Benson or me, but setting relativePath is 
definitely a requirement, and I think the error message you get is pretty clear 
when you don’t have it, so I imagine that's not Benson's issue.

In my case, I did some cut/pasting and some global replaces to separate the POM 
into parent and aggregator, and now my build works from the top with empty 
repositories.

I don't use the site plugin.

> On Wed 30 Nov 2016 at 03:28, Benson Margulies 
> wrote:
> 
> > My experience is precisely the opposite of yours. The most common
> > practice is for the parent to be the aggregator; it's hard to get the
> > site plugin, for example, to work right with your preferred structure
> > where they are different.
> >
> > I have built many projects with the the one-parent structure, and they
> > typically have interdependencies between the modules, and they work
> > fine.  Can you boil this down to a failing case on github? Can you
> > share some poms?
> >
> >
> > On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID  wrote:
> > > A while ago, I started working on an existing project with many
> > developers.  The codebase has a large multi-project Maven build.  The
> > top directory is both an "aggregator" and "parent" POM, as it has a
> "modules"
> > list, and all of the child modules have it as their parent POM, for
> > dependencies and plugins.
> > >
> > > I've always believed this is a defective architecture.  I believe
> > > that
> > the top-level directory should have an "aggregator" POM that just
> > lists the modules to build, and a subdirectory of the top-level
> > directory should have a project that just defines the parent POM,
> > which defines dependencies and plugins for subprojects to use.
> > >
> > > Although I feel this is a "cleaner" architecture, I've never been
> > > able
> > to cite specific problems with the other approach, besides the fact
> > that module changes and dependency/plugin changes go in the same file,
> > which is still a "cleanliness" argument.
> > >
> > > Today I think I saw a real reason why the present architecture is a
> > problem, but I need to be certain the problem I'm seeing is caused by
> > this, and that the better architecture fixes this problem, and whether
> > there is a simple workaround in the meantime.
> > >
> > > I've been modifying the build to use a completely new intranet maven
> > repo and completely different groupids for the build artifacts.
> > >
> > > I saw errors like this (with elisions):
> > > ---
> > > [INFO] Reactor Summary:
> > > [INFO]
> > > [INFO] big-parent . FAILURE
> > > [
> > 5.230 s]
> > > [INFO] some-other-module... SKIPPED
> > > [INFO] another-module.. SKIPPED
> > > [INFO] .SKIPPED
> > > [INFO]
> > --
> > --
> > > [INFO] BUILD FAILURE
> > > [INFO]
> > --
> > --
> > > [INFO] Total time: 8.063 s
> > > [INFO] Finished at: 2016-11-29T16:23:36-08:00 [INFO] Final Memory:
> > > 41M/1093M [INFO]
> > --
> > --
> > > [ERROR] Failed to execute goal on project some-other-module: Could
> > > not
> > resolve dependencies for project
> > com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not
> > find artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> > mycomp-public-group (
> > http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/myco
> > mp-public-group/)
> > -> [Help 1]
> > > [ERROR]
> > > ---
> > >
> > > The "big-parent" module is the top-level directory that is both the
> > aggregator and parent pom.
> > >
> > > Conceptually, I think this is happening because Maven is trying to
> > evaluate dependencies before those dependencies are built.  Again, I
> > think the "separated" architecture will resolve this, but before I
> > implement that, I need to understand exactly what is going on here.
> > >
> > > In my local workspace, I got around this by simply "cd"ing to the
> > "another-module" directory and doing a "mvn install", then "cd"ing to
> > "some-other-module", doing the same, and then doing the same again at
> > the top level. The reality was messier than this, because I had quite
> > a few modules that I had to build manually this way.
> > >
> > > Assuming I'm right that separating the "parent" 

Re: Need to fully understand bad implications of combined aggregator and parent pom

[Stephen Connolly]

You do have relativePath set correctly for the separate parent from
aggregator?

On Wed 30 Nov 2016 at 03:28, Benson Margulies  wrote:

> My experience is precisely the opposite of yours. The most common
> practice is for the parent to be the aggregator; it's hard to get the
> site plugin, for example, to work right with your preferred structure
> where they are different.
>
> I have built many projects with the the one-parent structure, and they
> typically have interdependencies between the modules, and they work
> fine.  Can you boil this down to a failing case on github? Can you
> share some poms?
>
>
> On Tue, Nov 29, 2016 at 9:19 PM, KARR, DAVID  wrote:
> > A while ago, I started working on an existing project with many
> developers.  The codebase has a large multi-project Maven build.  The top
> directory is both an "aggregator" and "parent" POM, as it has a "modules"
> list, and all of the child modules have it as their parent POM, for
> dependencies and plugins.
> >
> > I've always believed this is a defective architecture.  I believe that
> the top-level directory should have an "aggregator" POM that just lists the
> modules to build, and a subdirectory of the top-level directory should have
> a project that just defines the parent POM, which defines dependencies and
> plugins for subprojects to use.
> >
> > Although I feel this is a "cleaner" architecture, I've never been able
> to cite specific problems with the other approach, besides the fact that
> module changes and dependency/plugin changes go in the same file, which is
> still a "cleanliness" argument.
> >
> > Today I think I saw a real reason why the present architecture is a
> problem, but I need to be certain the problem I'm seeing is caused by this,
> and that the better architecture fixes this problem, and whether there is a
> simple workaround in the meantime.
> >
> > I've been modifying the build to use a completely new intranet maven
> repo and completely different groupids for the build artifacts.
> >
> > I saw errors like this (with elisions):
> > ---
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] big-parent . FAILURE [
> 5.230 s]
> > [INFO] some-other-module... SKIPPED
> > [INFO] another-module.. SKIPPED
> > [INFO] .SKIPPED
> > [INFO]
> 
> > [INFO] BUILD FAILURE
> > [INFO]
> 
> > [INFO] Total time: 8.063 s
> > [INFO] Finished at: 2016-11-29T16:23:36-08:00
> > [INFO] Final Memory: 41M/1093M
> > [INFO]
> 
> > [ERROR] Failed to execute goal on project some-other-module: Could not
> resolve dependencies for project
> com.mycomp.detsusl:some-other-module:bundle:2.0.0-SNAPSHOT: Could not find
> artifact com.mycomp.detsusl:another-module:jar:2.0.0-SNAPSHOT in
> mycomp-public-group (
> http://mavencentral.it.mycomp.com:8084/nexus/content/repositories/mycomp-public-group/)
> -> [Help 1]
> > [ERROR]
> > ---
> >
> > The "big-parent" module is the top-level directory that is both the
> aggregator and parent pom.
> >
> > Conceptually, I think this is happening because Maven is trying to
> evaluate dependencies before those dependencies are built.  Again, I think
> the "separated" architecture will resolve this, but before I implement
> that, I need to understand exactly what is going on here.
> >
> > In my local workspace, I got around this by simply "cd"ing to the
> "another-module" directory and doing a "mvn install", then "cd"ing to
> "some-other-module", doing the same, and then doing the same again at the
> top level. The reality was messier than this, because I had quite a few
> modules that I had to build manually this way.
> >
> > Assuming I'm right that separating the "parent" function from the
> "aggregator" function would resolve this, can someone explain exactly what
> is happening here, how my assumed solution would resolve this, and whether
> there's a cleaner temporary workaround besides "cd"ing into each directory
> to do a separate install?
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> --
Sent from my phone

Save the date: ApacheCon Miami, May 15-19, 2017

[Rich Bowen]

Dear Apache enthusiast,

ApacheCon and Apache Big Data will be held at the Intercontinental in
Miami, Florida, May 16-18, 2017. Submit your talks, and register, at
http://apachecon.com/  Talks aimed at the Big Data section of the event
should go to
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
while other talks should go to
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp


ApacheCon is the best place to meet the people that develop the software
that you use and rely on. It’s also a great opportunity to deepen your
involvement in the project, and perhaps make the leap to contributing.
And we find that user case studies, showcasing how you use Apache
projects to solve real world problems, are very popular at this event.
So, do consider whether you have a use case that might make a good
presentation.

ApacheCon will have many different ways that you can participate:

Technical Content: We’ll have three days of technical sessions covering
many of the projects at the ASF. We’ll be publishing a schedule of talks
on March 9th, so that you can plan what you’ll be attending

BarCamp: The Apache BarCamp is a standard feature of ApacheCon - an
un-conference style event, where the schedule is determined on-site by
the attendees, and anything is fair game.

Lightning Talks: Even if you don’t give a full-length talk, the
Lightning Talks are five minute presentations on any topic related to
the ASF, and can be given by any attendee. If there’s something you’re
passionate about, consider giving a Lightning Talk.

Sponsor: It costs money to put on a conference, and this is a great
opportunity for companies involved in Apache projects, or who benefit
from Apache code - your employers - to get their name and products in
front of the community. Sponsors can start any any monetary level, and
can sponsor everything from the conference badge lanyard, through larger
items such as video recordings and evening events. For more information
on sponsoring ApacheCon, see http://apachecon.com/sponsor/

So, get your tickets today at http://apachecon.com/ and submit your
talks. ApacheCon Miami is going to be our best ApacheCon yet, and you,
and your project, can’t afford to miss it.

-- 
Rich Bowen - rbo...@apache.org
VP, Conferences
http://apachecon.com
@apachecon


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Structuring bigger Maven projects

[Karl Heinz Marbaise]

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 this is of course a good idea, especially when starting to create
new applications, the library projects will grow with the applications
and not independently of them. We cannot start by first investing months
to create the perfect will-work-for-ten-years library and only then
start coding the application that will, in the first months, only use
10% of all these features. So, realistically, during a development
cycle, both the application and the library will grow... (which doesn't
mean that we cannot separate them)

Which leads me, for example, to the problem that I still want to
automate as much as possible. I would like, for example, to click one
button in my build server, perhaps enter some parameters and get a new
release candidate of the libraries from the current release branch,
update the dependency version of the application to this rc version,
make the application an rc (from the application's release branch),
install them both into the repository, tag the current status on git and
deploy the rc application onto the server.

Especially for bigger projects, I want to keep the amount of manual work
needed as small as possible. As much building should be done
automatically, if possible. And I would like not having to code a
jenkins or maven plugin for that purpose (but of course, I would, if
needed, no problem there).



You can simply use maven-release-plugin (in Maven itself) which you can 
used to  fully automatically create releases of your project...This will 
need only a plugin in Jenkins which handles all those stuff...correctly 
configured things like scm entries in your pom file tagging in Git will 
be done as well


Sometimes you might need to improve that using the versions-maven-plugin 
in combination with some pipeline steps in Jenkins...which prevents some 
drawbacks of the maven-release-plugin



May be you need to think about using the Maven integration in Jenkins or 
using freestyle projects or better start using pipelines ...(I often 
observed performance drawbacks in relationship with Maven integration in 
Jenkins)...



https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin


Kind regards
Karl Heinz Marbaise



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Structuring bigger Maven projects

[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.


While this is of course a good idea, especially when starting to create 
new applications, the library projects will grow with the applications 
and not independently of them. We cannot start by first investing months 
to create the perfect will-work-for-ten-years library and only then 
start coding the application that will, in the first months, only use 
10% of all these features. So, realistically, during a development 
cycle, both the application and the library will grow... (which doesn't 
mean that we cannot separate them)


Which leads me, for example, to the problem that I still want to 
automate as much as possible. I would like, for example, to click one 
button in my build server, perhaps enter some parameters and get a new 
release candidate of the libraries from the current release branch, 
update the dependency version of the application to this rc version, 
make the application an rc (from the application's release branch), 
install them both into the repository, tag the current status on git and 
deploy the rc application onto the server.


Especially for bigger projects, I want to keep the amount of manual work 
needed as small as possible. As much building should be done 
automatically, if possible. And I would like not having to code a 
jenkins or maven plugin for that purpose (but of course, I would, if 
needed, no problem there).


Regards,

Flo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Structuring bigger Maven projects

[Christian Schulte]

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 that were modified, too. If they weren't 
> modified, we would preferably not release new versions of the shared 
> code, but that point if debatable.

A rule of thumb working well for many of us is that only things to be
released together are candidates for multi-module projects. Things to be
released independently should be independent projects. That does not
mean you cannot inherit from the same parent. 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. It's important to understand how to make use of
inheritance and aggregation [1]. You can also use the archetype plugin
to generate example/template projects by executing 'mvn archetype:generate'.



Regards,
-- 
Christian


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Structuring bigger Maven projects

[Florian Schätz]

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 applications, also 
sharing code with the other applications, are likely in the future.


All applications get deployed to tomcat servers (some applications might 
share the same server, others might have different servers - and of 
course, there are test servers and pre-release servers to consider as 
well).


We are currently a SCRUM team, so normally only one application will be 
actively developed in one development cycle ("sprint"), but after each 
cycle , we want to release a new version of the currently developed 
application and, if they were modified, also new versions of the shared 
code modules.


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 that were modified, too. If they weren't 
modified, we would preferably not release new versions of the shared 
code, but that point if debatable.


The whole thing is on GIT, currently in one repository, but of course, 
there are arguments for using separate repositories for the applications 
and the shared code. But my question aims more in the Maven direction 
(obviously), because there seem to be a lot of articles about the 
basics, but not many about more complex topics like handling more 
complex projects... (Or I am simply missing them).


Regards,

Flo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Structuring bigger Maven projects

[Oliver B. Fischer]

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 the basic stuff, default folders, etc. but somehow, I seem 
to keep missing the articles (and books) about the "big picture" for 
bigger projects...


For example, I am having slight problems deciding between one parent 
project with many modules (and how to version the modules differently 
and automatically)... I guess there are many considerations like this, 
so has anyone good literature on the topic?


Regards,

Flo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



--
N Oliver B. Fischer
A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany
P +49 30 44793251
M +49 178 7903538
E o.b.fisc...@swe-blog.net
S oliver.b.fischer
J oliver.b.fisc...@jabber.org
X http://xing.to/obf


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org