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