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

[Robert Scholte]

On Thu, 23 Jun 2016 21:27:57 +0200, Hervé BOUTEMY <herve.bout...@free.fr>  
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 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


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