Github user vaimr commented on the issue:
https://github.com/apache/maven-surefire/pull/122
The problem is that no surefire stores information about the test execution
time. I build tests in Jenkins pipeline script. He balances the tests by
run-time, breaks it into several blocks and
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/127
@britter No big problem. Can you always run build locally? AFAIK your PC is
running the build two hours. Normally 45 minutes in Jenkins and my PC Intel i7
4Core 3GHz SSD disk.
---
If your p
+1 (non-binding)
The timeframe for voting ends today... Is there anything, that should be
done on my end? Or got the email just lost between the other mails?
It's the first time I'm staging a release ;)
Regards,
Andreas
Am 10.10.2016 um 20:15 schrieb Andreas Dangel:
> Hi,
>
> We solved 1
+1 (binding)
Even if you key is available in public, you must/should add your key here
https://dist.apache.org/repos/dist/release/maven/KEYS
On 11 October 2016 at 05:15, Andreas Dangel wrote:
> Hi,
>
> We solved 11 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12
I ll be happy to help committing those patches in other repository. How
could I get write access to it. Any suggestion?
On Oct 8, 2016 2:39 AM, "Robert Scholte" wrote:
Hi,
it is not possible to merge these pullrequests at github, it is a read-only
clone. And in case of the plugins, they are stil
the issue is not to merge blindly any request: it is to check the content, if
it is not too specific to a user, if there is IT, etc...
then if you'd like to help, yes, we're interested to help you become a
committer: you'll need to gain merit by taking a PR, check that it looks ok to
you then t
I built the release and got a failure in an IT:
[INFO] Building: MPMD-187/pom.xml
[INFO] run script verify.groovy
[INFO] ..FAILED (4.4 s)
[INFO] The post-build script did not succeed. assert !pmdXml.exists()
|| |
|| true
|/home/herve/tmp/maven-pmd-plugin-3.7/target/
That's weird. I don't see this... I'm on Linux, too.
Works with Java7 and maven 3.3.1, 3.3.3, 3.3.9.
The integration job seems to be ok, too:
https://builds.apache.org/job/maven-plugins-ITs-m3/
Am 13.10.2016 um 19:43 schrieb Hervé BOUTEMY:
> I built the release and got a failure in an IT:
> [I
same issue with maven-pmd-plugin-3.6: there's something strange on my
machine...
then +1
Regards,
Hervé
Le jeudi 13 octobre 2016 20:02:27 Andreas Dangel a écrit :
> That's weird. I don't see this... I'm on Linux, too.
>
> Works with Java7 and maven 3.3.1, 3.3.3, 3.3.9.
>
> The integration jo
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/128
@Tibor17 I think I'll wait until this is reintegrated, before I make a PR
for merging master to junit5.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/128
---
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 Hervé,
Tunaki propose to update the PR with an IT based on a push on local file
... more simple & sustainable, and will push it.
Many thanks to you.
Best regards.
2016-10-13 8:44 GMT+02:00 Hervé BOUTEMY :
> Hi Alix,
>
> Thanks for the patch: I'll review it this WE.
>
>
> See you soon at next
Github user axel3rd closed the pull request at:
https://github.com/apache/maven-plugins/pull/95
---
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
GitHub user britter opened a pull request:
https://github.com/apache/maven-surefire/pull/129
Merge master to junit5 branch
As discussed on the ML.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/britter/maven-surefire merge-with-m
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/122
We have such feature in Surefire. It is called "runorder". Makes sense
since the second run.
On Thu, Oct 13, 2016 at 9:04 AM, Denis Saponenko
wrote:
> The problem is
Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/129
---
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
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/129
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 th
On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte
wrote:
Am 10/12/16 um 23:17 schrieb Robert Scholte:
It is a bit different: the *effective* settings are the global settings
where parts can be overridden with the user settings. This means that
all
profiles will be there, during build
Github user britter commented on the issue:
https://github.com/apache/maven-surefire/pull/129
Thank you!
---
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
Hello,
reverting seems safer. As settings always override stuff in poms, my guess
would be that having global defining stuff for central will blow stuff for
lots of people. Overriding central seems very natural. And user's settings
will survive updates of Maven it self.
Regards
Mirko
--
Sent fro
Am 10/13/16 um 21:52 schrieb Robert Scholte:
> I'd say revert these changes. We see that this "hack" doesn't always work.
> Better look for a more solid solution with another release in the future.
The better solution would be to completely remove repositories from the
poms and from all profiles
Am 10/13/16 um 21:52 schrieb Robert Scholte:
> On Thu, 13 Oct 2016 02:53:54 +0200, Christian Schulte
>> Should I change the order of the effective settings so that things from
>> the global settings always come before the user settings? Will that blow
>> up somewhere else. We know nothing about
22 matches
Mail list logo