Re: Structuring bigger Maven projects

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.

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

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

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

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

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 On Wed, Nov 30, 2016 at 4:54 PM, KARR, DAVID wrote: > > -Original Message- > > From: Dan Tran [mailto:dant...@gmail.com] > > Sent:

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

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

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

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

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

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

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

Re: Structuring bigger Maven projects

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

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 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,

Re: Structuring bigger Maven projects

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

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

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

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? 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

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

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

Re: Structuring bigger Maven projects

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

Re: Structuring bigger Maven projects

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

Re: Structuring bigger Maven projects

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

Re: Structuring bigger Maven projects

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

Re: Structuring bigger Maven projects

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,