MDEPLOY-214: Added property "retryFailedDeploymentDelay".

[pabloa98]

Hello.

I added a new property in Maven Deploy plugin called
retryFailedDeploymentDelay

This property impose a delay between 1 second to 5 minutes (max) between
retries. The intention is to make maven more solid and stable when network
glitches happens.

This pull request is: https://github.com/apache/maven-plugins/pull/92
jira ticket is: https://issues.apache.org/jira/browse/MDEPLOY-214


This  Pull Request requires this other pull request on macen shared
project:  https://github.com/apache/maven-shared/pull/18 and requerest

Could you please accept the pull request?

Pablo

Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)

[Tibor Digana]

Instead of using  in Surefire (may affect the
ITs), there is a better trick.
See the POM surefire-junit47.
You will see the section of compiler endorsed classpath but Surefire has
different one:




  maven-dependency-plugin
  

  main
  process-sources
  
copy
  
  
${project.build.directory}/endorsed
false
true

  
junit
junit
4.7
jar
  

  


  test
  process-sources
  
copy
  
  

${project.build.directory}/endorsed-test
false
true

  
junit
junit
4.12
jar
  

  

  


  maven-compiler-plugin
  

  ${project.build.directory}/endorsed


  ${project.build.directory}/endorsed-test

  






On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter  wrote:

> Hello Tibor,
>
> Tibor Digana  schrieb am Di., 4. Okt. 2016 um
> 02:29 Uhr:
>
> > Can you simplify and speed up writing integration tests in the way that
> you
> > would parameterize the existing JUnit 4 testing by adding Maven profiles
> > (one default profile and junit5 profile) having another dependencies and
> > @RunWith(Parameterized.class)?
> > This would be cool because we can have identical assertion statements,
> > means behavior, for multiple providers.
> >
>
> I was already thinking about this, because right now I'm duplicating a lot
> of the code from the ITs. This is definitely a good idea. But right know I
> don't have a clear view of how we could implement that. Do we just share
> the test class and work with separate test projects? Or do we want to even
> share the test projects and work with profiles in the test project pom?
>
> JUnit 5 also has support for running legacy tests (they call it "vintage").
> To make a complete IT suite, we would have to run all the JUnit 4 tests
> against the JUnit 5 vintage engine as well.
>
> Lot a work ahead :-)
>
> Regards,
> Benedikt
>
>
> >
> > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter 
> > wrote:
> >
> > > Hi,
> > >
> > > now that we have a separate branch for the JUnit 5 support in the
> > surefire
> > > repo, I'm asking myself how to much things forward. I've added some
> > > additional IT implementations in my GitHub fork, but they all fail
> > because
> > > the 5.0.0-M2 release of junit-surefire-provider does not implement the
> > > desired features.
> > >
> > > At this point I'm pretty much blocked: I can not pick up the latest
> > changes
> > > to the JUnit 5 provider, because the JUnit team has not released it.
> The
> > > JUnit team does not push the development of the provider further, since
> > > they don't have integration tests...
> > > Right now I think it would be best to start implementing a JUnit 5
> > provider
> > > ourself in the junit5 branch, so we can add the missing features and
> have
> > > it ready when JUnit 5 reaches GA.
> > >
> > > Thoughts?
> > >
> > > Benedikt
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>



-- 
Cheers
Tibor

Re: [SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)

[Tibor Digana]

>>Or do we want to even share the test projects and work with profiles in
the test project pom?

I mean this.

It pretty depends on what we are going to test, either:
+ features of surefire-junit5 provider, or
+ features of junit5 itself.

I would say the provider in the first phase, and in the second phase we
should identify junit5 features which do not exist in junit4 but may
influence, e.g. Surefire report.

The main purpose of integration testing is the interoperability between the
main process of Maven and surefire (forked jvm or in-plugin process).

This would lower the development time because you can already reuse
existing tests.
It would be nice to have profiles for vintage and jupiter. If we find out
difference between reports, this can be a subject to a discovered bug.
I think we can keep all IT projects and IT classes where they are and we
can also keep sources using JUnit4 annotations together with JUnit5
annotations. The best was that you split the JUni5 project into
junit-jupiter-api and the core modules.
If we just add junit-jupiter-api to the main  section in
every POM, we do not break old tests because JUnit5 annotations do not
break JUnit4 runners. If we want to run JUnit5 tests, then the profiles
come into the role (one having junit-jupiter-engine
 and
another profile with junit-vintage-engine
,
and finally profiles for old junit4 or 47). Unfortunately JUnit4 does not
have separate module with annotations only. Therefore we may use
 to exclude it if really necessary, see
http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html
Do you think this would work?

Cheers
Tibor


On Tue, Oct 4, 2016 at 7:48 PM, Benedikt Ritter [via Maven] <
ml-node+s40175n5882181...@n5.nabble.com> wrote:

> Hello Tibor,
>
> Tibor Digana <[hidden email]
> > schrieb am Di.,
> 4. Okt. 2016 um
> 02:29 Uhr:
>
> > Can you simplify and speed up writing integration tests in the way that
> you
> > would parameterize the existing JUnit 4 testing by adding Maven profiles
> > (one default profile and junit5 profile) having another dependencies and
> > @RunWith(Parameterized.class)?
> > This would be cool because we can have identical assertion statements,
> > means behavior, for multiple providers.
> >
>
> I was already thinking about this, because right now I'm duplicating a lot
> of the code from the ITs. This is definitely a good idea. But right know I
> don't have a clear view of how we could implement that. Do we just share
> the test class and work with separate test projects? Or do we want to even
> share the test projects and work with profiles in the test project pom?
>
> JUnit 5 also has support for running legacy tests (they call it
> "vintage").
> To make a complete IT suite, we would have to run all the JUnit 4 tests
> against the JUnit 5 vintage engine as well.
>
> Lot a work ahead :-)
>
> Regards,
> Benedikt
>
>
> >
> > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter <[hidden email]
> >
> > wrote:
> >
> > > Hi,
> > >
> > > now that we have a separate branch for the JUnit 5 support in the
> > surefire
> > > repo, I'm asking myself how to much things forward. I've added some
> > > additional IT implementations in my GitHub fork, but they all fail
> > because
> > > the 5.0.0-M2 release of junit-surefire-provider does not implement the
> > > desired features.
> > >
> > > At this point I'm pretty much blocked: I can not pick up the latest
> > changes
> > > to the JUnit 5 provider, because the JUnit team has not released it.
> The
> > > JUnit team does not push the development of the provider further,
> since
> > > they don't have integration tests...
> > > Right now I think it would be best to start implementing a JUnit 5
> > provider
> > > ourself in the junit5 branch, so we can add the missing features and
> have
> > > it ready when JUnit 5 reaches GA.
> > >
> > > Thoughts?
> > >
> > > Benedikt
> > >
> >
> >
> >
> > --
> > Cheers
> > Tibor
> >
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/SUREFIRE-JUnit-5-support-
> how-to-move-things-forward-tp5882104p5882181.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166...@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> 
> .
> NAML
> 

Review Request: Apache Maven Recipe for module-info and older projects

[Robert Scholte]

Hi,

I've written a page[1] about the problem related to projects which need to  
be compatible with pre Java9 versions, but also want to provide a  
module-info file in case it is used in a Java 9 project. This is mainly an  
issue for library builders, end-application builders can simply push  
everything to Java 9.


Let me also explain why I didn't go for any other options:
- 1 execution-block to rule them all (maven-compiler-plugin magic): this  
would mean you need to introduce several parameters for the compilation of  
the module-info file. And we must assume they cannot always use the same  
JDK. To keep enough strength for the end-user you must provide duplicates  
of source/target/release, jdkToolchain, includes, excludes and maybe more.
  The next issue is about result handling: the result of both javac calls  
need to be merged, in all combinations of success and failure. In case of  
failure you must provide the exact information. Whoever tries to implement  
this just like I did must admit it results in ugly and hard controllable  
code.
-  2 separate source folders could be a pattern, but probably not a  
developer-friendly option. This also depends on what IDEs are going to do.
- Multimodule JAR: feels quite expensive to have a Maven MultiModule for  
only one file. Also in this case we might need to wait and see what kind  
of solutions IDEs have.
- auto-ignore module-info in case source/target/release < 9: I've decided  
not to do this. Uninformed developers might think that the module-info is  
automatically compiled. However, in the end the jar won't have the  
module-info file. Better break the build and point them to the module-info  
page[1]


I've written an integration test[2] matching this concept.

As said: this is mainly an issue for library builders. I expect that they  
don't have a real issue with this small amount of extra configuration in  
their pom. And this way they are still in full control.


Any comment is appreciated,
Robert

ps. .apt-files will be transformed to html with the maven-site-plugin as  
part of every release.


[1]  
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-compiler-plugin/src/site/apt/examples/module-info.apt.vm
[2]  
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/


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

[SUREFIRE] Parameterized Tests for Junit 4 and Junit 5? (Was: [SUREFIRE] JUnit 5 support - how to move things forward?)

[Benedikt Ritter]

Hello Tibor,

Tibor Digana  schrieb am Di., 4. Okt. 2016 um
02:29 Uhr:

> Can you simplify and speed up writing integration tests in the way that you
> would parameterize the existing JUnit 4 testing by adding Maven profiles
> (one default profile and junit5 profile) having another dependencies and
> @RunWith(Parameterized.class)?
> This would be cool because we can have identical assertion statements,
> means behavior, for multiple providers.
>

I was already thinking about this, because right now I'm duplicating a lot
of the code from the ITs. This is definitely a good idea. But right know I
don't have a clear view of how we could implement that. Do we just share
the test class and work with separate test projects? Or do we want to even
share the test projects and work with profiles in the test project pom?

JUnit 5 also has support for running legacy tests (they call it "vintage").
To make a complete IT suite, we would have to run all the JUnit 4 tests
against the JUnit 5 vintage engine as well.

Lot a work ahead :-)

Regards,
Benedikt


>
> On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter 
> wrote:
>
> > Hi,
> >
> > now that we have a separate branch for the JUnit 5 support in the
> surefire
> > repo, I'm asking myself how to much things forward. I've added some
> > additional IT implementations in my GitHub fork, but they all fail
> because
> > the 5.0.0-M2 release of junit-surefire-provider does not implement the
> > desired features.
> >
> > At this point I'm pretty much blocked: I can not pick up the latest
> changes
> > to the JUnit 5 provider, because the JUnit team has not released it. The
> > JUnit team does not push the development of the provider further, since
> > they don't have integration tests...
> > Right now I think it would be best to start implementing a JUnit 5
> provider
> > ourself in the junit5 branch, so we can add the missing features and have
> > it ready when JUnit 5 reaches GA.
> >
> > Thoughts?
> >
> > Benedikt
> >
>
>
>
> --
> Cheers
> Tibor
>

Re: [SUREFIRE] JUnit 5 support - how to move things forward?

[Benedikt Ritter]

Hello Tibor,

Tibor Digana  schrieb am Di., 4. Okt. 2016 um
02:14 Uhr:

> +1 to adopt JUnit 5 provider to Maven Surefire git branch.
> You would have to extend AbstractSurefireMojo.java with JUnit 5 provider in
> classpath builder.
>

I see, we would have to implement a ProviderInfo for JUnit 5. I think I can
work on thins.


> Do we have to keep using other license?
>

JUnit is EPL. I talked to Marc and they asked all contributors to
explicitly state that they are donating the code under the terms of EPL.
I'm not sure how we would handle it. If they explicitly contribute the
code, it should be no problem. Or do we have to talk to legal?


> Can we ask the JUnit team to continuously migrate stable changes to
> Surefire?
>

I think there should be only one home for the provider. Either it is
maven-surefire or it's junit but not both. So if we decide to take over the
provider they will probably stop maintaining their own implementation
because it is not their scope. I've volunteered to help maintaining the
code since I'd like to get involved in the maven project and in junit. If
that's not enough, we have to find a different solution.

Regards,
Benedikt


>
>
> On Mon, Oct 3, 2016 at 7:39 PM, Benedikt Ritter [via Maven] <
> ml-node+s40175n5882104...@n5.nabble.com> wrote:
>
> > Hi,
> >
> > now that we have a separate branch for the JUnit 5 support in the
> surefire
> > repo, I'm asking myself how to much things forward. I've added some
> > additional IT implementations in my GitHub fork, but they all fail
> because
> > the 5.0.0-M2 release of junit-surefire-provider does not implement the
> > desired features.
> >
> > At this point I'm pretty much blocked: I can not pick up the latest
> > changes
> > to the JUnit 5 provider, because the JUnit team has not released it. The
> > JUnit team does not push the development of the provider further, since
> > they don't have integration tests...
> > Right now I think it would be best to start implementing a JUnit 5
> > provider
> > ourself in the junit5 branch, so we can add the missing features and have
> > it ready when JUnit 5 reaches GA.
> >
> > Thoughts?
> >
> > Benedikt
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/SUREFIRE-JUnit-5-support-
> > how-to-move-things-forward-tp5882104.html
> > To start a new topic under Maven Developers, email
> > ml-node+s40175n142166...@n5.nabble.com
> > To unsubscribe from Maven Developers, click here
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=142166=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==
> >
> > .
> > NAML
> > <
> http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer=instant_html%21nabble%3Aemail.naml=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Re-SUREFIRE-JUnit-5-support-how-to-move-things-forward-tp5882138.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

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

[britter]

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

https://github.com/apache/maven-surefire/pull/125#discussion_r81810117
  
--- Diff: 
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/JUnit47ConcurrencyIT.java
 ---
@@ -32,14 +32,14 @@
  *
  * @author Kristian Rosenvold
  */
-public class Junit47concurrencyIT
--- End diff --

Because consistency is a good thing :-) There are some tests named 
"JunitXXX" and some "JUnitXXX". It's better to have only one naming convention.

Yes I've searched the whole project for occurrences of "concurrentjunit47".


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