Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-25 Thread Hervé BOUTEMY 
Le jeudi 23 juin 2016 21:39:02 Robert Scholte a écrit :
> >> > - move code to maven-shared-utils: the drawback here is to add jansi
> >> > dependency to the artifact.
> >> 
> >> That would pull in maven-shared-utils next to plexus-utils, which are
> >> comparable and shouldn't be mixed due to classloading issues as seen in
> >> the past.
> > 
> > classloading issues between maven-shared-utils and plexus-utils? how can
> > 2
> > separate pieces of code interfere?
> > 
> >> > Any preference? Any other idea?
> >> 
> >> So it seems like it should be a very small standalone module. It should
> >> also pick up jansi from the classpath, jansi shouldn't be a direct
> >> dependency, but a provided or optional one.
> > 
> > hiding JAnsi will require more code, but looks feasible
> > 
> > I'd really like to understand why maven-shared-utils would cause issues
> 
> IIRC https://issues.apache.org/jira/browse/MNG-2892 is the key issue here.
> However, nowadays plexus-utils is not shaded anymore, it is just another
> dependency. Not sure where everything changed again, but I think it is
> best that Maven uses plexus-utils, plugins use maven-shared-utils.
> AFAIK M2.0.5 was a quite a bad release due to the usage of different
> versions of plexus-utils between maven-core and the plugins.
now, Plexus XPP3 classes are exposed through META-INF/maven/extensions.xml in 
maven-core

adding maven-shared-utils as a dependency won't make anything visible from 
plugins

For the moment, I'll move code to maven-shared-utils: we'll see later if we 
want to move it further...

Regards,

Hervé

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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-23 Thread Robert Scholte 
On Thu, 23 Jun 2016 21:27:57 +0200, Hervé BOUTEMY   
wrote:



Le jeudi 23 juin 2016 19:54:58 Robert Scholte a écrit :

> thinking more about it.
> Yes, having Maven core depending on maven-project-utils, which  
dependes

> on
> maven-core, will cause issues: I already had to add an exclusion to
> avoid a
> build tests failure...
>
> Where to put AnsiUtils?
> I see multiple options:
> - a new Maven core module: the drawback I see is that it will be a  
really

> small artifact...

A separate module or part of an existing module?

a *new* module


This would mean that
plugins would require a newer version of maven dependencies just for
logging.

it would require just this module, not every Maven core dependencies


This doesn't seem to be correct.
one concrete drawback I see is that Maven core requires Java 7, where  
most

plugins are still with Java 6.


> - move code to maven-plugin-api: it would be consistent. The drawback
> here is
> that we'll need to shade it into plugins to avoid Maven 3.4.0  
requirement


Nope, see previous comment. Plugins should compile with lowest maven
dependencies.

> - move code to maven-shared-utils: the drawback here is to add jansi
> dependency to the artifact.

That would pull in maven-shared-utils next to plexus-utils, which are
comparable and shouldn't be mixed due to classloading issues as seen in
the past.
classloading issues between maven-shared-utils and plexus-utils? how can  
2

separate pieces of code interfere?



> Any preference? Any other idea?

So it seems like it should be a very small standalone module. It should
also pick up jansi from the classpath, jansi shouldn't be a direct
dependency, but a provided or optional one.

hiding JAnsi will require more code, but looks feasible

I'd really like to understand why maven-shared-utils would cause issues


IIRC https://issues.apache.org/jira/browse/MNG-2892 is the key issue here.  
However, nowadays plexus-utils is not shaded anymore, it is just another  
dependency. Not sure where everything changed again, but I think it is  
best that Maven uses plexus-utils, plugins use maven-shared-utils.
AFAIK M2.0.5 was a quite a bad release due to the usage of different  
versions of plexus-utils between maven-core and the plugins.


Robert



Regards,

Hervé



that's the approach I would go for.

Robert

> Regards,
>
> Hervé
>
> Le mardi 21 juin 2016 08:33:48 Hervé BOUTEMY a écrit :
>> Le lundi 20 juin 2016 20:33:26 Christian Schulte a écrit :
>> > Am 06/20/16 um 19:15 schrieb Robert Scholte:
>> > > Hi Christian,
>> > >
>> > > when I introduced the maven-project-utils I had a library in mind
>>
>> with
>>
>> > > helpful MavenProject related methods for multiple plugins. For  
that

>> > > reason
>> > > I didn't make it part of the Maven distribution.
>> > > With this commit the library suddenly is required.
>> > > Instead I think you should use plain JAnsi or we should extract  
the

>> > > logging part from the library.
>> >
>> > Hervé committed this and is currently working on it.
>>
>> yes, I'm the culprit here :)
>>
>> > Colours disappeard
>> > on current 'master' here.
>>
>> same for me
>> the code that checks for Maven version before activating colors does  
not

>> work when run in Maven core...
>> I just activated color explicitely in Maven core, but since this code
>> will
>> also be responsible for custom colors injection (later, I still  
didn't

>> have
>> time to implement it), I don't think this will be the right answer
>>
>> > I am not sure using plain JAnsi is the way to
>> > go. I would prefer having some kind of facade people can use which
>> > allows us to replace JAnsi without the need to touch any code.
>>
>> replacing JAnsi probably won't happen
>> But this API is responsible for consistent and configable colors
>>
>> > Currently
>> > JAnsi still is on the compile classpath. That's like using classes  
of

>> > some 'com.sun' package. We have no compiler warning people about
>>
>> direct
>>
>> > use of JAnsi. So it better disappears from any compile classpath  
to be

>> > safe. Allowing direct use of JAnsi we also run into that 'everyone
>>
>> uses
>>
>> > colours in an inconsistent way' - like someone else already said -  
we

>> > will get that rainbow console effect sometime in the future (when
>>
>> people
>>
>> > start providing colours in theire plugins).
>>
>> this is where Java 9 modules would help...
>> For the moment, I don't think hiding JAnsi is a priority: explaining  
the

>> Maven color logging messages API is more important.
>>
>> > The API Hervé is working on
>> > looks promising. Maybe we make that a class in 'maven-core' instead
>>
>> of a
>>
>> > part of some library. Plugins already add 'maven-core' to theire
>>
>> compile
>>
>> > classpath.
>>
>> if we do that, doing plugins working on every Maven version will  
require

>> reflection: that's hard
>>
>> > That could pull in some kind of Ansi Logging helper class as
>> > well. No need for a separate

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-23 Thread Hervé BOUTEMY 
Le jeudi 23 juin 2016 19:54:58 Robert Scholte a écrit :
> > thinking more about it.
> > Yes, having Maven core depending on maven-project-utils, which dependes
> > on
> > maven-core, will cause issues: I already had to add an exclusion to
> > avoid a
> > build tests failure...
> > 
> > Where to put AnsiUtils?
> > I see multiple options:
> > - a new Maven core module: the drawback I see is that it will be a really
> > small artifact...
> 
> A separate module or part of an existing module?
a *new* module

> This would mean that
> plugins would require a newer version of maven dependencies just for
> logging.
it would require just this module, not every Maven core dependencies

> This doesn't seem to be correct.
one concrete drawback I see is that Maven core requires Java 7, where most 
plugins are still with Java 6.
> 
> > - move code to maven-plugin-api: it would be consistent. The drawback
> > here is
> > that we'll need to shade it into plugins to avoid Maven 3.4.0 requirement
> 
> Nope, see previous comment. Plugins should compile with lowest maven
> dependencies.
> 
> > - move code to maven-shared-utils: the drawback here is to add jansi
> > dependency to the artifact.
> 
> That would pull in maven-shared-utils next to plexus-utils, which are
> comparable and shouldn't be mixed due to classloading issues as seen in
> the past.
classloading issues between maven-shared-utils and plexus-utils? how can 2 
separate pieces of code interfere?

> 
> > Any preference? Any other idea?
> 
> So it seems like it should be a very small standalone module. It should
> also pick up jansi from the classpath, jansi shouldn't be a direct
> dependency, but a provided or optional one.
hiding JAnsi will require more code, but looks feasible

I'd really like to understand why maven-shared-utils would cause issues

Regards,

Hervé

> 
> that's the approach I would go for.
> 
> Robert
> 
> > Regards,
> > 
> > Hervé
> > 
> > Le mardi 21 juin 2016 08:33:48 Hervé BOUTEMY a écrit :
> >> Le lundi 20 juin 2016 20:33:26 Christian Schulte a écrit :
> >> > Am 06/20/16 um 19:15 schrieb Robert Scholte:
> >> > > Hi Christian,
> >> > > 
> >> > > when I introduced the maven-project-utils I had a library in mind
> >> 
> >> with
> >> 
> >> > > helpful MavenProject related methods for multiple plugins. For that
> >> > > reason
> >> > > I didn't make it part of the Maven distribution.
> >> > > With this commit the library suddenly is required.
> >> > > Instead I think you should use plain JAnsi or we should extract the
> >> > > logging part from the library.
> >> > 
> >> > Hervé committed this and is currently working on it.
> >> 
> >> yes, I'm the culprit here :)
> >> 
> >> > Colours disappeard
> >> > on current 'master' here.
> >> 
> >> same for me
> >> the code that checks for Maven version before activating colors does not
> >> work when run in Maven core...
> >> I just activated color explicitely in Maven core, but since this code
> >> will
> >> also be responsible for custom colors injection (later, I still didn't
> >> have
> >> time to implement it), I don't think this will be the right answer
> >> 
> >> > I am not sure using plain JAnsi is the way to
> >> > go. I would prefer having some kind of facade people can use which
> >> > allows us to replace JAnsi without the need to touch any code.
> >> 
> >> replacing JAnsi probably won't happen
> >> But this API is responsible for consistent and configable colors
> >> 
> >> > Currently
> >> > JAnsi still is on the compile classpath. That's like using classes of
> >> > some 'com.sun' package. We have no compiler warning people about
> >> 
> >> direct
> >> 
> >> > use of JAnsi. So it better disappears from any compile classpath to be
> >> > safe. Allowing direct use of JAnsi we also run into that 'everyone
> >> 
> >> uses
> >> 
> >> > colours in an inconsistent way' - like someone else already said - we
> >> > will get that rainbow console effect sometime in the future (when
> >> 
> >> people
> >> 
> >> > start providing colours in theire plugins).
> >> 
> >> this is where Java 9 modules would help...
> >> For the moment, I don't think hiding JAnsi is a priority: explaining the
> >> Maven color logging messages API is more important.
> >> 
> >> > The API Hervé is working on
> >> > looks promising. Maybe we make that a class in 'maven-core' instead
> >> 
> >> of a
> >> 
> >> > part of some library. Plugins already add 'maven-core' to theire
> >> 
> >> compile
> >> 
> >> > classpath.
> >> 
> >> if we do that, doing plugins working on every Maven version will require
> >> reflection: that's hard
> >> 
> >> > That could pull in some kind of Ansi Logging helper class as
> >> > well. No need for a separate library, I think.
> >> 
> >> If using maven-project-utils in core is not ok, yes, we'll need a
> >> separate
> >> library
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> > Regards,
> >> 
> >> -
> >> To unsubscribe, e-mail:

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-23 Thread Robert Scholte 

thinking more about it.
Yes, having Maven core depending on maven-project-utils, which dependes  
on
maven-core, will cause issues: I already had to add an exclusion to  
avoid a

build tests failure...

Where to put AnsiUtils?
I see multiple options:
- a new Maven core module: the drawback I see is that it will be a really
small artifact...


A separate module or part of an existing module? This would mean that  
plugins would require a newer version of maven dependencies just for  
logging. This doesn't seem to be correct.


- move code to maven-plugin-api: it would be consistent. The drawback  
here is

that we'll need to shade it into plugins to avoid Maven 3.4.0 requirement


Nope, see previous comment. Plugins should compile with lowest maven  
dependencies.



- move code to maven-shared-utils: the drawback here is to add jansi
dependency to the artifact.


That would pull in maven-shared-utils next to plexus-utils, which are  
comparable and shouldn't be mixed due to classloading issues as seen in  
the past.




Any preference? Any other idea?


So it seems like it should be a very small standalone module. It should  
also pick up jansi from the classpath, jansi shouldn't be a direct  
dependency, but a provided or optional one.


that's the approach I would go for.

Robert



Regards,

Hervé

Le mardi 21 juin 2016 08:33:48 Hervé BOUTEMY a écrit :

Le lundi 20 juin 2016 20:33:26 Christian Schulte a écrit :
> Am 06/20/16 um 19:15 schrieb Robert Scholte:
> > Hi Christian,
> >
> > when I introduced the maven-project-utils I had a library in mind  
with

> > helpful MavenProject related methods for multiple plugins. For that
> > reason
> > I didn't make it part of the Maven distribution.
> > With this commit the library suddenly is required.
> > Instead I think you should use plain JAnsi or we should extract the
> > logging part from the library.
>
> Hervé committed this and is currently working on it.

yes, I'm the culprit here :)

> Colours disappeard
> on current 'master' here.

same for me
the code that checks for Maven version before activating colors does not
work when run in Maven core...
I just activated color explicitely in Maven core, but since this code  
will
also be responsible for custom colors injection (later, I still didn't  
have

time to implement it), I don't think this will be the right answer

> I am not sure using plain JAnsi is the way to
> go. I would prefer having some kind of facade people can use which
> allows us to replace JAnsi without the need to touch any code.

replacing JAnsi probably won't happen
But this API is responsible for consistent and configable colors

> Currently
> JAnsi still is on the compile classpath. That's like using classes of
> some 'com.sun' package. We have no compiler warning people about  
direct

> use of JAnsi. So it better disappears from any compile classpath to be
> safe. Allowing direct use of JAnsi we also run into that 'everyone  
uses

> colours in an inconsistent way' - like someone else already said - we
> will get that rainbow console effect sometime in the future (when  
people

> start providing colours in theire plugins).

this is where Java 9 modules would help...
For the moment, I don't think hiding JAnsi is a priority: explaining the
Maven color logging messages API is more important.

> The API Hervé is working on
> looks promising. Maybe we make that a class in 'maven-core' instead  
of a
> part of some library. Plugins already add 'maven-core' to theire  
compile

> classpath.

if we do that, doing plugins working on every Maven version will require
reflection: that's hard

> That could pull in some kind of Ansi Logging helper class as
> well. No need for a separate library, I think.

If using maven-project-utils in core is not ok, yes, we'll need a  
separate

library

Regards,

Hervé

> Regards,

-
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


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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-22 Thread Christian Schulte 
Am 06/22/16 um 23:41 schrieb Hervé BOUTEMY:
> - move code to maven-shared-utils: the drawback here is to add jansi 
> dependency to the artifact.

+1

Just flag it 'optional' so that people not using the Ansi related
classes do not get it on the classpath and do not need to exclude it
everywhere. While at it, the jsr305 dependency could also be flagged
'optional' instead of using scope 'provided'.


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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-22 Thread Hervé BOUTEMY 
thinking more about it.
Yes, having Maven core depending on maven-project-utils, which dependes on 
maven-core, will cause issues: I already had to add an exclusion to avoid a 
build tests failure...

Where to put AnsiUtils?
I see multiple options:
- a new Maven core module: the drawback I see is that it will be a really 
small artifact...
- move code to maven-plugin-api: it would be consistent. The drawback here is 
that we'll need to shade it into plugins to avoid Maven 3.4.0 requirement
- move code to maven-shared-utils: the drawback here is to add jansi 
dependency to the artifact.

Any preference? Any other idea?

Regards,

Hervé

Le mardi 21 juin 2016 08:33:48 Hervé BOUTEMY a écrit :
> Le lundi 20 juin 2016 20:33:26 Christian Schulte a écrit :
> > Am 06/20/16 um 19:15 schrieb Robert Scholte:
> > > Hi Christian,
> > > 
> > > when I introduced the maven-project-utils I had a library in mind with
> > > helpful MavenProject related methods for multiple plugins. For that
> > > reason
> > > I didn't make it part of the Maven distribution.
> > > With this commit the library suddenly is required.
> > > Instead I think you should use plain JAnsi or we should extract the
> > > logging part from the library.
> > 
> > Hervé committed this and is currently working on it.
> 
> yes, I'm the culprit here :)
> 
> > Colours disappeard
> > on current 'master' here.
> 
> same for me
> the code that checks for Maven version before activating colors does not
> work when run in Maven core...
> I just activated color explicitely in Maven core, but since this code will
> also be responsible for custom colors injection (later, I still didn't have
> time to implement it), I don't think this will be the right answer
> 
> > I am not sure using plain JAnsi is the way to
> > go. I would prefer having some kind of facade people can use which
> > allows us to replace JAnsi without the need to touch any code.
> 
> replacing JAnsi probably won't happen
> But this API is responsible for consistent and configable colors
> 
> > Currently
> > JAnsi still is on the compile classpath. That's like using classes of
> > some 'com.sun' package. We have no compiler warning people about direct
> > use of JAnsi. So it better disappears from any compile classpath to be
> > safe. Allowing direct use of JAnsi we also run into that 'everyone uses
> > colours in an inconsistent way' - like someone else already said - we
> > will get that rainbow console effect sometime in the future (when people
> > start providing colours in theire plugins).
> 
> this is where Java 9 modules would help...
> For the moment, I don't think hiding JAnsi is a priority: explaining the
> Maven color logging messages API is more important.
> 
> > The API Hervé is working on
> > looks promising. Maybe we make that a class in 'maven-core' instead of a
> > part of some library. Plugins already add 'maven-core' to theire compile
> > classpath.
> 
> if we do that, doing plugins working on every Maven version will require
> reflection: that's hard
> 
> > That could pull in some kind of Ansi Logging helper class as
> > well. No need for a separate library, I think.
> 
> If using maven-project-utils in core is not ok, yes, we'll need a separate
> library
> 
> Regards,
> 
> Hervé
> 
> > Regards,
> 
> -
> 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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-21 Thread Hervé BOUTEMY 
Le lundi 20 juin 2016 20:33:26 Christian Schulte a écrit :
> Am 06/20/16 um 19:15 schrieb Robert Scholte:
> > Hi Christian,
> > 
> > when I introduced the maven-project-utils I had a library in mind with
> > helpful MavenProject related methods for multiple plugins. For that reason
> > I didn't make it part of the Maven distribution.
> > With this commit the library suddenly is required.
> > Instead I think you should use plain JAnsi or we should extract the
> > logging part from the library.
> 
> Hervé committed this and is currently working on it.
yes, I'm the culprit here :)

> Colours disappeard
> on current 'master' here.
same for me
the code that checks for Maven version before activating colors does not work 
when run in Maven core...
I just activated color explicitely in Maven core, but since this code will 
also be responsible for custom colors injection (later, I still didn't have 
time to implement it), I don't think this will be the right answer

> I am not sure using plain JAnsi is the way to
> go. I would prefer having some kind of facade people can use which
> allows us to replace JAnsi without the need to touch any code.
replacing JAnsi probably won't happen
But this API is responsible for consistent and configable colors

> Currently
> JAnsi still is on the compile classpath. That's like using classes of
> some 'com.sun' package. We have no compiler warning people about direct
> use of JAnsi. So it better disappears from any compile classpath to be
> safe. Allowing direct use of JAnsi we also run into that 'everyone uses
> colours in an inconsistent way' - like someone else already said - we
> will get that rainbow console effect sometime in the future (when people
> start providing colours in theire plugins).
this is where Java 9 modules would help...
For the moment, I don't think hiding JAnsi is a priority: explaining the Maven 
color logging messages API is more important.

> The API Hervé is working on
> looks promising. Maybe we make that a class in 'maven-core' instead of a
> part of some library. Plugins already add 'maven-core' to theire compile
> classpath.
if we do that, doing plugins working on every Maven version will require 
reflection: that's hard

> That could pull in some kind of Ansi Logging helper class as
> well. No need for a separate library, I think.
If using maven-project-utils in core is not ok, yes, we'll need a separate 
library

Regards,

Hervé

> 
> Regards,


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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-20 Thread Christian Schulte 
Am 06/20/16 um 19:15 schrieb Robert Scholte:
> Hi Christian,
> 
> when I introduced the maven-project-utils I had a library in mind with  
> helpful MavenProject related methods for multiple plugins. For that reason  
> I didn't make it part of the Maven distribution.
> With this commit the library suddenly is required.
> Instead I think you should use plain JAnsi or we should extract the  
> logging part from the library.
> 

Hervé committed this and is currently working on it. Colours disappeard
on current 'master' here. I am not sure using plain JAnsi is the way to
go. I would prefer having some kind of facade people can use which
allows us to replace JAnsi without the need to touch any code. Currently
JAnsi still is on the compile classpath. That's like using classes of
some 'com.sun' package. We have no compiler warning people about direct
use of JAnsi. So it better disappears from any compile classpath to be
safe. Allowing direct use of JAnsi we also run into that 'everyone uses
colours in an inconsistent way' - like someone else already said - we
will get that rainbow console effect sometime in the future (when people
start providing colours in theire plugins). The API Hervé is working on
looks promising. Maybe we make that a class in 'maven-core' instead of a
part of some library. Plugins already add 'maven-core' to theire compile
classpath. That could pull in some kind of Ansi Logging helper class as
well. No need for a separate library, I think.

Regards,
-- 
Christian


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

Re: [2/5] maven git commit: [MNG-3507] use AnsiUtils API to use colors consistently

2016-06-20 Thread Robert Scholte 

Hi Christian,

when I introduced the maven-project-utils I had a library in mind with  
helpful MavenProject related methods for multiple plugins. For that reason  
I didn't make it part of the Maven distribution.

With this commit the library suddenly is required.
Instead I think you should use plain JAnsi or we should extract the  
logging part from the library.


thanks,
Robert


On Mon, 20 Jun 2016 01:15:05 +0200,  wrote:


[MNG-3507] use AnsiUtils API to use colors consistently

Project: http://git-wip-us.apache.org/repos/asf/maven/repo
Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/402ce4c3
Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/402ce4c3
Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/402ce4c3

Branch: refs/heads/MNG-6006
Commit: 402ce4c3cd1e970d2d4186aa6fc3e10c612241fb
Parents: 162c740
Author: Hervé Boutemy 
Authored: Mon Jun 20 00:35:17 2016 +0200
Committer: Hervé Boutemy 
Committed: Mon Jun 20 00:35:41 2016 +0200

--
 maven-core/pom.xml  | 10 +++-
 .../lifecycle/LifecycleExecutionException.java  | 19 
 maven-embedder/pom.xml  |  4 +-
 .../org/apache/maven/cli/CLIReportingUtils.java |  4 +-
 .../java/org/apache/maven/cli/MavenCli.java | 21 
 .../maven/cli/event/ExecutionEventLogger.java   | 50  
++--

 .../cli/logging/impl/gossip/ColorRenderer.java  | 26 +-
 pom.xml |  6 +--
 8 files changed, 72 insertions(+), 68 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/maven/blob/402ce4c3/maven-core/pom.xml
--
diff --git a/maven-core/pom.xml b/maven-core/pom.xml
index cc648be..f03eead 100644
--- a/maven-core/pom.xml
+++ b/maven-core/pom.xml
@@ -85,8 +85,14 @@ under the License.
   aether-util
 
 
-  org.fusesource.jansi
-  jansi
+  org.apache.maven.shared
+  maven-project-utils
+  
+
+  org.apache.maven
+  maven-core
+
+  
 
 
 

http://git-wip-us.apache.org/repos/asf/maven/blob/402ce4c3/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionException.java
--
diff --git  
a/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionException.java  
b/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionException.java

index fd4bca0..5645abd 100644
---  
a/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionException.java
+++  
b/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionException.java

@@ -19,11 +19,11 @@ package org.apache.maven.lifecycle;
  * under the License.
  */
-import static org.fusesource.jansi.Ansi.ansi;
+import static org.apache.maven.shared.project.utils.AnsiUtils.ansi;
import org.apache.maven.plugin.MojoExecution;
 import org.apache.maven.project.MavenProject;
-import org.fusesource.jansi.Ansi;
+import org.apache.maven.shared.project.utils.AnsiUtils;
/**
  * @author mailto:ja...@maven.org;>Jason van Zyl
@@ -78,26 +78,27 @@ public class LifecycleExecutionException
private static String createMessage( MojoExecution execution,  
MavenProject project, Throwable cause )

 {
-Ansi buffer = ansi( /*256*/ );
+AnsiUtils buffer = ansi( 256 );
-buffer.a( "Failed to execute goal" ).reset();
+buffer.a( "Failed to execute goal" );
if ( execution != null )
 {
-buffer.a( ' ' ).a( execution.getGroupId() ).a( ':'  
).fgGreen().a( execution.getArtifactId() );
-buffer.a( ':' ).a( execution.getVersion() ).a( ':' ).a(  
execution.getGoal() ).reset();
-buffer.bold().a( " (" ).a( execution.getExecutionId() ).a(  
')' ).reset();

+buffer.a( ' ' ).a( execution.getGroupId() ).a( ':' );
+buffer.mojo().a( execution.getArtifactId() ).a( ':' );
+buffer.a( execution.getVersion() ).a( ':' ).a(  
execution.getGoal() ).reset();
+buffer.strong().a( " (" ).a( execution.getExecutionId()  
).a( ')' ).reset();

 }
if ( project != null )
 {
 buffer.a( " on project " );
-buffer.fgCyan().a( project.getArtifactId() ).reset();
+buffer.project( project.getArtifactId() );
 }
if ( cause != null )
 {
-buffer.a( ": " ).bold().fgRed().a( cause.getMessage()  
).reset();

+buffer.a( ": " ).failure( cause.getMessage() );
 }
return buffer.toString();

http://git-wip-us.apache.org/repos/asf/maven/blob/402ce4c3/maven-embedder/pom.xml
--
diff --git