Re: Dealing with a generated project
Archetype with swagger Params in -D
On Sun, Aug 27, 2017, 11:32 AM Sander Verhagen
wrote:
> Apparently no one had ideas about this. That hurts :)
>
> Just circling back with what ended up being my approach. So we generate a
> Maven project using Swagger Codegen Maven Plugin. I now generate it
> somewhere below the "target/" folder of the POM project that has this
> configuration. Then use the Maven Invoker Plugin in the compile phase to do
> an install on the generated project, and in the deploy phase to do a deploy
> on the generated project (the latter with skipTest=true, to not repeat too
> much). The later Invoker run also has the following configured, so that the
> generated project ends up in our company POM (without itself carrying this
> information, as the generated project is ultimately aimed at public
> consumption):
>
> ${
> project.distributionManagement.snapshotRepository.id
> }::default::${project.distributionManagement.snapshotRepository.url}
>
> I probably left out some small but fancy details. I code reviewed this
> with some colleagues, who praised me for my wicked Maven skills. Now...
> that's not necessarily a good thing, because this is one of those cases
> where little is left from Maven's "convention over configuration"
> philosophy, and others may have a hard time figuring out how this all
> works. (Including future versions of myself. That wouldn't be a first
> either.)
>
> That's all.
>
>
>
> Sander Verhagen
> [ san...@sanderverhagen.net ]
>
> -Original Message-
> From: Sander Verhagen [mailto:san...@sanderverhagen.net]
> Sent: Saturday, July 22, 2017 01:10
> To: Maven Users List
> Subject: Dealing with a generated project
>
> Hi list,
>
>
> The REST API of our application is using Swagger for documentation. During
> build we spin up our application, extract the Swagger JSON document, and
> feed it into the Swagger Codegen Maven Plugin to generate an API client.
> This plugin spits out a complete Maven project (and Gradle for that
> matter), including Java files that represent this API client, even Java
> files with unit tests. Great!
>
> So, now I have a generated project, that's not part of my current Maven
> build. (Could it be?) I've used generated code plenty, but I struggle to
> fully comprehend what the best pattern is for this generated project. I
> would like this project to be published to our Artifactory (its artifact)
> and to Git (its source code). All preferably from the same build. For the
> publish to Git I'm afraid to get into the vendor branch pattern, which I've
> never done well at. I'm anyway not even sure if I'd want to publish to Git
> on every build, and every commit of my application, or maybe publish to Git
> based on a source JAR (is that even a thing?), so yeah, I could use some
> pointers, if anyone has any some good ideas or examples to look at.
>
> Thanks, Sander.
>
>
>
> Sander Verhagen
> [ san...@sanderverhagen.net ]
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: How does maven handle Java module dependencies?
Hi Robert, That sounds great. Any idea on timing of the release? What about the surefire plugin? Is there something I can do to help? I am actively working on Java 9 issues in a few projects, including both the module system and multi-release jars, so I am very motivated to do what I can to help maven get there. Thanks, Russ > On Aug 27, 2017, at 8:38 AM, Robert Scholte wrote: > > Hi Russ, > > this is how it works: > in case there's a module descriptor, the module-path with be used. With the > help of plexus-java it is possible to divide all jars over the module-path > and classpath. This mechanism is implemented in the maven-compiler-plugin > (will do an official release soon with the latest improvements), other > plugins can/should use this too. > > This means that you actually don't need to change anything in your pom.xml. > With the module descriptor and all the dependencies there's enough > information to decide which jars belong on the modulepath and which on the > classpath. So in the end there's no need for new scopes anymore, although > that was my first thought as well. > > To create an installer, I think you're referring to JLink. Karl Heinz is > preparing the maven-jlink-plugin. > > thanks, > Robert > > On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold > wrote: > >> I’m sure this must have been described somewhere; is there an overall >> direction document for supporting the java platform module system? >> >> case 1) >> >> I want to compile against another project on the module path rather than the >> class path. I do this in order to ensure compile-time checking for attempts >> to compile against non-exported packages. >> >> case 2) >> >> I want to test against another project on the module path. This would allow >> me to catch reflective access attempts against that module’s internals >> >> case 3) >> >> I want to use the module dependencies to create an installer, with the >> dependent modules on the module path. In theory, if Maven understands the >> above 2 cases, it would also be able to verify the requires clauses in my >> project’s module-info. >> >> So how will we be doing this in maven? Is it already supported? My first >> thought was that we need two new scopes: module (case 1) and module-test >> (case 2), but has this already been planned? >> >> Thanks, >> Russ >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding certain files from compilation or checking
Yikes. Does that mean I can't exclude a file with a comma in it? I.e., one called .,thisisafilename.java -- Seth Copen Goldstein Carnegie Mellon University Computer Science Dept 7111 GHC 412-268-3828 On Sun, Aug 27, 2017 at 4:59 PM, Robert Scholte wrote: > Hi, > > this can't be correct: > **/.,*.java > > this means: exclude all files called . (yes, just dot) and exclude all > *.java files in the root. > Don't think you're excluding anything, running with debug logging will > probably confirm that. > > Robert > > > On Sun, 27 Aug 2017 22:54:42 +0200, Seth Goldstein wrote: > > You are absolutely correct. In case others want this - exclude files from >> being checked and compiled - Here is the relevant part of the pom file: >> >> >> >> org.apache.maven.plugins >> maven-compiler-plugin >> 2.0.2 >> >> >> **/.,*.java >> >> >> >> >> org.apache.maven.plugins >> maven-checkstyle-plugin >> 2.17 >> >> >> validate >> validate >> >> check >> >> >> >> >> config/checkstyle.xml >> **/.,*.java >> >> >> >> >> >> >> -- >> Seth Copen Goldstein >> Carnegie Mellon University >> Computer Science Dept >> 7111 GHC >> 412-268-3828 >> >> On Sat, Aug 26, 2017 at 11:03 PM, Benson Margulies > > >> wrote: >> >> You have excluded it from the checkstyle plugin, but it's the Java >>> compiler which is discontented. You need to configure the compiler >>> plugin, as well. >>> >>> On Sat, Aug 26, 2017 at 12:03 PM, Seth Goldstein wrote: >>> > I would have expected that too, however: >>> > >>> > >>> > org.apache.maven.plugins >>> > maven-checkstyle-plugin >>> > 2.17 >>> > >>> > >>> > validate >>> > validate >>> > >>> > check >>> > >>> > >>> > >>> > >>> > config/checkstyle.xml >>> > **/.,*.java >>> > >>> > >>> > >>> > And it reports that: >>> > >>> > [ERROR] >>> > /mnt/shared/seth/courses/619/f17/src/my-app/src/main/java/ >>> com/mycompany/app/.,foo.java:[7,7] >>> > error: class App is public, should be declared in a file named App.java >>> > >>> > So, still getting .,* files. Wish this would work properly. >>> > >>> > >>> > -- >>> > Seth Copen Goldstein >>> > Carnegie Mellon University >>> > Computer Science Dept >>> > 7111 GHC >>> > 412-268-3828 >>> > >>> > On Sat, Aug 26, 2017 at 6:47 AM, Robert Scholte >>> > wrote: >>> > >>> >> I would expect it to be **/.* >>> >> **/ means zero or more directories >>> >> .* any file with a dot followed by anything >>> >> >>> >> Robert >>> >> >>> >> ps. repeating the same element within configuration like you did with >>> >> means the last one will win. >>> >> >>> >> >>> >> On Fri, 25 Aug 2017 23:26:58 +0200, Seth Goldstein >>> wrote: >>> >> >>> >> I am trying to exclude all files that begin with '.,' from being >>> checked or >>> >>> compiled. Is there a quick and easy way to do this? The following >>> does >>> >>> NOT work: >>> >>> >>> >>> >>> >>> org.apache.maven.plugins >>> >>> maven-checkstyle-plugin >>> >>> 2.17 >>> >>> >>> >>> >>> >>> validate >>> >>> validate >>> >>> >>> >>> check >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> .,*.java >>> >>> **/.,*.java >>> >>> **/**/.,*.java >>> >>> **/**/**/.,*.java >>> >>> **/**/**/**/.,*.java >>> >>> **/**/**/**/**/.,*.java >>> >>> src/main/java/com/mycompany/app/.,*.java >>> >>> >>> >>> >>> >>> >>> >>> Any suggestions? >>> >>> >>> >>> -seth >>> >>> >>> >> >>> >> - >>> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> >> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >>> >> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Excluding certain files from compilation or checking
Hi, this can't be correct: **/.,*.java this means: exclude all files called . (yes, just dot) and exclude all *.java files in the root. Don't think you're excluding anything, running with debug logging will probably confirm that. Robert On Sun, 27 Aug 2017 22:54:42 +0200, Seth Goldstein wrote: You are absolutely correct. In case others want this - exclude files from being checked and compiled - Here is the relevant part of the pom file: org.apache.maven.plugins maven-compiler-plugin 2.0.2 **/.,*.java org.apache.maven.plugins maven-checkstyle-plugin 2.17 validate validate check config/checkstyle.xml **/.,*.java -- Seth Copen Goldstein Carnegie Mellon University Computer Science Dept 7111 GHC 412-268-3828 On Sat, Aug 26, 2017 at 11:03 PM, Benson Margulies wrote: You have excluded it from the checkstyle plugin, but it's the Java compiler which is discontented. You need to configure the compiler plugin, as well. On Sat, Aug 26, 2017 at 12:03 PM, Seth Goldstein wrote: > I would have expected that too, however: > > > org.apache.maven.plugins > maven-checkstyle-plugin > 2.17 > > > validate > validate > > check > > > > > config/checkstyle.xml > **/.,*.java > > > > And it reports that: > > [ERROR] > /mnt/shared/seth/courses/619/f17/src/my-app/src/main/java/ com/mycompany/app/.,foo.java:[7,7] > error: class App is public, should be declared in a file named App.java > > So, still getting .,* files. Wish this would work properly. > > > -- > Seth Copen Goldstein > Carnegie Mellon University > Computer Science Dept > 7111 GHC > 412-268-3828 > > On Sat, Aug 26, 2017 at 6:47 AM, Robert Scholte > wrote: > >> I would expect it to be **/.* >> **/ means zero or more directories >> .* any file with a dot followed by anything >> >> Robert >> >> ps. repeating the same element within configuration like you did with >> means the last one will win. >> >> >> On Fri, 25 Aug 2017 23:26:58 +0200, Seth Goldstein wrote: >> >> I am trying to exclude all files that begin with '.,' from being checked or >>> compiled. Is there a quick and easy way to do this? The following does >>> NOT work: >>> >>> >>> org.apache.maven.plugins >>> maven-checkstyle-plugin >>> 2.17 >>> >>> >>> validate >>> validate >>> >>> check >>> >>> >>> >>> >>> .,*.java >>> **/.,*.java >>> **/**/.,*.java >>> **/**/**/.,*.java >>> **/**/**/**/.,*.java >>> **/**/**/**/**/.,*.java >>> src/main/java/com/mycompany/app/.,*.java >>> >>> >>> >>> Any suggestions? >>> >>> -seth >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Excluding certain files from compilation or checking
You are absolutely correct. In case others want this - exclude files from being checked and compiled - Here is the relevant part of the pom file: org.apache.maven.plugins maven-compiler-plugin 2.0.2 **/.,*.java org.apache.maven.plugins maven-checkstyle-plugin 2.17 validate validate check config/checkstyle.xml **/.,*.java -- Seth Copen Goldstein Carnegie Mellon University Computer Science Dept 7111 GHC 412-268-3828 On Sat, Aug 26, 2017 at 11:03 PM, Benson Margulies wrote: > You have excluded it from the checkstyle plugin, but it's the Java > compiler which is discontented. You need to configure the compiler > plugin, as well. > > On Sat, Aug 26, 2017 at 12:03 PM, Seth Goldstein wrote: > > I would have expected that too, however: > > > > > > org.apache.maven.plugins > > maven-checkstyle-plugin > > 2.17 > > > > > > validate > > validate > > > > check > > > > > > > > > > config/checkstyle.xml > > **/.,*.java > > > > > > > > And it reports that: > > > > [ERROR] > > /mnt/shared/seth/courses/619/f17/src/my-app/src/main/java/ > com/mycompany/app/.,foo.java:[7,7] > > error: class App is public, should be declared in a file named App.java > > > > So, still getting .,* files. Wish this would work properly. > > > > > > -- > > Seth Copen Goldstein > > Carnegie Mellon University > > Computer Science Dept > > 7111 GHC > > 412-268-3828 > > > > On Sat, Aug 26, 2017 at 6:47 AM, Robert Scholte > > wrote: > > > >> I would expect it to be **/.* > >> **/ means zero or more directories > >> .* any file with a dot followed by anything > >> > >> Robert > >> > >> ps. repeating the same element within configuration like you did with > >> means the last one will win. > >> > >> > >> On Fri, 25 Aug 2017 23:26:58 +0200, Seth Goldstein > wrote: > >> > >> I am trying to exclude all files that begin with '.,' from being > checked or > >>> compiled. Is there a quick and easy way to do this? The following > does > >>> NOT work: > >>> > >>> > >>> org.apache.maven.plugins > >>> maven-checkstyle-plugin > >>> 2.17 > >>> > >>> > >>> validate > >>> validate > >>> > >>> check > >>> > >>> > >>> > >>> > >>> .,*.java > >>> **/.,*.java > >>> **/**/.,*.java > >>> **/**/**/.,*.java > >>> **/**/**/**/.,*.java > >>> **/**/**/**/**/.,*.java > >>> src/main/java/com/mycompany/app/.,*.java > >>> > >>> > >>> > >>> Any suggestions? > >>> > >>> -seth > >>> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: How does maven handle Java module dependencies?
Hi, On 27/08/17 14:38, Robert Scholte wrote: Hi Russ, this is how it works: in case there's a module descriptor, the module-path with be used. With the help of plexus-java it is possible to divide all jars over the module-path and classpath. This mechanism is implemented in the maven-compiler-plugin (will do an official release soon with the latest improvements), other plugins can/should use this too. This means that you actually don't need to change anything in your pom.xml. With the module descriptor and all the dependencies there's enough information to decide which jars belong on the modulepath and which on the classpath. So in the end there's no need for new scopes anymore, although that was my first thought as well. To create an installer, I think you're referring to JLink. Karl Heinz is preparing the maven-jlink-plugin. This is not an installer it is a Java Run-Time Image which uses JLink (maven-jlink-plugin, maven-jmod-plugin)... An example how it looks like at the moment can be seen[1] and in [2] how the most recent code works... The first alpha release of maven-jlink-plugin and maven-jmod-plugin is planned within a few weeks... Kind regards Karl Heinz Marbaise [1]: http://blog.soebes.de/blog/2017/06/06/howto-create-a-java-run-time-image-with-maven/ [2]: https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-example thanks, Robert On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold wrote: I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system? case 1) I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages. case 2) I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals case 3) I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info. So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned? Thanks, Russ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How does maven handle Java module dependencies?
Hi Russ, this is how it works: in case there's a module descriptor, the module-path with be used. With the help of plexus-java it is possible to divide all jars over the module-path and classpath. This mechanism is implemented in the maven-compiler-plugin (will do an official release soon with the latest improvements), other plugins can/should use this too. This means that you actually don't need to change anything in your pom.xml. With the module descriptor and all the dependencies there's enough information to decide which jars belong on the modulepath and which on the classpath. So in the end there's no need for new scopes anymore, although that was my first thought as well. To create an installer, I think you're referring to JLink. Karl Heinz is preparing the maven-jlink-plugin. thanks, Robert On Sun, 27 Aug 2017 13:50:46 +0200, Russell Gold wrote: I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system? case 1) I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages. case 2) I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals case 3) I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info. So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned? Thanks, Russ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How does maven handle Java module dependencies?
A bit more research turned up this page https://www.sitepoint.com/maven-cannot-generate-module-declaration/ in which Robert explains why my “first thought” below is a non-starter, unless the pom spec is upgraded. So it sounds now as though we are waiting on ASM to read module-info files…? Is there really nothing to be done in the meantime? > On Aug 27, 2017, at 7:50 AM, Russell Gold wrote: > > I’m sure this must have been described somewhere; is there an overall > direction document for supporting the java platform module system? > > case 1) > > I want to compile against another project on the module path rather than the > class path. I do this in order to ensure compile-time checking for attempts > to compile against non-exported packages. > > case 2) > > I want to test against another project on the module path. This would allow > me to catch reflective access attempts against that module’s internals > > case 3) > > I want to use the module dependencies to create an installer, with the > dependent modules on the module path. In theory, if Maven understands the > above 2 cases, it would also be able to verify the requires clauses in my > project’s module-info. > > So how will we be doing this in maven? Is it already supported? My first > thought was that we need two new scopes: module (case 1) and module-test > (case 2), but has this already been planned? > > Thanks, > Russ > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How does maven handle Java module dependencies?
I’m sure this must have been described somewhere; is there an overall direction document for supporting the java platform module system? case 1) I want to compile against another project on the module path rather than the class path. I do this in order to ensure compile-time checking for attempts to compile against non-exported packages. case 2) I want to test against another project on the module path. This would allow me to catch reflective access attempts against that module’s internals case 3) I want to use the module dependencies to create an installer, with the dependent modules on the module path. In theory, if Maven understands the above 2 cases, it would also be able to verify the requires clauses in my project’s module-info. So how will we be doing this in maven? Is it already supported? My first thought was that we need two new scopes: module (case 1) and module-test (case 2), but has this already been planned? Thanks, Russ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 1;34mINFO[m] formatting on console output
ok, let's adapt to your profile First, let's see if the issue is related to your general Maven installation or to your project that uses Selenium and that could cause some sort of conflict. Can you run "mvn -V -X" from a directory where there is no pom.xml, please, and report if color is ok or not? If not ok, please send me in private the output: we'll dig more in details later. If it is ok, that means that you pom.xml causes conflict with JAnsi at some level: I'll need your build file (in private) to investigate. Regards, Hervé Le dimanche 27 août 2017, 03:07:28 CEST Friedman, Jacob a écrit : > Hi Herve, > > A little background about myself. I am a Scrum Master on a team that does > not have a QA resource for the product I'm working on. I undertook > regression testing manually and decided to teach myself how to code > Automated Selenium Regression Tests in Java. I'm VERY new to this, so > doing a ton of learning. I've set up a maven project that has a Base Test > Class, page object classes, and Test Classes that reference base. I can > use a data.properties file to define if I want to run my tests locally or > on a virtual machine called Sauce labs. > > Given my limited knowledge, I do not fully understand what you'd like me to > do in your below message. Do I just need to add the jansi reference from > the POM file on the github link you referenced to my project's POM file? > If more, can you guide a little bit? Do I unzip the file from git hub and > add those files to my project structure? > > Thanks, > Jake > > > Jacob Friedman, PMP, PMI-ACP | Optum > Scrum Master, Optum Technology > > 131 Morristown Rd, Basking Ridge, NJ 07920 > T +1 973-348-1521 > jacob.fried...@optum.com > www.optum.com > > > -Original Message- > From: Hervé BOUTEMY [mailto:herve.bout...@free.fr] > Sent: Friday, August 25, 2017 2:42 AM > To: Maven Users List > Subject: Re: 1;34mINFO[m] formatting on console output > > then JAnsi http://fusesource.github.io/jansi/ should detect this OS and do > the magic to interpret these ANSI escape codes > > This is tested by many people on many Windows 7 machines: I don't know what > is specific to yours > > I opened a PR to JAnsi a few months ago https://github.com/fusesource/jansi/ > pull/88 to have a test utility built into JAnsi library to test its > features independently of any integration (like Maven integrates it): but > the PR is not yet merged. It's sad, since it's really to diagnose case like > yours (when you report issues to Maven that are more probably tied to > JAnsi) > > Can you build this JAnsi snapshot with the PR and test, please? > > Regards, > > Hervé > > Le jeudi 24 août 2017, 18:21:01 CEST Stephen Cobb a écrit : > > That's what I have. I got a GO ProBook 7. It's got an Intel I-5 and a > > 250 STATA HD but 4 GB RAM is all but it's not that slow. Runs at about 2.3 > > GH. This is a PHO Utility right? > > > > On Aug 24, 2017 6:11 PM, "Friedman, Jacob" > > wrote: > > > > Hi Herve, > > > > I'm using Windows 7 64 Bit machine. > > > > I'm using cmd to get to the console. > > > > I'm using maven 3.5 > > > > Thanks, > > Jake > > > > > > > > Jacob Friedman, PMP, PMI-ACP | Optum > > Scrum Master, Optum Technology > > > > 131 Morristown Rd, Basking Ridge, NJ 07920 > > T +1 973-348-1521 > > jacob.fried...@optum.com > > www.optum.com > > > > > > -Original Message- > > From: Hervé BOUTEMY [mailto:herve.bout...@free.fr] > > Sent: Thursday, August 24, 2017 5:43 PM > > To: Maven Users List > > Subject: Re: 1;34mINFO[m] formatting on console output > > > > can you give info on Maven version and OS used? > > And if you are on Windows, which command line you're using? > > > > there is no reason to stop working: > > - any Unix supports these ANSI escape codes natively > > - we use JAnsi to add support on Windows > > > > Regards, > > > > Hervé > > > > Le jeudi 24 août 2017, 20:54:26 CEST Friedman, Jacob a écrit : > > > Howdy, > > > > > > Previously, maven output for my project yielded some slight > > > colorization to easily see test run results, errors etc. The other > > > day it started producing some funky formatting that looked similar to: > > > > > > 1;34mINFO[m] on many lines. > > > > > > I did some research and I see there was a recent maven release that > > > actually added some more colorization. I learned via a google search > > > i can use 'mvn test -B' to remove the aforementioned formatting, but > > > the output is black and white. How do I configure it so that it runs > > > in color per the samples videos I've seen online about the new release. > > > > > > Here's my POM file text in case that helps troubleshoot: > > > http://maven.apache.org/POM/4.0.0"; > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > > > http://maven.apache.org/maven-v4_0_0.xsd";> > > > 4.0.0 > > > > > >
