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.
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
> -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 o
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
> -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 w
> -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:
>
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/te
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 artif
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
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
> >
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
> -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 corr
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 exam
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-bi
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 thi
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 star
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 t
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
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, defa
19 matches
Mail list logo