thank you for these explanations: I'll have a deep look tonight
Regards,
Hervé
Le lundi 19 décembre 2016, 04:12:01 CET Christian Schulte a écrit :
> Am 12/19/16 um 03:39 schrieb Christian Schulte:
> > Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> > You know what? We want also that libraries cla
Le lundi 19 décembre 2016, 00:44:48 CET Christian Schulte a écrit :
> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> > you are completely missing my point: simply put, when doing such risky
> > change (that require Review Then Commit), *please do it on a branch*, not
> > on master (that you'll later
Am 12/19/16 um 00:44 schrieb Christian Schulte:
> Master is WIP. Working on a branch does not make Jenkins check anything.
> I can continue to use my machine during Jenkins doing it's job. Running
> the ITs locally means my machine is unuseable for nearly an hour.
Ok. It's not nearly an hour but i
Am 12/19/16 um 03:39 schrieb Christian Schulte:
> Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> You know what? We want also that libraries classpath are consistent
> when built
>> and when used as dependencies: nothing specific to plugins and core
>> extensions.
>> Everything is built some time
Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
You know what? We want also that libraries classpath are consistent
when built
> and when used as dependencies: nothing specific to plugins and core
> extensions.
> Everything is built some time then used.
> If there are some unexpected discrepencies,
Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> Notice I use the word "update", not "fix": I don't care if you think that the
> required update is a positive fix because everything was buggy for 10 years
> and
> you're the guy who is saving us from the bugs we lived with: for normal
> users,
> i
Am 12/18/16 um 13:36 schrieb Robert Scholte:
> On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte
> wrote:
>
>> Am 12/16/16 um 20:30 schrieb Robert Scholte:
>>> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte
>>> wrote:
>>>
Am 12/16/16 um 15:21 schrieb Robert Scholte:
>
>
Am 12/18/16 um 10:19 schrieb Hervé BOUTEMY:
> you are completely missing my point: simply put, when doing such risky change
> (that require Review Then Commit), *please do it on a branch*, not on master
> (that you'll later revert to postpone to a future Maven version: tracking
> changes on mast
I like that plan, but let's call that 3.4.0 and let these other changes go
for either 3.5.0
Does someone want to take a stab at forking master from an earlier point
(perhaps get infra to let us rewrite master back to the fork point and push
the current state to a branch?)
On Sun 18 Dec 2016 at 19
No, I meant just eclipse->apache move, not all changes that went into
maven-resolver. The idea is to have a release branch we can maintain
while things stabilize in master.
--
Regards,
Igor
On Sun, Dec 18, 2016, at 12:46 PM, Michael Osipov wrote:
> Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
Am 2016-12-18 um 18:53 schrieb Robert Scholte:
Hi,
I got this question during Devoxx: is Maven IPv6 ready?
My guess is that this is something for Wagon to confirm.
How can we test it?
Shall we really answer that question? For all transports, we are using
third-party components and finally the
Hi,
I got this question during Devoxx: is Maven IPv6 ready?
My guess is that this is something for Wagon to confirm.
How can we test it?
Robert
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands,
Am 2016-12-18 um 18:44 schrieb Igor Fedorenko:
I wonder if it makes sense to release 3.3.10 with just the new aether
and give 3.4 more time to bake on master.
Changing a dependency with so many changes recently in a fix version?
Doesn't sound right to me.
M
--
I wonder if it makes sense to release 3.3.10 with just the new aether
and give 3.4 more time to bake on master.
--
Regards,
Igor
On Sun, Dec 18, 2016, at 07:33 AM, Robert Scholte wrote:
> I did investigate some time in this request. The conclusion is that the
> discussion should be in the open
On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte
wrote:
Am 12/16/16 um 20:30 schrieb Robert Scholte:
On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte
wrote:
Am 12/16/16 um 15:21 schrieb Robert Scholte:
but this cover the issue we are talking about, because IIUC you are
saying
I did investigate some time in this request. The conclusion is that the
discussion should be in the open and not in the private list of the Maven
PMC.
What I see are good intended changes, but the results are a chain of
commits where every change fixes one thing but at the same time breaks
Awesome, thanks!
Le 18/12/2016 à 12:52, Hervé BOUTEMY a écrit :
this was a bug on the Jenkins slave, the JDK installation should have been
there:
https://issues.apache.org/jira/browse/INFRA-13129
Gavin fixed it, the build is now passing even on this slave
Regards,
Hervé
Le dimanche 18 décem
this was a bug on the Jenkins slave, the JDK installation should have been
there:
https://issues.apache.org/jira/browse/INFRA-13129
Gavin fixed it, the build is now passing even on this slave
Regards,
Hervé
Le dimanche 18 décembre 2016, 11:10:21 CET Guillaume Boué a écrit :
> Hi,
>
> I notice
Am 2016-12-18 um 10:19 schrieb Hervé BOUTEMY:
you are completely missing my point: simply put, when doing such risky change
(that require Review Then Commit), *please do it on a branch*, not on master
(that you'll later revert to postpone to a future Maven version: tracking
changes on master is a
Hi,
I noticed the job of maven-parent on Jenkins is failing, because it's
apparently looking for a JDK installation that doesn't exist
(/home/jenkins/tools/java/latest1.6/bin/java).
https://builds.apache.org/job/maven-parent/2062/console
Can someone with authorization to change the configuratio
you are completely missing my point: simply put, when doing such risky change
(that require Review Then Commit), *please do it on a branch*, not on master
(that you'll later revert to postpone to a future Maven version: tracking
changes on master is a big giant mess lately, with updates and reve
21 matches
Mail list logo