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
Github user wangyf2010 closed the pull request at:
https://github.com/apache/maven-enforcer/pull/13
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feat
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 -
On Jun 15, 2014, at 11:01 AM, Hervé BOUTEMY wrote:
> Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit :
>> On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY wrote:
>>> Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
> yes, but how is the constraint expressed and coded?
Tr
Le dimanche 15 juin 2014 09:19:26 Jason van Zyl a écrit :
> On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY wrote:
> > Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
> >>> yes, but how is the constraint expressed and coded?
> >>
> >> Trying to encode these in such a way where you effectively
Hi,
We solved 2 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11132&version=18776
There are still 27 issues left in JIRA:
http://jira.codehaus.org/issues/?jql=project%20%3D%20MEAR%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
Staging repo:
https
On Jun 14, 2014, at 3:09 PM, Hervé BOUTEMY wrote:
> Le samedi 14 juin 2014 13:33:37 Jason van Zyl a écrit :
>>> yes, but how is the constraint expressed and coded?
>>
>> Trying to encode these in such a way where you effectively have a property
>> graph is hard. Aether has some preliminary supp
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/21#issuecomment-46114965
No, we do not use install on this particular project where we are
developing the concept of a generation. We either have a project in source form
locally, or we get it remo
> 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 defining their snapshot policy (and I
> > mean
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
14 matches
Mail list logo
