On Mon, 04 Jul 2016 19:55:27 +0200, Christian Schulte <[email protected]>
wrote:
Am 07/04/16 um 19:42 schrieb Manfred Moser:
To be honest I dont think it would be a problem if it were in core.
Easier to understand for plugin developers potentially
and a good motivation for users to upgrade as well as plugin developers
to move forward..
Move everything depending on toolchains from maven-shared-utils into
maven-core? Sounds strange that maven-shared-utils depends on
maven-core. Either something in maven-core should not be part of
maven-core or something in maven-shared-utils should not be part of
maven-shared-utils.
Regards,
I was wondering why Toolchain was required by maven-shared-utils. There's
a JavaTool wrapper for easy usage of Toolchain. Every plugin wrapping
something in the jdk/bin or jre/bin might want to use this, so yes it is
shared.
However, IMO it is too Java specific and I still see Maven as a language
independent tool.
I have this idea of language-extensions, and this would be something to
move to such extension.
The logic of MavenProject.classpath should move to this extension too,
since it is Java specific. And we have a location were we can specify the
Java9 modulePaths as well.
Now back to the Messaging-Utils. The question is: do we want to say to all
maven-plugin developers that if they want colors in their output, set the
Maven prerequisite to 3.4.0? Plugin development will be easy, but Maven
users are required to install a newer version of Maven.
If we want to please the users more compared to developers AND we want to
let Maven core use the same code, then I'd go for the separate,
single-class (?) jar. It is the most flexible solution.
thanks,
Robert
ps. can we get rid of the argument-less methods? With the
logWithStyle(Object) you can do exactly the same things, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
