maven-compiler-plugin 4: integration tests completed

Hello all The proposed maven-compiler-plugin version 4 now passes the integration tests. It has reached a state where it could (theoretically) be used instead of version 3, but there is probably some more bugs to discover. Many tests had to be modified, and a few of them have been deleted

[GitHub] [maven-site-plugin] elharo merged pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

elharo merged pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to g

[GitHub] [maven-site-plugin] bertysentry commented on pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

bertysentry commented on pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39#issuecomment-788041050 Awesome news! :-) This is an automated message from the Apache Git Service. To respond to the message,

[GitHub] [maven-site-plugin] elharo commented on pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

elharo commented on pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39#issuecomment-788034268 Looks good. CI is slow today, but I'll merge as soon as they all pass. Thanks! This is an automated messag

[GitHub] [maven-site-plugin] mthmulders commented on pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

mthmulders commented on pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39#issuecomment-788023747 The remaining tests are also fixed by upgrading the Maven Javadoc Plugin. Just pushed. This is an auto

[GitHub] [maven-site-plugin] elharo commented on pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

elharo commented on pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39#issuecomment-787975296 Running through Jenkins: https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-site-plugin/job/msite-871/ Given that this fixes some tests, and does n

[GitHub] [maven-site-plugin] bertysentry commented on pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

bertysentry commented on pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39#issuecomment-787963914 This is cool, thank you! We're making good progress as only 2 integration tests are now failing: ``` Error: The following builds failed: Error: *

[GitHub] [maven-site-plugin] mthmulders opened a new pull request #39: [MSITE-871] Upgrade Maven Javadoc Plugin in integration tests

mthmulders opened a new pull request #39: URL: https://github.com/apache/maven-site-plugin/pull/39 These test failed on macOS with Java above 8; now they pass with Java 8, 11 and 15 on macOS. This is an automated message f

Re: How to see output for failing integration tests on jenkins

Hi Ian, To access additional files, such as IT output files, you need to tell Jenkins to save them as “artifacts”. This page tells how, if your project is using Jenkinsfiles (which are highly recommended): https://www.jenkins.io/doc/pipeline/tour/tests-and-artifacts/ Something similar ca

Re: How to see output for failing integration tests on jenkins

Blue Ocean is quite detailed: https://builds.apache.org/blue/organizations/jenkins/maven-box%2Fmaven-dependency-plugin/detail/te/1/pipeline On 5-8-2020 20:18:23, Ian Lavallee wrote: Hi, I'm trying to figure out why tests that pass locally are failing on Jenkins. When I run the tests locally I ca

How to see output for failing integration tests on jenkins

Hi, I'm trying to figure out why tests that pass locally are failing on Jenkins. When I run the tests locally I can go target\it\test to see the output, build log, etc. of each integration test but I can't figure out how to do that on Jenkins. Does anyone know how to do this or how to get more inf

Re: [VOTE] - Integration Tests of Maven Core

+1 good point to tag the sources with same version of Maven On Sat, Dec 21, 2019 at 3:18 PM Karl Heinz Marbaise wrote: > I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which > preserves the state of the history and furthermore we should create a > tag after each M

Re: [VOTE] - Integration Tests of Maven Core

Le vendredi 27 décembre 2019, 12:37:10 CET Karl Heinz Marbaise a écrit : > Hi, > > On 27.12.19 12:21, Karl Heinz Marbaise wrote: > > Hi, > > > I've created a tag on the Maven Integration Testing: > Hervé was faster than I was... no, no, you did the tag this was just on one of my commits :) > >

Re: [VOTE] - Integration Tests of Maven Core

rt of our release indirectly... Kind regards Karl Heinz Marbaise On Sun, 22 Dec 2019 at 00:18, Karl Heinz Marbaise wrote: I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which preserves the state of the history and furthermore we should create a tag after each Maven Core re

Re: [VOTE] - Integration Tests of Maven Core

Hi, On 27.12.19 12:21, Karl Heinz Marbaise wrote: Hi, I've created a tag on the Maven Integration Testing: Hervé was faster than I was... Named: its-maven-3.6.3 which is pointing to the state of the tests for Apache 3.6.3 release. This keeps the history of the tests and gives us the ch

Re: [VOTE] - Integration Tests of Maven Core

Hi, I've created a tag on the Maven Integration Testing: Named: its-maven-3.6.3 which is pointing to the state of the tests for Apache 3.6.3 release. This keeps the history of the tests and gives us the chance to clean up the test suites.. Kind regards Karl Heinz Marbaise -

Re: [VOTE] - Integration Tests of Maven Core

do we really need a vote for this? this seems to be overadministrativing :) it's not a release or produce any artifacts so just do it On Sun, 22 Dec 2019 at 00:18, Karl Heinz Marbaise wrote: > I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which > preserves the s

Re: [VOTE] - Integration Tests of Maven Core

+1 On Sat, Dec 21, 2019 at 9:18 AM Karl Heinz Marbaise wrote: > > I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which > preserves the state of the history and furthermore we should create a > tag after each Maven Core release. > > Vote open for at least 72

Re: [VOTE] - Integration Tests of Maven Core

Hi, On 21.12.19 15:23, Enrico Olivelli wrote: +1 Please also update the release guide That should be done of course. thanks for the hint. Enrico Il sab 21 dic 2019, 15:18 Karl Heinz Marbaise ha scritto: I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which preserves

Re: [VOTE] - Integration Tests of Maven Core

+1 Please also update the release guide Enrico Il sab 21 dic 2019, 15:18 Karl Heinz Marbaise ha scritto: > I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which > preserves the state of the history and furthermore we should create a > tag after each Maven Cor

[VOTE] - Integration Tests of Maven Core

I suggest to create a tag 3.6.3 in Integration Tests of Maven Core which preserves the state of the history and furthermore we should create a tag after each Maven Core release. Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1 Kind regards Karl Heinz Marbaise

Re: Integration Tests of Maven Core

renaming a method could easily break the ability of an integration > test to even compile with the version that matters. Project history > belongs in the source code control system, not the current HEAD > branch. > > On Sun, Dec 8, 2019 at 2:10 PM Karl Heinz Marbaise wrote: >>

Re: Integration Tests of Maven Core

a method could easily break the ability of an integration test to even compile with the version that matters. Project history belongs in the source code control system, not the current HEAD branch. On Sun, Dec 8, 2019 at 2:10 PM Karl Heinz Marbaise wrote: > > Hi, > I'm diving a li

Re: Integration Tests of Maven Core

reate tag on the integration tests as well which currently do not exist (which I find a problematic). 3. Dropping everything which has no value anymore This means removing any tests which are Maven 2 releated (Of course doing something as mentioned before) as first step. This will

Re: Integration Tests of Maven Core

I probably don't understand something but if you change anything in maven you shouldn't have to touch the Integration tests? I understand that the volume of code in integration tests is important but my understand is that we should never touch to them (excepted to change a condition if

Re: Integration Tests of Maven Core

est thing done in the project. > > > Having a separate repo avoids that you refactor a test with the > codebase > > > and thus you have to explicitly update the IT if you change something. > > > Having the whole history is helping to maintain old versions and even &

Re: Integration Tests of Maven Core

test with the codebase > > and thus you have to explicitly update the IT if you change something. > > Having the whole history is helping to maintain old versions and even if > > it's not done by us (the community) it is useful for others > > > > On Mon, Dec 9,

Re: Integration Tests of Maven Core

is helping to maintain old versions and even if > it's not done by us (the community) it is useful for others > > On Mon, Dec 9, 2019 at 8:40 AM Enrico Olivelli > wrote: > > > Karl, > > In my opinion I would like to drop anything that is not useful. > > > >

Re: Integration Tests of Maven Core

nything that is not useful. > > I would also like to merge the integration tests repository with the maven > core repository, this way it is clear that the ITs are for the same > version. > > Can you tell more about the reasons behind having two separate repos? > > Enr

Re: Integration Tests of Maven Core

Karl, In my opinion I would like to drop anything that is not useful. I would also like to merge the integration tests repository with the maven core repository, this way it is clear that the ITs are for the same version. Can you tell more about the reasons behind having two separate repos

Re: Integration Tests of Maven Core

Please don’t ever remove any of the integration tests. If they don’t apply to specific versions they are skipped as you see and there’s no harm. They serve as a historical record of what features work in a particular version. I’ve not done specific Maven work for any customer recently, but it

Integration Tests of Maven Core

Hi, I'm diving a little bit into the integration tests of maven core... and I realized that at the moment this list of IT's is SKIPPED based on the version of Maven Core: mng5889FindBasedir(MvnFileLongOptionModule).SKIPPED - Maven version 3.7.0-SNAPSHOT not in range [3

Re: Trying to fix integration tests of mvn-site-plugin

what you describe looks like MPIR-373 AFAIK, this does not fail the build I tried to run the maven-site-plugin build on my computer and got the 2 failing ITs, and for fullreporting it displays: [INFO] Building: full-reporting/pom.xml [INFO] run post-build script verify.groovy [INFO] ful

Re: Trying to fix integration tests of mvn-site-plugin

I would expect there's a difference between the local pom (buildpom) and the external poms (consumer poms). In case of the latter this tag shouldn't be an issue, however for the local pom it should. Poms will now probably go through the same validator. thanks, Robert On Sun, 18 Nov 2018 16:0

Trying to fix integration tests of mvn-site-plugin

Hi, I looked into fixing the Hudson build of maven-site-plugin https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/ There are two "it" failing, one of them is the fullreporting. This fullreporting

[GitHub] maven-integration-testing pull request #20: Integration tests for various JI...

GitHub user ChristianSchulte opened a pull request: https://github.com/apache/maven-integration-testing/pull/20 Integration tests for various JIRA issues. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ChristianSchulte/maven

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass plugin integration tests on Windows

ssed a > release build not passing plugin integration tests on Windows. > > <https://builds.apache.org/job/maven-master-release-status> > > Please review the following build job for any issues with changes to the > Maven master branch. > > <https://builds.apa

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass plugin integration tests on Linux

ssed a > release build not passing plugin integration tests on Linux. > > <https://builds.apache.org/job/maven-master-release-status> > > Please review the following build job for any issues with changes to the > Maven master branch. > > <https://builds.apache.o

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass plugin integration tests on Windows

passed a > release build not passing a surefire build on Windows including integration > tests. > > <https://builds.apache.org/job/maven-master-release-status> > > Please review the following build job for any issues with changes to the > Maven master branch. > &g

Re: [PING] The GIT master branch of Maven has unreleased changes that do not pass a surefire build including integration tests on Linux

ssed a > release build not passing a surefire build on Linux including integration > tests. > > <https://builds.apache.org/job/maven-master-release-status> > > Please review the following build job for any issues with changes to the > Maven master branch. > &g

Re: [DISCUSS] How do we want to handle false positives in the integration tests

https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=92a11a96 (not using annotations because our integration tests are JUnit 3.8.x style) On 1 February 2017 at 20:03, Christian Schulte wrote: > Am 02/01/17 um 20:05 schrieb Stephen Connolly: > > I wou

Re: [DISCUSS] How do we want to handle false positives in the integration tests

Am 02/01/17 um 20:05 schrieb Stephen Connolly: > I would rather modify verifier to allow recording versions we expect to > fail vs versions we expect to pass. +1 On method level instead of class level. Maybe by employing annotations one can add to methods like @SupportedBy.

Re: [DISCUSS] How do we want to handle false positives in the integration tests

aviour of Maven our procedure in the integration tests is as follows: 1. Mark the existing tests that are affected as range limited where the upper bound is the below the version of Maven that the change in behaviour will land in 2. Create tests of the new behaviour (probably copied from the ori

Re: [DISCUSS] How do we want to handle false positives in the integration tests

or 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

Re: [DISCUSS] How do we want to handle false positives in the integration tests

shed 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 follows: 1. Mark the existi

Re: [DISCUSS] How do we want to handle false positives in the integration tests

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

Re: [DISCUSS] How do we want to handle false positives in the integration tests

m> 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 old behav

Re: [DISCUSS] How do we want to handle false positives in the integration tests

> 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 old behaviour of Maven is no long

Re: [DISCUSS] How do we want to handle false positives in the integration tests

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 follows: 1. Mark the existing tests that are affected as range limited where the upper bound is the below the version of Maven that the change in behaviour will l

Re: [DISCUSS] How do we want to handle false positives in the integration tests

ished 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

Re: [DISCUSS] How do we want to handle false positives in the integration tests

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 follows: > > 1. Mark the existing tests that are affected as range limited where the > upper bound is the below the version of Maven that the c

Re: [DISCUSS] How do we want to handle false positives in the integration tests

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 t

Re: [DISCUSS] How do we want to handle false positives in the integration tests

> 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 m

[DISCUSS] How do we want to handle false positives in the integration 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

[RESULT] [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

.0-SNAPSHOT. More critically, JIRA issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally the informal practice of keeping existing integration tests > as RT

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

> I like this idea of avoiding force pushing, but I'm not git expert to know > exactly if this gives exactly the intended result = start clean and not > have noise when doing bisects or git blame It's clean for our own repo but might probably screw up cloned repos as they cannot just git-pull an

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

> > > > >> colourization and launcher script bug fixes. > > > > >> > > > > >> Given that some developer private builds of the current master branch > > have > > > > >> been shared with as 3.4.0-SNAPSHOT. More critically,

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

uncher script bug fixes. > > >> > > >> Given that some developer private builds of the current master branch > have > > >> been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have > been > > >> closed with a fixed version of 3.4.0. > > &

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

keeping existing integration tests as RTC has not been followed, leading to some people to question whether the integration tests remain valid. For all the above reasons it is proposed to do *all* the following as an whole: 1. In git://git.apache.org/maven.git we will rename the current master branch to `

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

If we were *throwing away* the other commits then that would work. But as I understand it, ours would mean that the commits are part of the history, so merging would not apply them... tooling to check if they need to be cherry picked would show as already merged... I'd need to check if cherry pick

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

tionally the informal practice of keeping existing integration tests as > RTC has not been followed, leading to some people to question whether the > integration tests remain valid. > > For all the above reasons it is proposed to do *all* the following as an > whole: > > 1. I

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

I like this idea of avoiding force pushing, but I'm not git expert to know exactly if this gives exactly the intended result = start clean and not have noise when doing bisects or git blame this technical discussion should probably on a separate email thread, to not pollute the vote thread Any

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

> > > For us to release a 3.4.0 with those fixes reverted, could cause > confusion > > > with our user community. > > > > > > Additionally the informal practice of keeping existing integration tests > as > > > RTC has not been followed, le

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

osed with a fixed version of 3.4.0. > > > > > > For us to release a 3.4.0 with those fixes reverted, could cause > confusion > > > with our user community. > > > > > > Additionally the informal practice of keeping existing integration tests >

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

s 3.4.0-SNAPSHOT. More critically, JIRA issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally the informal practice of keeping existing integration tests as

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

builds of the current master branch have > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

version of 3.4.0. For us to release a 3.4.0 with those fixes reverted, could cause confusion with our user community. Additionally the informal practice of keeping existing integration tests as RTC has not been followed, leading to some people to question whether the integration tests remain valid. F

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

y, JIRA issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally the informal practice of keeping existing integration tests as > RTC has not been followed,

[DISCUSS] [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

This would be better on the discuss thread, but here is my answer anyway: Well we want to bring most of that history back in for 3.5.1+ so, no that wouldn't work AIUI. Part of the issue is the to and fro with things like the bump of modelVersion to 4.1.0 and then the revert, etc. Plus if the com

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

On 5 Jan 2017, at 1:16, Stephen Connolly wrote: > As this involves a --force push on the `master` branch, we want to get the > approval of the committers before continuing. You _could_ branch at the point you want to reset to, then use an ours/theirs merge strategy which creates a merge commit t

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

xed version of 3.4.0. For us to release a 3.4.0 with those fixes reverted, could cause confusion with our user community. Additionally the informal practice of keeping existing integration tests as RTC has not been followed, leading to some people to question whether the integration tests remain v

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

A issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally the informal practice of keeping existing integration tests as > RTC has not been followed,

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

rted, could cause confusion >> with our user community. >> >> Additionally the informal practice of keeping existing integration tests >> as >> RTC has not been followed, leading to some people to question whether the >> integration tests remain valid. >> >

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

th a fixed version of 3.4.0. For us to release a 3.4.0 with those fixes reverted, could cause confusion with our user community. Additionally the informal practice of keeping existing integration tests as RTC has not been followed, leading to some people to question whether the integration te

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

t; > colourization and launcher script bug fixes. > > > > > > > > > > Given that some developer private builds of the current master branch > > have > > > > > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have > > bee

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

> been > > > closed with a fixed version of 3.4.0. > > > > > > For us to release a 3.4.0 with those fixes reverted, could cause > confusion > > > with our user community. > > > > > > Additionally the informal practice of keeping existing integ

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally the informal practice of keeping existing integration

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

have > been shared with as 3.4.0-SNAPSHOT. More critically, JIRA issues have been > closed with a fixed version of 3.4.0. > > For us to release a 3.4.0 with those fixes reverted, could cause confusion > with our user community. > > Additionally the informal practice of keeping existi

[VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

ould cause confusion with our user community. Additionally the informal practice of keeping existing integration tests as RTC has not been followed, leading to some people to question whether the integration tests remain valid. For all the above reasons it is proposed to do *all* the following a

Re: [SUREFIRE] Bring more order in the integration tests project?

the moment the integration test project has a directory containing > almost all integration tests. The Jira issue related tests are located in > a > sub package. The test/resources directory contains all the test projects > with no further ordering. This makes it hard to navigate through th

[SUREFIRE] Bring more order in the integration tests project?

Hello, at the moment the integration test project has a directory containing almost all integration tests. The Jira issue related tests are located in a sub package. The test/resources directory contains all the test projects with no further ordering. This makes it hard to navigate through the

[GitHub] maven-surefire issue #125: Consistently rename JUnit 4.x integration tests

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/125 @britter 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 wishe

[GitHub] maven-surefire issue #125: Consistently rename JUnit 4.x integration tests

Github user britter commented on the issue: https://github.com/apache/maven-surefire/pull/125 @Tibor17 rebased with master. --- 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 enable

[GitHub] maven-surefire issue #125: Consistently rename JUnit 4.x integration tests

Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/125 @britter It makes me a problem to merge this PR. Please open a new one with same changes. --- If your project is set up for it, you can reply to this email and have your reply appear on

[GitHub] maven-integration-testing pull request #14: MNG-6049: Adds integration tests...

Github user asfgit closed the pull request at: https://github.com/apache/maven-integration-testing/pull/14 --- 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 t

[GitHub] maven-integration-testing issue #14: MNG-6049: Adds integration tests for ve...

Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o Done. ITs passed. Merge conflict solved. --- 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 d

[GitHub] maven-integration-testing issue #14: MNG-6049: Adds integration tests for ve...

Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o Rename already done. ITs running locally right now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If you

[GitHub] maven-integration-testing issue #14: MNG-6049: Adds integration tests for ve...

Github user michael-o commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @barthel Can you also take care of the file names in the PR? `mng3092` to `mng-6049`. --- If your project is set up for it, you can reply to this email and have your reply appear

[GitHub] maven-integration-testing issue #14: MNG-3092: Adds integration tests for ve...

Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 Relabelling commit from MNG-3092 to MNG-6049. --- 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 no

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67946906 --- Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java --- @@ -0,0 +1,132 @@

[GitHub] maven-integration-testing issue #14: MNG-3092: Adds integration tests for ve...

Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o 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 a

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67945228 --- Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java --- @@ -0,0 +1,132 @@

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67942011 --- Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java --- @@ -0,0 +1,132 @@

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67941526 --- Diff: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3092VersionRangeResultFilterExtensionTest.java --- @@ -0,0 +1,132 @@

[GitHub] maven-integration-testing issue #14: MNG-3092: Adds integration tests for ve...

Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o 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 a

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67776474 --- Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/pom.xml --- @@ -0,0 +1,73 @@ + + + + +http://maven

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user barthel commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67776182 --- Diff: core-it-suite/src/test/resources/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom --- @@ -2

[GitHub] maven-integration-testing issue #14: MNG-3092: Adds integration tests for ve...

Github user barthel commented on the issue: https://github.com/apache/maven-integration-testing/pull/14 @michael-o Missing JARs added and changes included. Integration tests run successfully: ``` […] --- T

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233942 --- Diff: core-it-suite/src/test/resources/mng-3092/repo/org/apache/maven/its/mng3092/a/2.0-SNAPSHOT/a-2.0-20100408.111215-1.pom --- @@

[GitHub] maven-integration-testing pull request #14: MNG-3092: Adds integration tests...

Github user michael-o commented on a diff in the pull request: https://github.com/apache/maven-integration-testing/pull/14#discussion_r67233825 --- Diff: core-it-suite/src/test/resources/mng-3092/filter-extension/src/main/java/org/apache/maven/its/extensions/MavenITVersionRangeResultF

  1   2   3   4   >