date:20170612

[GitHub] maven-enforcer pull request #23: Adding RequireUpperBoundDeps.excludes optio...

2017-06-12 Thread jglick

GitHub user jglick opened a pull request:

https://github.com/apache/maven-enforcer/pull/23

Adding RequireUpperBoundDeps.excludes option

Needed to implement 
[JENKINS-41631](https://issues.jenkins-ci.org/browse/JENKINS-41631): there are 
certain known cases (that for various reasons cannot be fixed any time in the 
near future) where a dependency is older than a transitive version, yet this 
has been manually confirmed as acceptable, and we wish to enforce the ban for 
everything else. Analogous to exclude options on various other rules.

@reviewbybees for my colleages

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jglick/maven-enforcer 
RequireUpperBoundDeps.excludes

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-enforcer/pull/23.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #23






---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-enforcer pull request #22: Site fixes

2017-06-12 Thread jglick

GitHub user jglick opened a pull request:

https://github.com/apache/maven-enforcer/pull/22

Site fixes

Some fixes I found desirable or necessary when testing site generation 
locally.

@reviewbybees for my colleagues

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jglick/maven-enforcer site-fixes

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-enforcer/pull/22.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #22


commit 765fb8eec32a730e247779008f8630da8407fafe
Author: Jesse Glick 
Date:   2017-06-12T22:29:06Z

Grammar error.

commit 6408b6f2383bcb906fffdc9fe2ef701b461d5c74
Author: Jesse Glick 
Date:   2017-06-12T22:29:45Z

Pick up fix of https://github.com/mojohaus/extra-enforcer-rules/issues/13.

commit fb93d6b2f53734f302c0fc300c823eba212a67e0
Author: Jesse Glick 
Date:   2017-06-12T22:30:01Z

Fix Javadoc error considered fatal by JDK 8.




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [SUREFIRE] JUnit 5 support - current state and next steps

2017-06-12 Thread Benedikt Ritter

Hello Tibor,

thank you for sharing your thoughts and thank you for the review.

> Am 10.06.2017 um 12:48 schrieb Tibor Digana :
> 
> Both branches are messy.
> 3.0-rc1 is pretty old and not working properly because one IT fails.
> I wanted to continue on 3.0 two years ago but could not because the plugin
> was unstable and the 3.0 Extensions was undefined. The way to have
> extensions is clear to me now. Currently now the plugin is able to work
> with Maven 3 so the stability has higher preference. So I wanted release
> 2.20.1 by the end of this week and then 2.20.2 with JDK 9. After this we
> have nothing to fix in stability.
> 
> The JUnit 5 should go to one branch. I do not know why I was so liberal to
> accept pushing JUnit 5 provider to 3.0-rc1 branch. Anyway I do not want to
> push branches junit5 and 3.0-rc1 directly to master now because it is
> technically impossible. Instead I would like to create a patch from
> 3.0-rc1, test it, apply the patch in another branch on the top of master
> HEAD and commit consistent single commit to new branch 3.0-alpha1 and then
> JUnit 5 patch to another branch. These branches will be used for code
> review before pushing directly to master. This is usual process. Meanwhile
> the branches will be in progress there will be no other activity due to
> these are very big and merge conflicts should be avoided.
> 
> So I would propose committing all code related to JUnit 5 to branch junit5
> include changes in AbstractSurefireMojo and add ITs which are necessary.
> At the time when we prepare branch for code review we need to have tests to
> make sure the code is not risky.
> 

Okay, so let me propose this:

I will create a new PR targeted at the junit5 branch, where I will cherry-pick 
to commits with the provider code. Then I create another PR to remove the 
provider code vom 3.0-rc1 branch again. This way we have the junit 5 code in a 
separate branch and can decide where we want to merge it to.

Regards,
Benedikt

> 
> On Sat, Jun 10, 2017 at 11:24 AM, Tibor Digana-2 [via Maven] <
> ml+s40175n5909755...@n5.nabble.com> wrote:
> 
>> Pls give me time to read it.
>> 
>> On Sat, Jun 10, 2017 at 11:06 AM, Benedikt Ritter <[hidden email]
>> >
>> wrote:
>> 
>>> Hey guys,
>>> 
>>> any thoughts on this?
>>> 
>>> Benedikt
>>> 
>>> Benedikt Ritter <[hidden email]
>> > schrieb am Do.
>> 8. Juni 2017 um 15:16:
>>> 
 Hello,
 
 first of all, I’d like to apologize for not being very active over the
 past few months. I’ve been busy at work and there was ApacheCON… so
>> you
 know how it is :-)
 
 I’d like to take some time to review where we’re standing with JUnit 5
 support and what we our next steps will be. Currently the whole thing
>> is
>>> a
 little bit messed up and I’m pretty much to blame for this:
 
 - we have a junit5 branch, where I started to implement some
>> integration
 tests for JUnit 5 support. There are no code changes to Surefire
>> itself
>>> in
 this branch. It just tests that specifying the provider explicitly
>> does
 work as shown in the JUnit docs.
 - then we have 3.0-rc1. We have merged the Provider code from the
>> JUnit
 team into this branch. But we don’t have any tests there.
 - I’ve created a new PR to get work started on a ProviderInfo
 implementation to enable automatic provider lookup [1]. This way users
 don’t need to specify the provider explicitly anymore.
 
 So what should be our next steps?
 
 I think we should merge the junit5 branch into the 3.0-rc1 branch, so
>>> that
 we have the existing integration tests we already implemented in place
>>> for
 getting the work on the ProviderInfo started.
 Then we will need some time to clean up the integration test project.
>> I
 think it need to be restructured a little bit to make it easier to
 understand and make it possible to run tests against several JUnit
>>> versions.
 In the end we should be able to verify that all existing JUnit 4 also
>>> work
 with the JUnit 5 provider.
 
 @Tibor: Can you merge the junit5 branch to 3.0-rc1 branch? Or should I
 create a PR for this?
 
 Best regards,
 Benedikt
 
 [1] https://github.com/apache/maven-surefire/pull/153
 -
 To unsubscribe, e-mail: [hidden email]
>> 
 For additional commands, e-mail: [hidden email]
>> 
 
 
>>> 
>> 
>> 
>> 
>> --
>> Cheers
>> Tibor
>> 
>> 
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://maven.40175.n5.nabble.com/Re-SUREFIRE-JUnit-5-
>> support-current-state-and-next-steps-tp5909754p5909755.html
>> To

[GitHub] maven-surefire pull request #154: Move junit5 provider code

2017-06-12 Thread britter

GitHub user britter opened a pull request:

https://github.com/apache/maven-surefire/pull/154

Move junit5 provider code

Move the junit5/junit-plattform provider code to the junit5 branch. I used 
`git cherry-pick 73e09a8b^..70c8843e` to do this.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/britter/maven-surefire 
move-junit5-provider-code

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/154.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #154


commit 4bf43aab9726f387a35bff40ee0c872110e03d52
Author: Benedikt Ritter 
Date:   2017-02-06T13:02:48Z

SUREFIRE-1330: Import code from 
https://issues.apache.org/jira/browse/SUREFIRE-1330 unchanged as provided

commit 91e6d96593af11bcd7d80183caa6c9ef838fd8bc
Author: Benedikt Ritter 
Date:   2017-02-06T13:20:54Z

Remove LICENSE file, ALv2 will be part of the source distribution

commit 68722a859522efbc9654a7dd6881108c86dafe1d
Author: Benedikt Ritter 
Date:   2017-02-06T13:23:03Z

Convert spaces to tabs

commit 9ac9198760e0b7682534e84220d9210ca4b8a80a
Author: Benedikt Ritter 
Date:   2017-02-06T13:25:01Z

Use Apache Software Foundation License header

commit c4e77a85f498cd4fc3e3fb5a79e1a717201dd02e
Author: Benedikt Ritter 
Date:   2017-02-06T14:20:30Z

Adopt Apache Maven code style

commit e842f9b361845176a6e883d7bf12838f94e89872
Author: Benedikt Ritter 
Date:   2017-02-06T17:55:49Z

Add surefire-junit5 provider as module to the surefire build

commit 61dbc6c79c5fea357bda999d1cbeb647bca5494b
Author: Benedikt Ritter 
Date:   2017-02-06T17:56:20Z

Remove unused filed

commit 78229d505cf515aa90652ab630bea11ae1c6ce69
Author: Benedikt Ritter 
Date:   2017-02-06T18:06:23Z

Remove usage of internal JUnit API

commit 4b8c1a47ab348e16f3f9ec0938d8312cb7546f4c
Author: Benedikt Ritter 
Date:   2017-02-06T18:14:53Z

Move provider classes to maven surefire package

commit acef2c3207da233c03bef600bf7467c92e8ee897
Author: Benedikt Ritter 
Date:   2017-02-06T18:17:36Z

Remove engine declaration - this should be done automatically by surefire

commit 04b482ca6403696e9d118a3f05bd086dc82691ad
Author: Benedikt Ritter 
Date:   2017-02-06T18:54:40Z

Make Checkstyle happy

commit 6a9f36e6a403f376b8088f8e7f4345e2c190b3ec
Author: Benedikt Ritter 
Date:   2017-02-06T18:54:59Z

Configure shade plugin so that is does not explode

commit 841d67f9f0bbb8291d5d20120f6b91f58c634e95
Author: Benedikt Ritter 
Date:   2017-02-10T18:59:23Z

Rename JUnit5 provider to JUnit Platform provider, as suggested by 
@marcphilipp

commit da384e987c73ebbe4767f19427c021bced5f1c0e
Author: Benedikt Ritter 
Date:   2017-02-10T20:00:14Z

Add contributors of the original provider implementation to pom.xml

Thank you for your contributions to open source:
- @lutovich
- @hotchemi
- @sbrannen
- @bechte
- @marcphilipp
- @mmerdes
- @jlink

commit 9580f5ef25c0d4736046165275f2d57d31686ae9
Author: Maxime GrÃ©au 
Date:   2017-04-11T13:32:10Z

SUREFIRE-1330: Fix module name in surefire-providers reactor




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #155: Revert junit-plattform provider code from ...

2017-06-12 Thread britter

GitHub user britter opened a pull request:

https://github.com/apache/maven-surefire/pull/155

Revert junit-plattform provider code from 3.0-rc1 branch.

This code will be moved to the junit5 branch. This commit reverts:

- Commit 70c8843e935882b0a78916894cb9f042964f2717
  "SUREFIRE-1330: Fix module name in surefire-providers reactor"

- Commit c9a1f973e334b402d59f9944c5a58d1db9c8da45
  "Add contributors of the original provider implementation to pom.xml"

- Commit 6e83aa3808bcb4accce54a1b1c0ba91dd01a8812
  "Rename JUnit5 provider to JUnit Platform provider, as suggested by 
@marcphilipp"

- Commit ef6a391006ab1fa672dc26fc234b6411a7dfa888
  "Configure shade plugin so that is does not explode"

- Commit b08b1aeae4ad01582fd6264462a4a9345bfd065d
  "Make Checkstyle happy"

- Commit 97f97167ea0aa07bba4bd864b1f686c2f79ca33d
  "Remove engine declaration - this should be done automatically by 
surefire"

- Commit c197b926a5f02ab2a3842d4a8a736315c3c8eb33
  "Move provider classes to maven surefire package"

- Commit 30ee7b94c3421411aa6257e78f77fe8b88aa125e
  "Remove usage of internal JUnit API"

- Commit 43fb41e8d4115830fbeb6d29f1f17efe8e04de5f
  "Remove unused filed"

- Commit caceca16772c6d11302c2d8627c7f5b7d913878a
  "Add surefire-junit5 provider as module to the surefire build"

- Commit 9283dee30decf62e12edd5eaea08abd811ee811f
  "Adopt Apache Maven code style"

- Commit 62d00dca5709c0a089a65f810c1c66c2897b5003
  "Use Apache Software Foundation License header"

- Commit a0d0325db046f266abc401abe3e0047f6ce908c3
  "Convert spaces to tabs"

- Commit 0c329812e71f149bb7c92bfaa3fa37c6d2ec6eec
  "Remove LICENSE file, ALv2 will be part of the source distribution"

- Commit 73e09a8b2b245e76e072c1809e7fa50be02e95b6
  "SUREFIRE-1330: Import code from 
https://issues.apache.org/jira/browse/SUREFIRE-1330 unchanged as provided"

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/britter/maven-surefire remove-provider-code

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/155.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #155


commit 6636b0693de852a029961bbe676a61c6edfd4293
Author: Benedikt Ritter 
Date:   2017-06-12T06:21:11Z

Revert junit-plattform provider code from 3.0-rc1 branch.
This code will be moved to the junit5 branch. This commit reverts:

- Commit 70c8843e935882b0a78916894cb9f042964f2717
  "SUREFIRE-1330: Fix module name in surefire-providers reactor"

- Commit c9a1f973e334b402d59f9944c5a58d1db9c8da45
  "Add contributors of the original provider implementation to pom.xml"

- Commit 6e83aa3808bcb4accce54a1b1c0ba91dd01a8812
  "Rename JUnit5 provider to JUnit Platform provider, as suggested by 
@marcphilipp"

- Commit ef6a391006ab1fa672dc26fc234b6411a7dfa888
  "Configure shade plugin so that is does not explode"

- Commit b08b1aeae4ad01582fd6264462a4a9345bfd065d
  "Make Checkstyle happy"

- Commit 97f97167ea0aa07bba4bd864b1f686c2f79ca33d
  "Remove engine declaration - this should be done automatically by 
surefire"

- Commit c197b926a5f02ab2a3842d4a8a736315c3c8eb33
  "Move provider classes to maven surefire package"

- Commit 30ee7b94c3421411aa6257e78f77fe8b88aa125e
  "Remove usage of internal JUnit API"

- Commit 43fb41e8d4115830fbeb6d29f1f17efe8e04de5f
  "Remove unused filed"

- Commit caceca16772c6d11302c2d8627c7f5b7d913878a
  "Add surefire-junit5 provider as module to the surefire build"

- Commit 9283dee30decf62e12edd5eaea08abd811ee811f
  "Adopt Apache Maven code style"

- Commit 62d00dca5709c0a089a65f810c1c66c2897b5003
  "Use Apache Software Foundation License header"

- Commit a0d0325db046f266abc401abe3e0047f6ce908c3
  "Convert spaces to tabs"

- Commit 0c329812e71f149bb7c92bfaa3fa37c6d2ec6eec
  "Remove LICENSE file, ALv2 will be part of the source distribution"

- Commit 73e09a8b2b245e76e072c1809e7fa50be02e95b6
  "SUREFIRE-1330: Import code from 
https://issues.apache.org/jira/browse/SUREFIRE-1330 unchanged as provided"




---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional

[GitHub] maven-surefire issue #153: SUREFIRE-1384: ProviderInfo for JUnit Plattform (...

2017-06-12 Thread britter

Github user britter commented on the issue:

https://github.com/apache/maven-surefire/pull/153
  
@Tibor17 thank you for your review. Have you seen my question? I'm having 
problems running the IT. Is this related to the 3.0-rc1 branch?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #153: SUREFIRE-1384: ProviderInfo for JUnit Plat...

2017-06-12 Thread britter

Github user britter commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/153#discussion_r121315282
  
--- Diff: 
surefire-integration-tests/src/test/resources/junit-plattform/src/test/java/junitplattform/BasicTest.java
 ---
@@ -0,0 +1,65 @@
+package junitplattform;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import static org.junit.jupiter.api.Assertions.assertTrue;
+
+import org.junit.jupiter.api.AfterAll;
+import org.junit.jupiter.api.AfterEach;
+import org.junit.jupiter.api.BeforeEach;
+import org.junit.jupiter.api.Test;
+
+public class BasicTest
+{
+
+private boolean setUpCalled = false;
+
+private static boolean tearDownCalled = false;
--- End diff --

This is copied from the junit4-versions test project. Should we fix this 
there as well?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-surefire pull request #153: SUREFIRE-1384: ProviderInfo for JUnit Plat...

2017-06-12 Thread britter

Github user britter commented on a diff in the pull request:

https://github.com/apache/maven-surefire/pull/153#discussion_r121315310
  
--- Diff: 
surefire-integration-tests/src/test/resources/junit-plattform/pom.xml ---
@@ -0,0 +1,58 @@
+
+
+
+http://maven.apache.org/POM/4.0.0;
--- End diff --

This is copied from the junit4-versions test project. Should we fix it 
there as well?


---
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 is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Plexus Archiver handling of symbolic links on Windows

2017-06-12 Thread Plamen Totev

Hello,

There is discussion on Plexus Archiver about symbolic links and
Windows[1]. Currently if a file set is added to an archive and the OS
is Windows the symbolic links are followed. That is, instead of the
symbolic links, the resulting archive contains the files they point
to. For some time Java was not able to work with symbolic links on
Windows, but that is no longer the case. Windows supports symbolic
links since Vista and if you have the required permissions Java works
perfectly fine with the them.

There is proposal to change the default behavior of Plexus Archiver -
to make it consistent across the OSes and to not follow the symbolic
links when a file set is added to an archive. Then regardless of the
OS, the resulting archive will contain the symbolic links and not
copies of the files they point to.

I have two concerns about that.

The first one is the path separator. A symbolic links on Windows will
look something like `src\fileR.txt`. When the archive is extracted on
Linux the symbolic link will be broken. It will point to the
`src\fileR.txt` file (a perfectly valid name for a file on Linux) and
not to the `fileR.txt` file inside the `src` directory. So I think we
should normalize the paths on Windows. The link added should point to
`src/fileR.txt`. I think this will work both on Windows and Linux, but
I'm not 100% sure. Would be great if somebody with more experience on
the matter could confirm that.

My second concern is the effect that this change will have on Maven
plug-ins such as the Assembly plug-in. Imagine a project that creates
a distribution package and one of the directories contains some
symbolic links. With the current implementation if the package is
created on Windows, it will contains duplicated files. In many cases
that could be a desired behavior. By default you have to be admin user
to create symbolic links and many tools on Windows does not support
symbolic links. Including some (if not most) of the popular archivers.
If we change the Plexus Archiver default behavior we may broke
projects like this one. The resulting Windows package will contain
symbolic links but this may result in poor user experience as many
archive programs will no handle it properly. What do you think? Will
such a change in the Plexus Archive break projects or my concern is
undue? Probably the benefits of having consistent behavior on all OSes
are worth taking the risk?

What do you think? Do you have any other concerns related to the
support of symbolic links on Windows.

Regards,
Plamen Totev

p.s. Microsoft is trying to improve the support for symbolic links.
The Windows 10 Creators update will contain some improvements that
will allow non-admin users to create symbolic links and Microsoft is
"working with the owners of open-source community tools such as Git
and npm so they know symlink improvements are coming and can make the
necessary changes to better support symlinks on Windows" [2].


[1] https://github.com/codehaus-plexus/plexus-archiver/issues/47
[2] https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] maven-enforcer pull request #23: Adding RequireUpperBoundDeps.excludes optio...

[GitHub] maven-enforcer pull request #22: Site fixes

Re: [SUREFIRE] JUnit 5 support - current state and next steps

[GitHub] maven-surefire pull request #154: Move junit5 provider code

[GitHub] maven-surefire pull request #155: Revert junit-plattform provider code from ...

[GitHub] maven-surefire issue #153: SUREFIRE-1384: ProviderInfo for JUnit Plattform (...

[GitHub] maven-surefire pull request #153: SUREFIRE-1384: ProviderInfo for JUnit Plat...

[GitHub] maven-surefire pull request #153: SUREFIRE-1384: ProviderInfo for JUnit Plat...

Plexus Archiver handling of symbolic links on Windows

9 matches

Site Navigation

Mail list logo

Footer information