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
