On 18 Jun 2014, at 17:05, Barrie Treloar wrote:
It takes a small (but not negligible) amount of time to haul the
release
jars from you local Maven Repository - likely also hosted on your CI
server.
Plus pulling in any snapshots previously deployed.
The problem gets extended further when you'
On 18 Jun 2014, at 20:50, Stephen Connolly wrote:
Thus you can declare upstream literate projects and branch matching
criteria... an upstream project's local repository
The problem here is the way Gerrit presents its reviews, they're not
publicly accessible branches so there IS no matching br
Well one of the features I want to write for the literate project type in
Jenkins is a smarter Maven awareness...
Thus you can declare upstream literate projects and branch matching
criteria... an upstream project's local repository cache will then be
exposed to downstream projects... but on a bra
On 18 June 2014 13:48, Mark Derricutt wrote:
> You assume CI servers have intelligence and deep knowledge of Maven. Or
> that you have deep control over their configuration.
>
> You can't do that with Travis CI, nor with Code-review tools such as
> Gerrit ( not cleanly, not without doing evil thi
You assume CI servers have intelligence and deep knowledge of Maven. Or
that you have deep control over their configuration.
You can't do that with Travis CI, nor with Code-review tools such as
Gerrit ( not cleanly, not without doing evil things with maven configs
like I mention in [1] ).
St
On 18 June 2014 12:23, Mark Derricutt wrote:
> Interesting, I hadn't noticed this was only a warning.
>
> The main problem I have is the moment you start relying on these fake
> reactors you end up breaking C.I. builds with dependant changes.
>
Why?
Your CI should know that project B depends upo
Interesting, I hadn't noticed this was only a warning.
The main problem I have is the moment you start relying on these fake
reactors you end up breaking C.I. builds with dependant changes.
This is my main beef with multiple git repositories for projects - if
you have a pairing of dependant c
That's it... and also note that while Maven complains if the pom at the
specified is not the parent, it will build correctly ...
just resolving the parent from the local repository and not from the disk.
On 16 June 2014 06:05, Barrie Treloar wrote:
> On 16 June 2014 14:12, Stephen Connolly
>
On 16 June 2014 14:12, Stephen Connolly
wrote:
> On Sunday, 15 June 2014, Mark Derricutt wrote:
>
> > So if I have two modules that are interdependent on in-progress changes,
> > how does one build/test the dependant one.
> >
> > Note - reactor builds and multi-modules builds are out of the ques
On Sunday, 15 June 2014, Mark Derricutt wrote:
> So if I have two modules that are interdependent on in-progress changes,
> how does one build/test the dependant one.
>
> Note - reactor builds and multi-modules builds are out of the question -
> the above modules are in separate git repositories
On Jun 15, 2014, at 5:45 PM, Mark Derricutt wrote:
> So if I have two modules that are interdependent on in-progress changes, how
> does one build/test the dependant one.
>
This setup is just normal and works in m2e with Eclipse's workspace resolution.
I can have an arbitrary graph of project
On 15 Jun 2014, at 21:07, Stephen Connolly wrote:
I favour never deploying smapshots to developer repositories... Any
time
Agree fully on not deploying snapshots - but I'm talking about locally
INSTALLED snapshots.
broken shit for... Timestamped snapshots are just a crutch...
Agreed tota
So if I have two modules that are interdependent on in-progress changes,
how does one build/test the dependant one.
Note - reactor builds and multi-modules builds are out of the question -
the above modules are in separate git repositories and there's no way to
create a "fake reactor" setup -
> To: dev@maven.apache.org
> Subject: Re: A thought on local-SNAPSHOTs
> Date: Sun, 15 Jun 2014 13:08:17 +0200
> From: rfscho...@apache.org
>
> Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly
> :
>
> > The real issue I see is people not definin
Op Sun, 15 Jun 2014 11:07:33 +0200 schreef Stephen Connolly
:
The real issue I see is people not defining their snapshot policy (and I
mean that in a wider sense)
Personally speaking I favour *never* deploying snapshots. Only using them
for local speed up where a large reactor required to wir
The real issue I see is people not defining their snapshot policy (and I
mean that in a wider sense)
Personally speaking I favour *never* deploying snapshots. Only using them
for local speed up where a large reactor required to wire everything up
using either the `package` or `verify` phase (with
I definitely like that. At times (and many times) I want to blow away all
my local snapshots. Having a separate local repo for that would be a nice
separation.
Cheers,
Paul
On Sat, Jun 14, 2014 at 10:12 PM, Mark Derricutt wrote:
> Hey all,
>
> A recent discussion on one of the github PR's led
17 matches
Mail list logo
