[jira] [Commented] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245242#comment-16245242
 ] 

Manfred Moser commented on MRESOLVER-28:


Turns out the rat failures are due .checkstyle files that are created somehow. 
Once I delete them all is good.. 

> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245224#comment-16245224
 ] 

Manfred Moser edited comment on MRESOLVER-28 at 11/9/17 5:33 AM:
-

Further cleanup done. CI build passes. Local site build also worked.

https://builds.apache.org/job/maven-resolver-jenkinsfile/job/master-all/

One issue is that for local build I have to skip rat plugin but that seems to 
be the case for master for me as well. 

What do we need to do as a next step in terms of review? 

I will ask on the maven dev list but essentially my steps would include

- doc updates in readme files and site sources where necessary
- other changes required I cant think of atm
- merge master-all into master
- delete now redundant branchs ant-tasks, ant-tasks-folder, demos, 
demos-folder, master-all
- do a release including binaries deploy and site publish




was (Author: simpligility):
Further cleanup done. CI build passes. Local site build also worked.

https://builds.apache.org/job/maven-resolver-jenkinsfile/job/master-all/

What do we need to do as a next step in terms of review? 

I will ask on the maven dev list but essentially my steps would include

- doc updates in readme files and site sources where necessary
- other changes required I cant think of atm
- merge master-all into master
- delete now redundant branchs ant-tasks, ant-tasks-folder, demos, 
demos-folder, master-all
- do a release including binaries deploy and site publish



> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245224#comment-16245224
 ] 

Manfred Moser commented on MRESOLVER-28:


Further cleanup done. CI build passes. Local site build also worked.

https://builds.apache.org/job/maven-resolver-jenkinsfile/job/master-all/

What do we need to do as a next step in terms of review? 

I will ask on the maven dev list but essentially my steps would include

- doc updates in readme files and site sources where necessary
- other changes required I cant think of atm
- merge master-all into master
- delete now redundant branchs ant-tasks, ant-tasks-folder, demos, 
demos-folder, master-all
- do a release including binaries deploy and site publish



> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-29) Move ant tasks into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245219#comment-16245219
 ] 

Manfred Moser commented on MRESOLVER-29:


More comments in linked issue

> Move ant tasks into master as new module
> 
>
> Key: MRESOLVER-29
> URL: https://issues.apache.org/jira/browse/MRESOLVER-29
> Project: Maven Resolver
>  Issue Type: Task
>  Components: ant tasks
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The ant tasks of Maven Resolver are currently in a separate branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245174#comment-16245174
 ] 

Manfred Moser commented on MRESOLVER-28:


The linked issue and its work is covered in this issue.

> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245173#comment-16245173
 ] 

Manfred Moser commented on MRESOLVER-28:


Thin integration with simple module addition is done and build works. Pushed 
into master-all branch.

WIll improve versioning and so on next.

> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-29) Move ant tasks into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245170#comment-16245170
 ] 

Manfred Moser commented on MRESOLVER-29:


Moved into subfolder and pushed into new branch ant-tasks-folder

> Move ant tasks into master as new module
> 
>
> Key: MRESOLVER-29
> URL: https://issues.apache.org/jira/browse/MRESOLVER-29
> Project: Maven Resolver
>  Issue Type: Task
>  Components: ant tasks
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The ant tasks of Maven Resolver are currently in a separate branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245171#comment-16245171
 ] 

Manfred Moser commented on MRESOLVER-28:


Moved into new folder and pushed in new branch demos-folder

> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MRESOLVER-28) Move demos into master as new module

[Manfred Moser (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Manfred Moser reassigned MRESOLVER-28:
--

Assignee: Manfred Moser

> Move demos into master as new module
> 
>
> Key: MRESOLVER-28
> URL: https://issues.apache.org/jira/browse/MRESOLVER-28
> Project: Maven Resolver
>  Issue Type: Task
>  Components: demo
>Reporter: Manfred Moser
>Assignee: Manfred Moser
>
> The demos of Maven Resolver are currently in a separate demos branch. This 
> makes it hard to keep version consistent and is also harder to understand and 
> locate for users in apache git and on github.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SUREFIRE-1442) report icons missing

[Ernst Reissner (JIRA)]

Ernst Reissner created SUREFIRE-1442:


 Summary: report icons missing 
 Key: SUREFIRE-1442
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1442
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Report Plugin
Affects Versions: 2.20.1
 Environment: linux
Reporter: Ernst Reissner


pom: 
  
org.apache.maven.plugins
maven-surefire-report-plugin
2.20.1

  
  false

  

mvn surefire-report:report 

Then in reports the icons which can be seen in the docs are missing. 
I suspect, that in the docs one must add the information 
how to add the icons. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SUREFIRE-1443) surefire report: broken links with inner classes

[Ernst Reissner (JIRA)]

Ernst Reissner created SUREFIRE-1443:


 Summary: surefire report: broken links with inner classes 
 Key: SUREFIRE-1443
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1443
 Project: Maven Surefire
  Issue Type: Bug
  Components: Maven Surefire Report Plugin
Affects Versions: 2.20.1
 Environment: linux
Reporter: Ernst Reissner
 Attachments: RelanaTest.java, surefire-report.html

pom: 
  
org.apache.maven.plugins
maven-surefire-report-plugin
2.20.1

  
  false

  

testclass as attached. 

Then tying mvn surefire-report:report  

yields waning 
[warn] [XHTML Sink] Modified invalid anchor name: 
'eu.simuline.relana.sysRelanaTest$TestAll' to 
'eu.simuline.relana.sysRelanaTestTestAll'
and in the created html this can be seen: 
dot between sys and RelanaTest missing. 
Partially with $ , partially without so that links are broken 
I attached also the hmtl. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SUREFIRE-1441) Parallel Build Fork Timeout - Impossible To Find Bad Test

[M A (JIRA)]

M A created SUREFIRE-1441:
-

 Summary: Parallel Build Fork Timeout - Impossible To Find Bad Test
 Key: SUREFIRE-1441
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1441
 Project: Maven Surefire
  Issue Type: Bug
  Components: Junit 4.7+ (parallel) support, process forking
Affects Versions: 2.20.1, 2.19.1
Reporter: M A


In any maven project that contains more than a few modules, with a lot of 
tests, it's nearly impossible to understand from the build log what test caused 
a surefire fork timeout when there's only a message with the following line:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
project : There was a timeout or other error in the fork -> [Help 1]
 
In my case, we have a Maven project with more than 200 modules, and nearly 20k 
unit tests.
Lately we've noticed we don't fail our build upon surefire fork timeout, so we 
changed our build behavior (TeamCity in our case) to fail the build in case 
there was any timeout for some test.
But quickly afterwards when the build did start to fail on that issue, we came 
to understatement that it's impossible to find this needle in a haystack, and 
understand what test (not a specific @Test method, but just the test class 
name).

The error message should be more informative and contain useful information for 
debugging.  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MENFORCER-285) error parameters 'rules' are missing or invalid

[Ernst Reissner (JIRA)]

Ernst Reissner created MENFORCER-285:


 Summary: error parameters 'rules'  are missing or invalid 
 Key: MENFORCER-285
 URL: https://issues.apache.org/jira/browse/MENFORCER-285
 Project: Maven Enforcer Plugin
  Issue Type: Bug
  Components: Plugin
Affects Versions: 3.0.0-M1
 Environment: linux
Reporter: Ernst Reissner


I have the following config under build.plugins: 

 
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0-M1

  
enforce

  enforce


  
 

  3.5.0
 

  
  
  true
  true

  

  

Then 
mvn enforcer:enforce

yields 

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli) 
on project Relana: The parameters 'rules' for goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or 
invalid -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli) 
on project Relana: The parameters 'rules' for goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or 
invalid
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginParameterException: The parameters 
'rules' for goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or 
invalid
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:643)
at 
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:596)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginParameterException





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MCOMPILER-315) "Older projects with module-info" documentation does not work

[Keir (JIRA)]

[ 
https://issues.apache.org/jira/browse/MCOMPILER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244938#comment-16244938
 ] 

Keir commented on MCOMPILER-315:


Ok I was able to get it working, not sure exactly what was going wrong for me, 
though would still be good to better understand default-compile and 
base-compile.

> "Older projects with module-info" documentation does not work
> -
>
> Key: MCOMPILER-315
> URL: https://issues.apache.org/jira/browse/MCOMPILER-315
> Project: Maven Compiler Plugin
>  Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Keir
> Attachments: pom.xml
>
>
> I copied and pasted the 2nd snipped from 
> https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html
>  , amending it to refer to Java 8 rather than 6, however the jar produced by 
> mvn package is still only consumable by Java 9 as all classes appear to have 
> been compiled to its version. Is there something else I need to do to get 
> this to work? If so, the documentation could be clearer. Or have I 
> misunderstood something? I have attached the pom in question.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1424) javax.transaction.TransactionManager not visible with Java9

[Russell Gold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244713#comment-16244713
 ] 

Russell Gold commented on SUREFIRE-1424:


Is there a way to disable this hack? 

I am trying to build the glassfish-corba project 
, which defines its own version of 
classes in the javax.rmi.CORBA package, and having --add-modules java.se.ee on 
the command line means that those classes aren’t found during unit tests.

- Russ




> javax.transaction.TransactionManager not visible with Java9
> ---
>
> Key: SUREFIRE-1424
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1424
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: Maven Surefire Plugin
>Affects Versions: 2.20.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
> Maven home: /Users/snicoll/tools/maven
> Java version: 9, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_BE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.6", arch: "x86_64", family: "mac"
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
>
> I am trying to port Spring Boot to Java9 and I am hitting an issue that looks 
> like Maven specific. I've managed to trim down the problem to [a simple class 
> that doesn't involve Spring 
> Boot|https://github.com/snicoll-scratches/test-jta-java9]
> If I run this project on the command line, I get the following:
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.043 s <<< 
> FAILURE! - in com.example.testjtajava9.TestJtaJava9ApplicationTests
> contextLoads(com.example.testjtajava9.TestJtaJava9ApplicationTests)  Time 
> elapsed: 0.006 s  <<< ERROR!
> java.lang.NoClassDefFoundError: javax/transaction/TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> Caused by: java.lang.ClassNotFoundException: 
> javax.transaction.TransactionManager
>   at 
> com.example.testjtajava9.TestJtaJava9ApplicationTests.contextLoads(TestJtaJava9ApplicationTests.java:9)
> {noformat}
> If I run that test with IntelliJ IDEA, it passes. This sample project has 
> also a simple Gradle build that shows it works with Gradle as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6223) mvn -f outputs invalid error when specifying POM directory

[Charles Gould (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244502#comment-16244502
 ] 

Charles Gould commented on MNG-6223:


Thanks for getting this fix into 3.5.2!

> mvn -f outputs invalid error when specifying POM directory
> --
>
> Key: MNG-6223
> URL: https://issues.apache.org/jira/browse/MNG-6223
> Project: Maven
>  Issue Type: Bug
>  Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /Users/cgould/dev/tools/apache-maven-3.5.0
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Charles Gould
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.5.2
>
> Attachments: alternate-pom.zip
>
>
> Basic multi-module project: common, client, and server modules.
>  
> {noformat}
> $ mvn -f client package
> POM file client specified with the -f/--file command line argument does not 
> exist
> [INFO] Scanning for projects...
> [INFO]
> [INFO] 
> 
> [INFO] Building alternate-pom-client 1.0
> [INFO] 
> 
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> /Users/cgould/dev/personal/alternate-pom/client/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ 
> alternate-pom-client ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> /Users/cgould/dev/personal/alternate-pom/client/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ 
> alternate-pom-client ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ 
> alternate-pom-client ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ alternate-pom-client ---
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> [INFO] Total time: 0.764 s
> [INFO] Finished at: 2017-04-29T14:03:22-04:00
> [INFO] Final Memory: 11M/309M
> [INFO] 
> 
> {noformat}
> There is an error message, but the client module proceeds to build 
> nonetheless.
> I don't see the error message when I run:
> {noformat}
> $ mvn -f client/pom.xml package
> {noformat}
> I've verified it doesn't happen on 3.3.9, but it does happen on 3.5.0 and 
> 3.5.0-alpha-1.
> Sample project attached.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MSKINS-137) Enable "Hamburger menu" with top-nav only

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSKINS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244526#comment-16244526
 ] 

ASF GitHub Bot commented on MSKINS-137:
---

joshelser commented on issue #1: MSKINS-137 Make the hamburger menu work with 
the top-navigation ena…
URL: https://github.com/apache/maven-fluido-skin/pull/1#issuecomment-342918748
 
 
   >  To test, I understand that any rendering of the skin with a nav bar in a 
little screen should be used: we already have a few when running "mvn -Prun-its 
verify"
   
   Great. Will take a look.
   
   > But with the patch applied, there is a space added before the topbar: to 
me, the patch breaks topbar positionning.
   
   Yeah, I did have to tweak some CSS down in HBase. I assumed that was 
something we were doing down there -- will have to circle around and see if I 
can make the equivalent change here instead :)
   
   > Please share a screenshot of the issue you get in hbase, then the result 
once the patch fixes the issue
   
   Acknowledged.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable "Hamburger menu" with top-nav only
> -
>
> Key: MSKINS-137
> URL: https://issues.apache.org/jira/browse/MSKINS-137
> Project: Maven Skins
>  Issue Type: Improvement
>Reporter: Josh Elser
>
> Revitalizing this old PR https://github.com/apache/maven-skins/pull/4
> Still an issue for us down in HBase. Changes seem to apply and have worked in 
> local testing on the HBase site.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] joshelser commented on issue #1: MSKINS-137 Make the hamburger menu work with the top-navigation ena?

[GitBox]

joshelser commented on issue #1: MSKINS-137 Make the hamburger menu work with 
the top-navigation ena?
URL: https://github.com/apache/maven-fluido-skin/pull/1#issuecomment-342918748
 
 
   >  To test, I understand that any rendering of the skin with a nav bar in a 
little screen should be used: we already have a few when running "mvn -Prun-its 
verify"
   
   Great. Will take a look.
   
   > But with the patch applied, there is a space added before the topbar: to 
me, the patch breaks topbar positionning.
   
   Yeah, I did have to tweak some CSS down in HBase. I assumed that was 
something we were doing down there -- will have to circle around and see if I 
can make the equivalent change here instead :)
   
   > Please share a screenshot of the issue you get in hbase, then the result 
once the patch fixes the issue
   
   Acknowledged.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MSKINS-137) Enable "Hamburger menu" with top-nav only

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSKINS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244496#comment-16244496
 ] 

ASF GitHub Bot commented on MSKINS-137:
---

hboutemy commented on issue #1: MSKINS-137 Make the hamburger menu work with 
the top-navigation ena…
URL: https://github.com/apache/maven-fluido-skin/pull/1#issuecomment-342916660
 
 
   thanks fo the explanation: now I know what a hamburger menu is :)
   To test, I understand that any rendering of the skin with a nav bar in a 
little screen should be used: we already have a few when running "mvn -Prun-its 
verify"
   Then I checked hbase site: the hamburger menu was perfect. But with the 
patch applied, there is a space added before the topbar: to me, the patch 
breaks topbar positionning.
   
   Please share a screenshot of the issue you get in hbase, then the result 
once the patch fixes the issue


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable "Hamburger menu" with top-nav only
> -
>
> Key: MSKINS-137
> URL: https://issues.apache.org/jira/browse/MSKINS-137
> Project: Maven Skins
>  Issue Type: Improvement
>Reporter: Josh Elser
>
> Revitalizing this old PR https://github.com/apache/maven-skins/pull/4
> Still an issue for us down in HBase. Changes seem to apply and have worked in 
> local testing on the HBase site.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] hboutemy commented on issue #1: MSKINS-137 Make the hamburger menu work with the top-navigation ena?

[GitBox]

hboutemy commented on issue #1: MSKINS-137 Make the hamburger menu work with 
the top-navigation ena?
URL: https://github.com/apache/maven-fluido-skin/pull/1#issuecomment-342916660
 
 
   thanks fo the explanation: now I know what a hamburger menu is :)
   To test, I understand that any rendering of the skin with a nav bar in a 
little screen should be used: we already have a few when running "mvn -Prun-its 
verify"
   Then I checked hbase site: the hamburger menu was perfect. But with the 
patch applied, there is a space added before the topbar: to me, the patch 
breaks topbar positionning.
   
   Please share a screenshot of the issue you get in hbase, then the result 
once the patch fixes the issue


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Tom Wieczorek (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244410#comment-16244410
 ] 

Tom Wieczorek commented on MNG-6220:


[~jgl...@netbeans.org] Thanks for pointing out. Just saw "Resolution Fixed" but 
not the link to the follow-up.

Sorry for the noise.

> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MSKINS-137) Enable "Hamburger menu" with top-nav only

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSKINS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244330#comment-16244330
 ] 

ASF GitHub Bot commented on MSKINS-137:
---

joshelser commented on issue #1: MSKINS-137 Make the hamburger menu work with 
the top-navigation ena…
URL: https://github.com/apache/maven-fluido-skin/pull/1#issuecomment-342886972
 
 
   Thanks, Hervé!
   
   > But I don't understand what this change does: can you describe a little 
bit the issue (what a "hamburger menu" is)?
   
   See https://en.wikipedia.org/wiki/Hamburger_button for starters :). If you 
visit https://hbase.apache.org/ on your mobile or shrink down the page in a 
browser, you'll see the nav-bar at the top of the page convert into a drop-down 
with the "stacked-lines" (hamburger) button to open/close it.
   
   >  Is there one existing IT that show clearly the issue (then the fix)?
   
   Admittedly, I didn't look at all into how to test :D. Have any 
pointers/docs/suggestions on what kind of test would be effective?
   
   > Sidenote: this is a generic topic with Skins, ie understanding html/css 
changes. Any generic idea on how to describe an issue and a fix, between 
"designer oriented" people (who are html/css experts) and "java dev" oriented 
people (like Maven developpers, like me, who is not proficient at all with 
modern html/css, who need to judge before merging...)
   
   Ditto. CSS has changed drastically since I've done anything of consequence 
with it :D. I'm mostly repurposing Misty's original commit here. My general 
understanding is that bootstrap is doing some special logic when the "window" 
(or maybe screen is more appropriate) reduces to a certain size. Then it uses 
some CSS rules to convert the content into the dynamic drop-down instead of how 
it appears on screens with adequate width.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable "Hamburger menu" with top-nav only
> -
>
> Key: MSKINS-137
> URL: https://issues.apache.org/jira/browse/MSKINS-137
> Project: Maven Skins
>  Issue Type: Improvement
>Reporter: Josh Elser
>
> Revitalizing this old PR https://github.com/apache/maven-skins/pull/4
> Still an issue for us down in HBase. Changes seem to apply and have worked in 
> local testing on the HBase site.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] joshelser commented on issue #1: MSKINS-137 Make the hamburger menu work with the top-navigation ena?

[GitBox]

joshelser commented on issue #1: MSKINS-137 Make the hamburger menu work with 
the top-navigation ena?
URL: https://github.com/apache/maven-fluido-skin/pull/1#issuecomment-342886972
 
 
   Thanks, Herv?!
   
   > But I don't understand what this change does: can you describe a little 
bit the issue (what a "hamburger menu" is)?
   
   See https://en.wikipedia.org/wiki/Hamburger_button for starters :). If you 
visit https://hbase.apache.org/ on your mobile or shrink down the page in a 
browser, you'll see the nav-bar at the top of the page convert into a drop-down 
with the "stacked-lines" (hamburger) button to open/close it.
   
   >  Is there one existing IT that show clearly the issue (then the fix)?
   
   Admittedly, I didn't look at all into how to test :D. Have any 
pointers/docs/suggestions on what kind of test would be effective?
   
   > Sidenote: this is a generic topic with Skins, ie understanding html/css 
changes. Any generic idea on how to describe an issue and a fix, between 
"designer oriented" people (who are html/css experts) and "java dev" oriented 
people (like Maven developpers, like me, who is not proficient at all with 
modern html/css, who need to judge before merging...)
   
   Ditto. CSS has changed drastically since I've done anything of consequence 
with it :D. I'm mostly repurposing Misty's original commit here. My general 
understanding is that bootstrap is doing some special logic when the "window" 
(or maybe screen is more appropriate) reduces to a certain size. Then it uses 
some CSS rules to convert the content into the dynamic drop-down instead of how 
it appears on screens with adequate width.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Commented] (MNG-5102) Mixin POM fragments

[Sam Brougher (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244317#comment-16244317
 ] 

Sam Brougher commented on MNG-5102:
---

The inability to have some kind of mixin functionality is likely going to drive 
my company away from Maven to something like Gradle. This should really be a 
much higher priority than "maybe someday".

> Mixin POM fragments
> ---
>
> Key: MNG-5102
> URL: https://issues.apache.org/jira/browse/MNG-5102
> Project: Maven
>  Issue Type: Wish
>  Components: FDPFC, POM
>Affects Versions: 2.2.1
>Reporter: Anthony Whitford
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: daddy3.zip, maven-tiles.zip
>
>
> I am looking for a way to _mixin_ POM fragments into POMs.  Note that this 
> idea is beyond parent pom inheritance because all projects inherit from a 
> corporate parent pom.  The problem that I am running into is that the 
> corporate parent pom is turning into an _"everything but the kitchen sink"_ 
> POM and I'd like to dissect it into POM fragments relevant for individual 
> modules.
> For example, I would like to have mixins for:
> * Java projects (that include static code analysis plugins, javadoc, etc.)
> * JPA projects (that include DDL generation)
> * Flex projects (that include flexmojos, asdoc, etc.)
> * Scala projects (that include the maven-scala-compiler plugin, scaladoc, 
> etc.)
> * JavaScript projects (that include build plugins like 
> maven-yuicompressor-plugin with jslint and compress goals)
> Hopefully, you get the idea.  Without the ability to factor pom logic, we are 
> left with two symptoms:
> # copy/paste duplication
> # complex _"it does it all"_ parent poms (which slow down builds because more 
> plugins are loaded even though they might not do anything material)
> Note that a project may include multiple mixins as I could have a project 
> that contains Java code, Scala code, and JavaScript.
> Another idea is that the mixins could be parameterized, so that the ultimate 
> pom can be customized based on the parameters (like tokens).
> I recall reading about Mixins coming in Maven 3.1, but could not find any 
> such issue to watch, so am creating one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Jesse Glick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244271#comment-16244271
 ] 

Jesse Glick commented on MNG-6220:
--

I was directed to MNG-6296 which tracks the problem.

> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MINDEXER-106) ClassNotFoundException (org.sonatype.aether.version.InvalidVersionSpecificationException) under recent Maven versions

[Eric Barboni (JIRA)]

[ 
https://issues.apache.org/jira/browse/MINDEXER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244169#comment-16244169
 ] 

Eric Barboni commented on MINDEXER-106:
---

[~sewe]

 after cloning use the following maven command (-DnexusIndexDirectory must be 
configured according to your will and os)
{noformat}
mvn clean install  org.codehaus.mojo:nb-repository-plugin:1.4-SNAPSHOT:download 
-DnexusIndexDirectory=/tmp/test -DrepositoryUrl=https://repo1.maven.org/maven2
{noformat}

With maven 3.0.5 it works (but it take time)

With maven 3.5.2 
{noformat}
Caused by: java.lang.ClassNotFoundException: 
org.sonatype.aether.version.VersionScheme
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass 
(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass 
(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass 
(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass 
(ClassRealm.java:239)
at org.apache.maven.index.context.IndexUtils.constructArtifactInfo 
(IndexUtils.java:111)
at org.apache.maven.index.context.IndexUtils.updateDocument 
(IndexUtils.java:135)
at org.apache.maven.index.updater.IndexDataReader.readIndex 
(IndexDataReader.java:92)
at org.apache.maven.index.updater.DefaultIndexUpdater.unpackIndexData 
(DefaultIndexUpdater.java:509)
at org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory 
(DefaultIndexUpdater.java:197)
at org.apache.maven.index.updater.DefaultIndexUpdater.access$300 
(DefaultIndexUpdater.java:76)
at 
org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile
 (DefaultIndexUpdater.java:642)
at org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex 
(DefaultIndexUpdater.java:862)
at org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex 
(DefaultIndexUpdater.java:157)
at org.codehaus.mojo.nbm.repository.DownloadIndexMojo.execute 
(DownloadIndexMojo.java:152)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.jvnet.hudson.maven3.launcher.Maven35Launcher.main 
(Maven35Launcher.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
at jenkins.maven3.agent.Maven35Main.launch (Maven35Main.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at hudson.maven.Maven3Builder.call (Maven3Builder.java:139)
at hudson.maven.Maven3Builder.call (Maven3Builder.java:70)
at hudson.remoting.UserRequest.perform (UserRequest.java:205)
at hudson.remoting.UserRequest.perform (UserRequest.java:52)
at hudson.remoting.Request$2.run (Request.java:356)
at hudson.remoting.InterceptingExecutorService$1.call 
(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run (FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker 
(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run 
(ThreadPoolExecutor.java:624)
at java.lang.Thread.run (Thread.java:748)
{noformat}





> ClassNotFoundException 
> (org.sonatype.aether.version.InvalidVersionSpecificationException) under 
> recent Maven versions
> 

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Jesse Glick (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244119#comment-16244119
 ] 

Jesse Glick commented on MNG-6220:
--

The usual risks of relying on unit tests: you get what you pay for. :-/ 
[~rfscholte] can this be reopened? (I have no permissions to do so.)

> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Daniel Beland (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244089#comment-16244089
 ] 

Daniel Beland commented on MNG-6220:


I'm sorry to say but it is not working and the test is wrong.

The test goes (MavenCliTest.java):


{code:java}
MessageUtils.setColorEnabled( true );
request = new CliRequest( new String[] { "-Dstyle.color=never" }, null 
);
cli.cli( request );
cli.properties( request );
cli.logging( request );
assertFalse( MessageUtils.isColorEnabled() );
{code}

While the real code goes (MavenCli.java):

{code:java}
try
{
initialize( cliRequest );
cli( cliRequest );
logging( cliRequest );
version( cliRequest );
properties( cliRequest );
localContainer = container( cliRequest );
commands( cliRequest );
configure( cliRequest );
toolchains( cliRequest );
populateRequest( cliRequest );
encryption( cliRequest );
repository( cliRequest );
return execute( cliRequest );
}
{code}

cli.logging is called before cli.properties while the test was calling them in 
a different order.
When I debug maven the userProperties is always empty and then default value of 
auto is assumed for the color logging.


> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Tom Wieczorek (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243969#comment-16243969
 ] 

Tom Wieczorek commented on MNG-6220:


[~dcendents]: The PR was closed in favor of 
[785bad693c60ad60d7b307af8fab9e9234ff57bd|http://git-wip-us.apache.org/repos/asf/maven/commit/785bad69].

> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Daniel Beland (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243956#comment-16243956
 ] 

Daniel Beland commented on MNG-6220:


It seems like it was not added to the maven 3.5.2 release.
Was the pull request merged?

Looking at the pull request, the parameter is '--color=always|never|auto': 
https://github.com/apache/maven/pull/114/files

But when I check the source code for CLIManager on tag maven-3.5.2 it is not 
there: 
https://github.com/apache/maven/blob/maven-3.5.2/maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java

I'm a bit confused...

> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SUREFIRE-1436) Increase usability in quiet mode

[Zoltan Haindrich (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243946#comment-16243946
 ] 

Zoltan Haindrich commented on SUREFIRE-1436:


sorry for the late answer; I've just checked it, and its working fine!
thank you [~tibor17]!
Meanwhile I've found an alternative way to get back the old surefire output in 
all cases: 
either using: 
{{-Dorg.slf4j.simpleLogger.log.org.apache.maven.plugin.surefire.SurefirePlugin=INFO}}
or adding it to the maven installation's simplelogger.properties



> Increase usability in quiet mode
> 
>
> Key: SUREFIRE-1436
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1436
> Project: Maven Surefire
>  Issue Type: Wish
>Affects Versions: 2.20, 2.20.1
>Reporter: Zoltan Haindrich
>Assignee: Tibor Digana
> Fix For: 2.21.0.Jigsaw
>
>
> Prior to SUREFIRE-1436. The messages which were closely related to test 
> execution were printed directly to the console instead of the logger.info
> https://github.com/apache/maven-surefire/commit/6a79127ab63273f0f1f5268c65e4806761871a46#diff-94128f02ad41a51dcab77c0e0756705fL136
> I always execute maven with `-q` because of the high volume of irrelevant 
> messages it prints out.
> I miss the following messages when silent mode is active:
> {code}
> Running org.apache.hadoop.hive.cli.TestMiniLlapCliDriver
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.93 s - in 
> org.apache.hadoop.hive.cli.TestMiniLlapCliDriver
> {code}
> * It would be great to get back the old behaviour
> * especially important to get back disaplaying the {{Listening for transport 
> dt_socket at address: 5005}} message in case someone executes: {{mvn install 
> -q -Dtest=TestA -Dmaven.surefire.debug}} 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MNG-6220) Add CLI options to control color output

[Tom Wieczorek (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243779#comment-16243779
 ] 

Tom Wieczorek commented on MNG-6220:


I'm somehow not able to see any change when using {{-Dstyle.color=XXX}} with 
Maven 3.5.2. It always uses the auto detection. Can somebody confirm that it's 
working? I tried {{never}} at the terminal and had colors. I tried {{always}} 
when piping, and got no colors. I also tried some bogus value to trigger the 
exception, but to no avail.

I tried both {{MAVEN_OPTS}} and as an argument to {{mvn}}.

{noformat}
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
2017-10-18T09:58:13+02:00)
Maven home: /opt/apache-maven-3.5.2
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-oracle/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-37-generic", arch: "amd64", family: "unix"
{noformat}


> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
>  Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the 
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment 
> with the ansicolor plugin), there is no CLI option combination to support the 
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)