Didn't we agree on v3.5.0 to be a drop-in replacement for v3.3.9? IMO
fixing MNG-5868 wouldn't fit in that.
I'm sorry to say, but I think we're heading back to where we were before
the reset.
/Anders
On Wed, Feb 1, 2017 at 8:42 AM, Hervé BOUTEMY wrote:
> https://issues.apache.org/jira/browse/M
https://issues.apache.org/jira/browse/MNG-5868
Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
does not produce a failure
by reading the Jira entry, I can't understand what has been done and what is
the effective impact: IIUC, Maven core becomes more picky, expected
seconded
Regards,
Hervé
Le mercredi 1 février 2017, 05:39:16 CET Christian Schulte a écrit :
> Hi,
>
> I'd also like to make MNG-5981 part of 3.5.0. It is just an upgrade to a
> dependency needed to fix a bug. Anyone second that?
>
> Regards,
Hi,
I'd also like to make MNG-5981 part of 3.5.0. It is just an upgrade to a
dependency needed to fix a bug. Anyone second that?
Regards,
--
Christian
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional co
Github user jsoref commented on the issue:
https://github.com/apache/maven/pull/100
done
---
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 feature
Hi,
I'd like to make MNG-5868 FIX-3.5.0. There have been plugin issues
solved by this. I know Karl-Heinz worked on some of those plugin issues.
If this does not get released, those plugin issues may need to be
re-opened. Anyone second FIX-3.5.0?
Regards,
--
Christian
---
Am 01/31/17 um 23:23 schrieb Christian Schulte:
> Before the reset I did A. On the branch I did B. Do not ask me why I did
> it differently this time. Maybe because I reviewed the versions in more
> detail this time. While at it: I somehow get the feeling that those ITs
> really should be unit test
Before the reset I did A. On the branch I did B. Do not ask me why I did
it differently this time. Maybe because I reviewed the versions in more
detail this time. While at it: I somehow get the feeling that those ITs
really should be unit tests. I added the exact same tests to the core as
unit test
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/114
@Fuud
We had an internal collision and I tried to recover from this and reverted
11 commits and now trying to fix them and add the last jira fix and then cut
the release version. Please t
thx hervé
On Tue, Jan 31, 2017 at 10:34 PM, wrote:
> seconded for 3.5.0
> yes, basic bug fix
>
> Regards,
>
> Hervé
>
> - Mail original -
> De: "Arnaud Héritier"
> À: "Maven Developers List"
> Envoyé: Mardi 31 Janvier 2017 21:44:09
> Objet: MNG-5961 for 3.5.0 ?
>
> Hi,
>
> This is a so
seconded for 3.5.0
yes, basic bug fix
Regards,
Hervé
- Mail original -
De: "Arnaud Héritier"
À: "Maven Developers List"
Envoyé: Mardi 31 Janvier 2017 21:44:09
Objet: MNG-5961 for 3.5.0 ?
Hi,
This is a so easy one I fixed a long time ago in master :
https://issues.apache.org/jira/bro
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
Cool @michael-o it is exactly what I did
the build is in progress
https://builds.apache.org/view/Maven/job/maven-3.x-jenkinsfile/job/MNG-5961/
---
If your project is set up for it, you can
Ok so, we'll need to knock this one out and see if there is a consensus.
My position is that I only have a slight preference for A over B and I
cannot fully articulate why.
Michael, do you feel you can present a reasoned argument in favour of A and
we'll let one of the B proponents present their
Github user michael-o commented on the issue:
https://github.com/apache/maven/pull/104
Do this:
git checkout master
git checkout -b MNG-5961
git cherry-pick
git push
Wait for the Jenkins build to finish, get approval
git checko
Hi,
This is a so easy one I fixed a long time ago in master :
https://issues.apache.org/jira/browse/MNG-5961
I originally sent it as PR on GitHub and now I created a branch MNG-5961 in
our repo
WDYT?
--
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
@michael-o we don't have a CI validation here, thus I have to open a real
branch on ASF side. Right ?
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Am 2017-01-31 um 20:23 schrieb Stephen Connolly:
Looking like a consensus on B.
I am actually in favor of A. How do you want to assure with B that the
will be properly handled for current master as you fixed the test for
released versions?
Michael
On Tue 31 Jan 2017 at 12:51, Anders Hamma
Github user michael-o commented on the issue:
https://github.com/apache/maven/pull/104
I am fine with this PR. You have to raise the issue on the dev mailing list
to have at least someone who seconds it. If someone does, after your branch
passes all tests, go ahead and merge into mast
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
I think @stephenc will tell me to push a branch on ASF side :-)
---
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 n
Github user aheritier commented on the issue:
https://github.com/apache/maven/pull/104
cc @michael-o @stephenc
https://issues.apache.org/jira/browse/MNG-5961
---
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 pr
On Tue 31 Jan 2017 at 19:29, Michael Osipov wrote:
> Am 2017-01-22 um 11:22 schrieb Stephen Connolly:
> > I'm currently waiting on Hervé to start the 1.0.3 release of resolver.
> >
> > Once we get that I'm going to start cutting RCs (I plan 2 a week apart)
> >
> > Once we have a stable RC I will
Am 2017-01-22 um 11:22 schrieb Stephen Connolly:
I'm currently waiting on Hervé to start the 1.0.3 release of resolver.
Once we get that I'm going to start cutting RCs (I plan 2 a week apart)
Once we have a stable RC I will cut the release, and start a clock towards
3.5.1 (6 weeks approx)
Two
Am 2017-01-31 um 03:37 schrieb Hervé BOUTEMY:
Le dimanche 29 janvier 2017, 22:11:16 CET Michael Osipov a écrit :
Am 2017-01-29 um 20:47 schrieb Hervé BOUTEMY:
resolver integration is ready in MNG-6110 branch: please review
I'll merge in 48h
I believe that bfc35976e2883bb922ef6e1787917a2821553
Looking like a consensus on B.
Let's lazy this one.
On Tue 31 Jan 2017 at 12:51, Anders Hammar wrote:
> I favor B.
>
> /Anders
>
> On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > We have kind of established a consensus on how to handle the ca
Github user Fuud commented on the issue:
https://github.com/apache/maven-surefire/pull/114
Any updates?
---
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
Github user michael-o commented on the issue:
https://github.com/apache/maven/pull/100
Can you rebase your changes and squash into one commit? I want to pull them
in with
[MNG-6146](https://issues.apache.org/jira/browse/MNG-6146?src=confmacro).
---
If your project is set up for it,
Github user michael-o commented on the issue:
https://github.com/apache/maven-indexer/pull/12
Looking at your changes, they are not really related. They all require
appropriate JIRA issues and seperate PRs.
---
If your project is set up for it, you can reply to this email and have yo
I favor B.
/Anders
On Tue, Jan 31, 2017 at 12:42 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> We have kind of established a consensus on how to handle the case where we
> want to change the specification of how Maven works going forward.
> Specifically, if we decide that the
I would prefer B
On Tue, Jan 31, 2017 at 1:34 PM, Igor Fedorenko wrote:
> > B. Fix the test, but exclude the broken versions of Maven from the range
> with a comment explaining why
>
> I sometimes rerun integration tests against released versions of Maven
> to validate the tests are still workin
> B. Fix the test, but exclude the broken versions of Maven from the range
with a comment explaining why
I sometimes rerun integration tests against released versions of Maven
to validate the tests are still working and I know other developers who
do that too. Having failures would just mean tests
We have kind of established a consensus on how to handle the case where we
want to change the specification of how Maven works going forward.
Specifically, if we decide that the old behaviour of Maven is no longer
going to be the new behaviour of Maven our procedure in the integration
tests is as f
GitHub user aheritier opened a pull request:
https://github.com/apache/maven/pull/104
[MNG-5961] Fix the SLF4J logger factory implementation used for LOG4J2
This is the fix I did in
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blobdiff;f=maven-embedder/src/main/resources/ME
32 matches
Mail list logo
