[GitHub] maven-scm pull request #52: add --chache option for git rm

[soiff]

GitHub user soiff opened a pull request:

https://github.com/apache/maven-scm/pull/52

add --chache option for git rm

For newer git release, command `git rm` will remove files definitely and 
it's not possible to add it again by command `git add`. In this scenario, 
option `--cache` should be added to command `git rm` to prevent from deleting.

The only change I want to merge to `apache/maven-scm` is the option not the 
`pom.xml`. Thanks a lot.

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

$ git pull https://github.com/soiff/maven-scm 1.9.5

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

https://github.com/apache/maven-scm/pull/52.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 #52


commit 6c903f4bda7ad9370384602620c905707e38243a
Author: Gemini Keith 
Date:   2016-09-11T02:07:58Z

add --chache option for git rm




---
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: shared: maven-artifact-transfer

[Robert Scholte]

On Sat, 10 Sep 2016 17:15:49 +0200, Karl Heinz Marbaise  
 wrote:



Hi Robert,

On 10/09/16 16:54, Robert Scholte wrote:

Hi Karl Heinz,

when looking at Aether it is not aware of a MavenProject. Instead it is
transferring Files.


Yes I know..


My idea was to have a thin layer on top op (Sonatype/Eclipse) Aether and
to avoid too much Maven Core mixin.


Yes I have understood that...



But it did cross my mind to use the MavenProject as the entity instead
of File.


A file is a good idea to be flexible..but a MavenProject would also make  
sense, cause it will make plugin usage more simpler..(extension usage as  
well ;-) ).



Apart from that the component contains already ProjectCoordinate (which  
isnt't anywhere)...





Yes, I thought I needed this, but a ProjectCoordinate only makes sense in  
a multimodule project. They are referred as Dependencies, so it is again a  
DependencyCoordinate. In those cases it is better to use the MavenProject  
instead. I don't think there's still a good usecase for ProjectCoordinate.


Robert



It will come with some other interesting possibilities:
updating meta after all files are uploaded, otherwise you'll need to
write this inside the plugin(s).


That's what came up to me by looking into maven-install-plugin...


It will introduce an extra layer and we must be aware that Aether's
DeployRequest cannot be translated back and forward to the
artifact-transfer DeployRequest.
It is a design question and I think it is worth adding it.


The DeployRequest I have only taken cause it is done via this in  
maven-deploy-plugin...I would say it is not really neccessary...


So first I would suggest to add DeployProject (better name?) to the  
package:


org.apache.maven.shared.project.deploy

as well as DeployRequest (it does not contain any Aether specific  
things; no imports here)(May be it can be removed)...


and something like InstallProject and InstallRequest (need to think  
about it) to:


org.apache.maven.shared.project.install

If you have no objections

I will give it a try and see how it works...

Kind regards
Karl Heinz



Robert

On Sat, 10 Sep 2016 15:27:35 +0200, Karl Heinz Marbaise
 wrote:


Hi,

so after using the maven-artifact-transfer a time I have realized
there seemed to be some lack of funcionality from my point of view...

My extension[1] will deploy all projects at the end of the session and
I had to write down a lot of code to deploy a project...the same
meaning for install a project...(Not yet done but I will deployAtEnd /
installAtEnd problem).

So I wrote a class[2] which contains this code (most of this is of
course taken from maven-deploy-plugin):

and now you simply deploy the whole projects of a maven project with a
few lines of code(The following is special for the extension):

ArtifactRepository repository =
executionEvent.getSession().getTopLevelProject().getDistributionManagementArtifactRepository();


List sortedProjects =
executionEvent.getSession().getProjectDependencyGraph().getSortedProjects();

for ( MavenProject mavenProject : sortedProjects )
{
   DeployRequest deployRequest = new DeployRequest().setProject(
mavenProject ).setUpdateReleaseInfo( true );

deployProject.deployProject(
executionEvent.getSession().getProjectBuildingRequest(), deployRequest,
  repository );
}

So in the end if you like to do that from a usual maven plugin this
reduces to having a MavenSession and of course a project you would
like to deploy...

About the DeployRequest I'm not sure if it belongs to
maven-artifact-transfer but I have strong trend to...


So the question is:
   Does it make sense to integrate those classes into
maven-artifact-transfer ?

This would simplify the implementation in maven-deploy-plugin and
other plugins as well (maven-install-plugin, maven-invoker-plugin,
maven-assembly-plugin, maven-shade-plugin etc.)..

I think similar code can be extracted to handle installing of a
project (as in maven-install-plugin already done)...


WDYT ?

Kind regards
Karl Heinz Marbaise


[1]: https://github.com/khmarbaise/maven-deployer-extension
[2]:
https://github.com/khmarbaise/maven-deployer-extension/blob/master/src/main/java/com/soebes/maven/extensions/deployer/DeployProject.java


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


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





Mit freundlichem Gruß
Karl-Heinz Marbaise


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

Re: shared: maven-artifact-transfer

[Karl Heinz Marbaise]

Hi Robert,

On 10/09/16 16:54, Robert Scholte wrote:

Hi Karl Heinz,

when looking at Aether it is not aware of a MavenProject. Instead it is
transferring Files.


Yes I know..


My idea was to have a thin layer on top op (Sonatype/Eclipse) Aether and
to avoid too much Maven Core mixin.


Yes I have understood that...



But it did cross my mind to use the MavenProject as the entity instead
of File.


A file is a good idea to be flexible..but a MavenProject would also make 
sense, cause it will make plugin usage more simpler..(extension usage as 
well ;-) ).



Apart from that the component contains already ProjectCoordinate (which 
isnt't anywhere)...




It will come with some other interesting possibilities:
updating meta after all files are uploaded, otherwise you'll need to
write this inside the plugin(s).


That's what came up to me by looking into maven-install-plugin...


It will introduce an extra layer and we must be aware that Aether's
DeployRequest cannot be translated back and forward to the
artifact-transfer DeployRequest.
It is a design question and I think it is worth adding it.


The DeployRequest I have only taken cause it is done via this in 
maven-deploy-plugin...I would say it is not really neccessary...


So first I would suggest to add DeployProject (better name?) to the package:

org.apache.maven.shared.project.deploy

as well as DeployRequest (it does not contain any Aether specific 
things; no imports here)(May be it can be removed)...


and something like InstallProject and InstallRequest (need to think 
about it) to:


org.apache.maven.shared.project.install

If you have no objections

I will give it a try and see how it works...

Kind regards
Karl Heinz



Robert

On Sat, 10 Sep 2016 15:27:35 +0200, Karl Heinz Marbaise
 wrote:


Hi,

so after using the maven-artifact-transfer a time I have realized
there seemed to be some lack of funcionality from my point of view...

My extension[1] will deploy all projects at the end of the session and
I had to write down a lot of code to deploy a project...the same
meaning for install a project...(Not yet done but I will deployAtEnd /
installAtEnd problem).

So I wrote a class[2] which contains this code (most of this is of
course taken from maven-deploy-plugin):

and now you simply deploy the whole projects of a maven project with a
few lines of code(The following is special for the extension):

ArtifactRepository repository =
executionEvent.getSession().getTopLevelProject().getDistributionManagementArtifactRepository();


List sortedProjects =
executionEvent.getSession().getProjectDependencyGraph().getSortedProjects();

for ( MavenProject mavenProject : sortedProjects )
{
   DeployRequest deployRequest = new DeployRequest().setProject(
mavenProject ).setUpdateReleaseInfo( true );

deployProject.deployProject(
executionEvent.getSession().getProjectBuildingRequest(), deployRequest,
  repository );
}

So in the end if you like to do that from a usual maven plugin this
reduces to having a MavenSession and of course a project you would
like to deploy...

About the DeployRequest I'm not sure if it belongs to
maven-artifact-transfer but I have strong trend to...


So the question is:
   Does it make sense to integrate those classes into
maven-artifact-transfer ?

This would simplify the implementation in maven-deploy-plugin and
other plugins as well (maven-install-plugin, maven-invoker-plugin,
maven-assembly-plugin, maven-shade-plugin etc.)..

I think similar code can be extracted to handle installing of a
project (as in maven-install-plugin already done)...


WDYT ?

Kind regards
Karl Heinz Marbaise


[1]: https://github.com/khmarbaise/maven-deployer-extension
[2]:
https://github.com/khmarbaise/maven-deployer-extension/blob/master/src/main/java/com/soebes/maven/extensions/deployer/DeployProject.java


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


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





Mit freundlichem Gruß
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseUSt.IdNr: DE191347579
Hauptstrasse 177
52146 Würselen   http://www.soebes.de

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

Re: shared: maven-artifact-transfer

[Robert Scholte]

Hi Karl Heinz,

when looking at Aether it is not aware of a MavenProject. Instead it is  
transferring Files.
My idea was to have a thin layer on top op (Sonatype/Eclipse) Aether and  
to avoid too much Maven Core mixin.
But it did cross my mind to use the MavenProject as the entity instead of  
File. It will come with some other interesting possibilities: updating  
meta after all files are uploaded, otherwise you'll need to write this  
inside the plugin(s).
It will introduce an extra layer and we must be aware that Aether's  
DeployRequest cannot be translated back and forward to the  
artifact-transfer DeployRequest.

It is a design question and I think it is worth adding it.

Robert

On Sat, 10 Sep 2016 15:27:35 +0200, Karl Heinz Marbaise  
 wrote:



Hi,

so after using the maven-artifact-transfer a time I have realized there  
seemed to be some lack of funcionality from my point of view...


My extension[1] will deploy all projects at the end of the session and I  
had to write down a lot of code to deploy a project...the same meaning  
for install a project...(Not yet done but I will deployAtEnd /  
installAtEnd problem).


So I wrote a class[2] which contains this code (most of this is of  
course taken from maven-deploy-plugin):


and now you simply deploy the whole projects of a maven project with a  
few lines of code(The following is special for the extension):


ArtifactRepository repository =  
executionEvent.getSession().getTopLevelProject().getDistributionManagementArtifactRepository();


List sortedProjects =  
executionEvent.getSession().getProjectDependencyGraph().getSortedProjects();

for ( MavenProject mavenProject : sortedProjects )
{
   DeployRequest deployRequest = new DeployRequest().setProject(  
mavenProject ).setUpdateReleaseInfo( true );


deployProject.deployProject(  
executionEvent.getSession().getProjectBuildingRequest(), deployRequest,

  repository );
}

So in the end if you like to do that from a usual maven plugin this  
reduces to having a MavenSession and of course a project you would like  
to deploy...


About the DeployRequest I'm not sure if it belongs to  
maven-artifact-transfer but I have strong trend to...



So the question is:
   Does it make sense to integrate those classes into
maven-artifact-transfer ?

This would simplify the implementation in maven-deploy-plugin and other  
plugins as well (maven-install-plugin, maven-invoker-plugin,  
maven-assembly-plugin, maven-shade-plugin etc.)..


I think similar code can be extracted to handle installing of a project  
(as in maven-install-plugin already done)...



WDYT ?

Kind regards
Karl Heinz Marbaise


[1]: https://github.com/khmarbaise/maven-deployer-extension
[2]:  
https://github.com/khmarbaise/maven-deployer-extension/blob/master/src/main/java/com/soebes/maven/extensions/deployer/DeployProject.java


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


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

shared: maven-artifact-transfer

[Karl Heinz Marbaise]

Hi,

so after using the maven-artifact-transfer a time I have realized there 
seemed to be some lack of funcionality from my point of view...


My extension[1] will deploy all projects at the end of the session and I 
had to write down a lot of code to deploy a project...the same meaning 
for install a project...(Not yet done but I will deployAtEnd / 
installAtEnd problem).


So I wrote a class[2] which contains this code (most of this is of 
course taken from maven-deploy-plugin):


and now you simply deploy the whole projects of a maven project with a 
few lines of code(The following is special for the extension):


ArtifactRepository repository = 
executionEvent.getSession().getTopLevelProject().getDistributionManagementArtifactRepository();


List sortedProjects = 
executionEvent.getSession().getProjectDependencyGraph().getSortedProjects();

for ( MavenProject mavenProject : sortedProjects )
{
  DeployRequest deployRequest = new DeployRequest().setProject( 
mavenProject ).setUpdateReleaseInfo( true );


   deployProject.deployProject( 
executionEvent.getSession().getProjectBuildingRequest(), deployRequest,

 repository );
}

So in the end if you like to do that from a usual maven plugin this 
reduces to having a MavenSession and of course a project you would like 
to deploy...


About the DeployRequest I'm not sure if it belongs to 
maven-artifact-transfer but I have strong trend to...



So the question is:
  Does it make sense to integrate those classes into
maven-artifact-transfer ?

This would simplify the implementation in maven-deploy-plugin and other 
plugins as well (maven-install-plugin, maven-invoker-plugin, 
maven-assembly-plugin, maven-shade-plugin etc.)..


I think similar code can be extracted to handle installing of a project 
(as in maven-install-plugin already done)...



WDYT ?

Kind regards
Karl Heinz Marbaise


[1]: https://github.com/khmarbaise/maven-deployer-extension
[2]: 
https://github.com/khmarbaise/maven-deployer-extension/blob/master/src/main/java/com/soebes/maven/extensions/deployer/DeployProject.java


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

[GitHub] maven-surefire pull request #120: Add convinient method to check for the cur...

[britter]

GitHub user britter opened a pull request:

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

Add convinient method to check for the currently used Java Version



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

$ git pull https://github.com/britter/maven-surefire assume-java-version

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

https://github.com/apache/maven-surefire/pull/120.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 #120


commit ff951f9dd2836101ce0df86b79da76bc51c2996b
Author: Benedikt Ritter 
Date:   2016-09-10T13:13:24Z

Add convinient method to check for the currently used Java Version




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

[SUREFIRE] Branch for JUnit 5 integration?

[Benedikt Ritter]

Hi,

I'm currently a bit stuck with the JUnit 5 integration, because I don't
really know where it should be going. At first I thought we should just
merge the Integration tests I'm about to write directly to master. But
maybe that's not the best idea. But I don't want to implement the whole
thing in my fork as well since this will lead to a unmanagable huge change
set when it will be reintegrated. So my proposal is to create a separate
branch in the maven-surefire repo I can open PRs against. This way I can
iteratively add more stuff in small chucks but is does not land directly on
master.

WDYT?

Regards,
Benedikt

Re: Code Style for IntelliJ 2016.2

[Benedikt Ritter]

Hello Tibor,

that file does not seem to work with IntelliJ 2016.2 :-( I think I will
have to configure the code style myself.

Benedikt

Tibor Digana  schrieb am Fr., 9. Sep. 2016 um
15:00 Uhr:

> Sorry I did not get notice this email. You need to configure your IDE for
> you pending PR in GitHub, right? :)
> I use IntelliJ IDEA 14.1.7. The code style for IDEA:
> https://maven.apache.org/developers/maven-idea-codestyle.xml
> https://maven.apache.org/developers/conventions/code.html
>
> On Wed, Sep 7, 2016 at 9:04 PM, Benedikt Ritter [via Maven] <
> ml-node+s40175n5880158...@n5.nabble.com> wrote:
>
> > Hi maven devs,
> >
> > which code style file do you use for IntelliJ 2016.2? I've imported the
> > file from http://maven.apache.org/developers/committer-environment.html
> but
> >
> > is does not work properly (for example is does not place curly braces on
> > new lines)
> >
> > Thank you!
> > Benedikt
> >
> >
> > --
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://maven.40175.n5.nabble.com/Code-Style-for-IntelliJ-
> > 2016-2-tp5880158.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/Code-Style-for-IntelliJ-2016-2-tp5880158p5880283.html
> Sent from the Maven Developers mailing list archive at Nabble.com.

[GitHub] maven-surefire pull request #119: Make JUnit4VersionsIT acutally use the ver...

[britter]

GitHub user britter opened a pull request:

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

Make JUnit4VersionsIT acutally use the versions set by the test code

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 
junit4versionit-use-versions

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

https://github.com/apache/maven-surefire/pull/119.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 #119


commit 2c9edf062aa5188a9437972f4eac09c1f20172d3
Author: Benedikt Ritter 
Date:   2016-09-10T12:30:09Z

Make JUnit4VersionsIT acutally use the versions set by the test code




---
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: colored console

[Romain Manni-Bucau]

Le 10 sept. 2016 12:57, "Hervé BOUTEMY"  a écrit :
>
> Le vendredi 9 septembre 2016 10:49:54 Tibor Digana a écrit :
> > @Herve What do you think about Romain's concept: --color-info=blue
> > --color-error=red --color-warning=yellow-bold
> > @Romain In MVN 3.4 you can override the colors via system properties,
e.g.
> > -Dstyle.info=bold,blue
> see
http://maven.apache.org/shared/maven-shared-utils/apidocs/org/apache/maven/shared/utils/logging/package-summary.html
>
>
> > @Romain, if we had "--color-surefire-test=blue" in CLI then all plugins
> > would require to have the same principle.
> > What if some users want to cover only some part of the text with colors
and
> > combine with multiple colors?
> making styles rendering configurable per plugin seems really too much,
IMHO
>

If you compare maven to dome other build tools you have more data you can
desire to control *as a user*: level, message, subpart of a message etc.
Control per line or data etc...

This induce the need of more config by nature otherwise colors are a less
useful feature than it should be cause instead of helping the user making
outputs more readable you decrease the readability. That is my feedback
with current colors and why i forked the binder ATM.

> Regards,
>
> Hervé
>
> >
> > On Fri, Sep 9, 2016 at 10:06 AM, Romain Manni-Bucau <
rmannibu...@gmail.com>
> >
> > wrote:
> > > 2016-09-09 7:45 GMT+02:00 Tibor Digana :
> > > > Romain, did you mean ${maven.projectBasedir}/.mvn/maven.config [1] ?
> > > > Some extension or maven.config.
> > > > [1] https://maven.apache.org/docs/3.3.1/release-notes.html
> > >
> > > Could be if all options are mapped to the command line but was more
> > > thinking to a color oriented config (globally and overridable by
plugin)
> > >
> > > In maven config it would be something like:
> > > --color-info=blue --color-error=red --color-warning=yellow-bold
> > >
> > > etc --color-surefire-test=blue
> > >
> > > Not a "syntax" I'm in love but in the home and working so would be ok
too
> > >
> > > > On Fri, Sep 9, 2016 at 12:20 AM, Romain Manni-Bucau <
> > >
> > > rmannibu...@gmail.com
> > >
> > > > wrote:
> > > > > Color is a user thing not a build thing so belongs to .m2 not
> > > > >  I think.
> > > > >
> > > > > Le 9 sept. 2016 00:18, "Gary Gregory"  a
> > >
> > > écrit :
> > > > > > On Thu, Sep 8, 2016 at 2:48 PM, Romain Manni-Bucau <
> > > > >
> > > > > rmannibu...@gmail.com>
> > > > >
> > > > > > wrote:
> > > > > > > +1 to remove the bold
> > > > > >
> > > > > > I agree fwiw.
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > > What about having the coloration configurable in settings.xml:
> > > > current
> > > >
> > > > > or
> > > > >
> > > > > > > no color for test result line or single color for level and
result
> > >
> > > or
> > >
> > > > > > only
> > > > > >
> > > > > > > start of the line?
> > > > > > >
> > > > > > > Le 8 sept. 2016 23:36, "Tibor Digana" 
a
> > > > >
> > > > > écrit :
> > > > > > > > sending the picture in attachment..
> > > > > > > >
> > > > > > > > On Thu, Sep 8, 2016 at 11:32 PM, Romain Manni-Bucau [via
Maven]
> > > > > > > > <
> > > > > > > >
> > > > > > > > ml-node+s40175n5880220...@n5.nabble.com> wrote:
> > > > > > > > > Hello Tibor,
> > > > > > > > >
> > > > > > > > > not sure that's me but I don't see the picture
> > > > > > > > >
> > > > > > > > > that said I like this kind of coloring for maven:
> > > > > > > > > https://raw.githubusercontent.com/rmannibucau/maven-color/
> > > > > > > > > master/screenshot.png
> > > > > > > > > . Makes it easy to identify steps and warn/error (in red)
> > > >
> > > > visually
> > > >
> > > > > > > > > Romain Manni-Bucau
> > > > > > > > > @rmannibucau  |  Blog
> > > > > > > > >  | Old Wordpress
Blog
> > > > > > > > >  | Github <
> > >
> > > https://github.com/
> > >
> > > > > > > > > rmannibucau> |
> > > > > > > > > LinkedIn  |
> > >
> > > Tomitriber
> > >
> > > > > > > > >  | JavaEE Factory
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > > 2016-09-08 23:27 GMT+02:00 Tibor Digana <[hidden email]
> > > > > > > > >
> > > > > > > > > >:
> > > > > > > > > > Currently the colored console looks like in the picture.
> > > > > > > > > > Please let me know what other highlighting you prefer.
> > > > > > > > > >
> > > > > > > > > > I do not prefer using bold text in color, and use colors
> > > > > > > > > > only
> > > >
> > > > in
> > > >
> > > > > > the
> > > > > >
> > > > > > > > > begin
> > > > > > > > >
> > > > > > > > > > of line:
> > > > > > > > > > "Tests run: 12, Failure: 0, Errors: 0, Skipped: 0"
> > > > > > > > > >
> > > > > > > > > > WDYT?
> > > > > > > > > >
> > > > > 

Re: colored console

[Hervé BOUTEMY]

Le vendredi 9 septembre 2016 10:49:54 Tibor Digana a écrit :
> @Herve What do you think about Romain's concept: --color-info=blue
> --color-error=red --color-warning=yellow-bold
> @Romain In MVN 3.4 you can override the colors via system properties, e.g.
> -Dstyle.info=bold,blue
see 
http://maven.apache.org/shared/maven-shared-utils/apidocs/org/apache/maven/shared/utils/logging/package-summary.html


> @Romain, if we had "--color-surefire-test=blue" in CLI then all plugins
> would require to have the same principle.
> What if some users want to cover only some part of the text with colors and
> combine with multiple colors?
making styles rendering configurable per plugin seems really too much, IMHO

Regards,

Hervé

> 
> On Fri, Sep 9, 2016 at 10:06 AM, Romain Manni-Bucau 
> 
> wrote:
> > 2016-09-09 7:45 GMT+02:00 Tibor Digana :
> > > Romain, did you mean ${maven.projectBasedir}/.mvn/maven.config [1] ?
> > > Some extension or maven.config.
> > > [1] https://maven.apache.org/docs/3.3.1/release-notes.html
> > 
> > Could be if all options are mapped to the command line but was more
> > thinking to a color oriented config (globally and overridable by plugin)
> > 
> > In maven config it would be something like:
> > --color-info=blue --color-error=red --color-warning=yellow-bold
> > 
> > etc --color-surefire-test=blue
> > 
> > Not a "syntax" I'm in love but in the home and working so would be ok too
> > 
> > > On Fri, Sep 9, 2016 at 12:20 AM, Romain Manni-Bucau <
> > 
> > rmannibu...@gmail.com
> > 
> > > wrote:
> > > > Color is a user thing not a build thing so belongs to .m2 not
> > > >  I think.
> > > > 
> > > > Le 9 sept. 2016 00:18, "Gary Gregory"  a
> > 
> > écrit :
> > > > > On Thu, Sep 8, 2016 at 2:48 PM, Romain Manni-Bucau <
> > > > 
> > > > rmannibu...@gmail.com>
> > > > 
> > > > > wrote:
> > > > > > +1 to remove the bold
> > > > > 
> > > > > I agree fwiw.
> > > > > 
> > > > > Gary
> > > > > 
> > > > > > What about having the coloration configurable in settings.xml:
> > > current
> > > 
> > > > or
> > > > 
> > > > > > no color for test result line or single color for level and result
> > 
> > or
> > 
> > > > > only
> > > > > 
> > > > > > start of the line?
> > > > > > 
> > > > > > Le 8 sept. 2016 23:36, "Tibor Digana"  a
> > > > 
> > > > écrit :
> > > > > > > sending the picture in attachment..
> > > > > > > 
> > > > > > > On Thu, Sep 8, 2016 at 11:32 PM, Romain Manni-Bucau [via Maven]
> > > > > > > <
> > > > > > > 
> > > > > > > ml-node+s40175n5880220...@n5.nabble.com> wrote:
> > > > > > > > Hello Tibor,
> > > > > > > > 
> > > > > > > > not sure that's me but I don't see the picture
> > > > > > > > 
> > > > > > > > that said I like this kind of coloring for maven:
> > > > > > > > https://raw.githubusercontent.com/rmannibucau/maven-color/
> > > > > > > > master/screenshot.png
> > > > > > > > . Makes it easy to identify steps and warn/error (in red)
> > > 
> > > visually
> > > 
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau  |  Blog
> > > > > > > >  | Old Wordpress Blog
> > > > > > > >  | Github <
> > 
> > https://github.com/
> > 
> > > > > > > > rmannibucau> |
> > > > > > > > LinkedIn  |
> > 
> > Tomitriber
> > 
> > > > > > > >  | JavaEE Factory
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 2016-09-08 23:27 GMT+02:00 Tibor Digana <[hidden email]
> > > > > > > > 
> > > > > > > > >:
> > > > > > > > > Currently the colored console looks like in the picture.
> > > > > > > > > Please let me know what other highlighting you prefer.
> > > > > > > > > 
> > > > > > > > > I do not prefer using bold text in color, and use colors
> > > > > > > > > only
> > > 
> > > in
> > > 
> > > > > the
> > > > > 
> > > > > > > > begin
> > > > > > > > 
> > > > > > > > > of line:
> > > > > > > > > "Tests run: 12, Failure: 0, Errors: 0, Skipped: 0"
> > > > > > > > > 
> > > > > > > > > WDYT?
> > > > > > > > > 
> > > > > > > > > I will not change the text.
> > > > > > > > > 
> > > > > > > > > [image: Inline image 1]
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Cheers
> > > > > > > > > Tibor
> > > > > > > > 
> > > > > > > > --
> > > > > > > > If you reply to this email, your message will be added to the
> > > > > > 
> > > > > > discussion
> > > > > > 
> > > > > > > > below:
> > > > > > > > http://maven.40175.n5.nabble.com/colored-console-> > > > > > 
> > > > > > tp5880214p5880220.html
> > > > > > 
> > > > > > > > To start a new topic under Maven Developers, email
> > > > > > > > ml-node+s40175n142166...@n5.nabble.com
> > > > > > > > To unsubscribe from Maven Developers, click here
> > > > > > > > 

Re: Method level parallelization not completing consistently

[Karl Heinz Marbaise]

Hi,

you know that failsafe is intended for integration tests which are 
usually not parallelizable...


Apart from that maven-eclipse-plugin is retired and shouldn't be part of 
your build any more...


Furthermore without an exmple which shows the behaviour it's hard to 
guess what might be wrong...Do you have full log output...


Which tests running long ?

Kind regards
Karl Heinz


On 09/09/16 20:00, Prakul Agarwal wrote:

Hi,

Using Maven 3.3.9, maven-eclipse-plugin 2.9, failsafe 2.19.1, surefire
2.19.1.

I'm using FailSafe parallel = method and threadCount ={5,10,50,100} to
execute a bunch of test classes with forkCount = {2,3,4,5}. The
integration-test phase is completing sometimes and getting stuck for long
the other times. When it is getting stuck it is taking > 20 min than normal
execution to complete.

In case when tests are getting stuck I notice that the log files
(failsafe-reports folder) of individual test classes are generated each
time consistently but the summary file generation does't happens for long.
Also one surefire-booter jvm lingers on while others are killed.

When I execute in with forkCount = 1 the test execution probably doesnt
start at all (Failsafe-reports folder is not generated, surefire tmp files
are ). If I reduce the number of test classes to be executed (with
forkCount = 1) then the execution is completing normally. We have ~100 test
classes with ~1000 test methods to be executed.

I'm using reuseForks = true and have tried execution after removing all
fork related settings.

Can anyone suggest why this extension is not executing consistently.

Thanks ,

Other configuration:

OS name: "mac os x", version: "10.11.6", Intel 2.8 GHz i7, 16GB DDR3 RAM.

JDK 1.7.0_8




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

Method level parallelization not completing consistently

[Prakul Agarwal]

Hi,

Using Maven 3.3.9, maven-eclipse-plugin 2.9, failsafe 2.19.1, surefire
2.19.1.

I'm using FailSafe parallel = method and threadCount ={5,10,50,100} to
execute a bunch of test classes with forkCount = {2,3,4,5}. The
integration-test phase is completing sometimes and getting stuck for long
the other times. When it is getting stuck it is taking > 20 min than normal
execution to complete.

In case when tests are getting stuck I notice that the log files
(failsafe-reports folder) of individual test classes are generated each
time consistently but the summary file generation does't happens for long.
Also one surefire-booter jvm lingers on while others are killed.

When I execute in with forkCount = 1 the test execution probably doesnt
start at all (Failsafe-reports folder is not generated, surefire tmp files
are ). If I reduce the number of test classes to be executed (with
forkCount = 1) then the execution is completing normally. We have ~100 test
classes with ~1000 test methods to be executed.

I'm using reuseForks = true and have tried execution after removing all
fork related settings.

Can anyone suggest why this extension is not executing consistently.

Thanks ,

Other configuration:

OS name: "mac os x", version: "10.11.6", Intel 2.8 GHz i7, 16GB DDR3 RAM.

JDK 1.7.0_8

-- 
Prakul Agarwal

M.S. Computer Science | University of California, Irvine, Dec '16

Ph: (949)372-8510
Linkedin: https://www.linkedin.com/in/prakulagarwal