Re: MNG-5567: Zips on classpath

Am 08/15/16 um 19:57 schrieb Paul Benedict: > I hear different opinions on how to move forward. Robert believes it's > possible with MPLUGIN-305 (is that really the right ticket #?), but you > have doubts for the 3.x series. Which shall it be for 3.4? The 'import' scope was introduced in a patch

Re: maven git commit: [MNG-5971] Imported dependencies should be available to inheritance processing

asf/maven/tree/059b9ab3 > Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/059b9ab3 > > Branch: refs/heads/master > Commit: 059b9ab3028360b011c1539caa4c40d033b9143f > Parents: 814b516 > Author: Christian Schulte <schu...@apache.org> > Authored: Sat Aug 13 22:58:4

Dependency management import conflict resolution

Hi, currently the 'DefaultDependencyManagementImporter' does some kind of conflict resolution by only importing dependencies not already declared in the model. When working on MNG-5971, I introduced a warning to make users aware of what is happening behind the scenes. I was asked to revert those

Re: Promoting Maven 'master'

Am 08/13/16 um 03:11 schrieb Christian Schulte: > Hi, > > I don't know if something like this has been discussed before. Is there > a reason we are not asking users to use Maven snapshots on theire CI > systems? > > We are currently asking users for testing snapshot

Promoting Maven 'master'

Hi, I don't know if something like this has been discussed before. Is there a reason we are not asking users to use Maven snapshots on theire CI systems? We are currently asking users for testing snapshots manually. They need to download something and run some builds manually. For users having a

Re: opinions on MJAVADOC-451

Am 06.08.2016 um 11:35 schrieb Robert Scholte: fooled. So it must be javadoc:fix + compiler:compile + scm:commit. The Maven-way would be a lifecycle for things like that, right? Like the clean or site lifecycle. A general purpose "manage source code" lifecycle with phases like

Re: Maven Core Command Line

Am 08/06/16 um 16:08 schrieb Karl Heinz Marbaise: > So the question is WDYT ? +1 Consistency. Almost all properties can be overridden from the command line. I see no reason why 'maven.config' should not be overridable from the command line as well. Regards, -- Christian

Re: opinions on MJAVADOC-451

Am 08/06/16 um 11:35 schrieb Robert Scholte: > I consider the javadoc:fix goal in the same range as the release:prepare > release:perform combination (why as is everything executed twice) and > cobertura-maven-plugin (why are the tests executed twice) and the fix-goal > is probably even

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

Am 08/06/16 um 05:15 schrieb Christian Schulte: > It just takes the highest version the version range resolver returns and uses > that or fails if nothing like that is available. If using version range syntax. - To unsub

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

Am 08/06/16 um 02:04 schrieb Fred Cooke: > A parent, I thought, used to be equivalent to [], ie, hard requirement. A > dependency without [] is NOT a hard requirement, simply advisory. So yeah, > they're different, or were. I wonder what semantics the ranged parents > behaviour has for a simple

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

Am 08/05/16 um 16:10 schrieb Thiebaud, Christophe: > ... oh ... I was 200% sure that parent did not allow a version range ... Introduced in Maven 3.2.2. Broken since a few releases. Fixed in 3.4.0-SNAPSHOT. > > I tried, -> BUILD SUCCESS. > > Hourah, and thanks. > > Let see now if this option

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

f-lib:jar:0.0.1-SNAPSHOT: Could not > find artifact net.aequologica.iroif:iroif-parent:pom:0.0.1-SNAPSHOT in > local_nexus (http://localhost:1082/nexus/content/groups/public/) -> [Help 1] > [ERROR] > > Also, the -U (--update snapshots) parameter makes no difference, as a new, &g

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

Am 08/05/16 um 13:27 schrieb Thiebaud, Christophe: > Reading Aether documentation : > > https://wiki.eclipse.org/Aether/Transitive_Dependency_Resolution > > looks that aether has been thought to manage this kind of issue: > > « For each direct dependency, a dependency selector is given a

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/05/16 um 01:21 schrieb Gary Gregory: > On Thu, Aug 4, 2016 at 3:24 PM, Christian Schulte <c...@schulte.it> wrote: > >> Am 08/05/16 um 00:15 schrieb Gary Gregory: >>> But here you would just tell the manager: "I want to use Maven" as >> opposed &

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/05/16 um 00:15 schrieb Gary Gregory: > But here you would just tell the manager: "I want to use Maven" as opposed > to "I want to use Ant and Ivy". So lets rename Maven. We need a name sounding cool to management. Just so that we do not need to discuss why we want to use it...something

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/04/16 um 23:08 schrieb Jason van Zyl: > When in doubt I have tried Velocity, Turbine, Plexus, Nexus, Aether and > Tycho. None of them very useful for people to understand what they actually > do. I think I’m done with catchy names. I’m old. There is one quote I can make here. Working on a

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/04/16 um 22:22 schrieb Jason van Zyl: > These are all discussions about abstractions we had when talking about Maven > 1.x, so let me save you the circuitous route back to the fact that users > don’t care about having an abstraction that lets them store artifacts as > blobs in any

Re: [DISCUSSION] finishing Aether import: help find a new name

If I wanted to store my artifacts in a database instead of putting files into some well-known locations. Can I write an implementation of 'RepositorySystem' which allows me to do that? No. It's way too file-system based. A database would give me a blob. A path or a filename is meaningless for the

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/04/16 um 18:27 schrieb Robert Scholte: > It is all about Maven coordinates: groupId + artifactId + version + > extension ( + classifier) > This all together results in a URL to a repository. In case of remote > repositories these work both with M1 and M2 repository layouts (yes, the >

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/04/16 um 18:44 schrieb Paul Benedict: > In my own experience regarding the difficulty of naming something, it has > always indicated the codebase is too big and multi-functional. > > Thus, there are two paths to take: > 1) Slap a brand name on it because no descriptive name can succinctly >

Re: project having a dependency with a version range fails building when parent pom of dependency is evicted from remote repo

Am 08/04/16 um 12:36 schrieb Thiebaud, Christophe: > I understand that pom file of lib 0.0.1-SNAPSHOT dependency cannot be built > because of missing (evicted) parent 0.0.1-SNAPSHOT. > > The point is that failing to build lib 0.0.1-SNAPSHOT pom file should not > result in a app failed build, as

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/04/16 um 02:34 schrieb Ralph Goers: > I much prefer MARS, especially if you can come up with corresponding wordplay > for VENUS… ;-) Better than 'resolver'. > > Seriously, the overlap with Java ARchive is bound to be confusing, and might > even make people think that the component has

Re: [DISCUSSION] finishing Aether import: help find a new name

It's really all about JARs... "Java Artifact Repository Specification" JARS Happenstance. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSSION] finishing Aether import: help find a new name

Guys. Just because it fits perfectly the Java universe. "Java Artifact Repository Specification". JARS Regards, -- Christian Am 04.08.2016 um 00:21 schrieb Christian Schulte: Am 08/03/16 um 23:47 schrieb Michael Osipov: I proposed Maven Artifact Universe, but received no respons

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 08/03/16 um 23:47 schrieb Michael Osipov: > I proposed Maven Artifact Universe, but received no response. Pretty close. In the Java universe we got used to talk about JSRs and JEPs and things like that. I am all for something along "Maven Artifact Repository Specification" and corresponding

Re: [DISCUSSION] finishing Aether import: help find a new name

It's just a name - I know. Personally, I disagree with 'resolver'. It's so much more. It also abstracts the transfers/transports etc. It is an abstraction to manage and access a repository (whatever that may mean) of artifacts (whatever that may mean) by employing a special directory structure and

Re: Build failed in Jenkins: core-it-maven-3-win #1240

Am 07/31/16 um 23:46 schrieb Karl Heinz Marbaise: > Hi, > > I think this is related to: > > https://issues.apache.org/jira/browse/INFRA-12232 Failed to install JDK. Exit code=1,603 Ok. Seems related. Thanks. - To

Re: Build failed in Jenkins: core-it-maven-3-win #1240

Am 07/31/16 um 23:27 schrieb Apache Jenkins Server: > Please set the JAVA_HOME variable in your environment to match the > location of your Java installation. Anyone? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: maven git commit: [MNG-6074] Maven should print a warning if no model version has been set in a POM file.

Am 07/31/16 um 12:10 schrieb Robert Scholte: > Hi, > > Really only warn??? Why? I am all for error myself. I wanted to bump the validation severity level in the 'maven-3.x-next' branch to ModelBuildingRequest.VALIDATION_LEVEL_MAVEN_3_1. So in some next 3.x this would have become an error. +1

Re: maven git commit: [MNG-6074] Maven should print a warning if no model version has been set in a POM file.

Am 07/30/16 um 21:12 schrieb Karl Heinz Marbaise: > Hi, > > If I test with this version the build will fail if I don't set the > modelVersion (empty tag) or remove the entry completely... This wasn't intended. Will fix it. It should just warn about it. Thanks.

Model version (was: Re: [DISCUSSION] finishing Aether import: help find a new name)

Am 28.07.2016 um 19:18 schrieb Jason van Zyl: I’m a vehement -1 to changing the artifactIds or structure without a plan. +1 If something does not need to be renamed, then don't rename it. If something needs to be renamed, don't choose some kind of trademarkish name no-one knows what it

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 07/28/16 um 18:21 schrieb Christian Schulte: > Am 07/28/16 um 17:37 schrieb Andreas Sewe: >> Jason van Zyl wrote: >>> It’s all Maven specific, it’s always been Maven specific and that’s >>> unlikely to change after how many years? Even if it can employ >>

Re: [DISCUSSION] finishing Aether import: help find a new name

Am 07/28/16 um 17:37 schrieb Andreas Sewe: > Jason van Zyl wrote: >> It’s all Maven specific, it’s always been Maven specific and that’s >> unlikely to change after how many years? Even if it can employ >> different strategies it’s still the Maven Artifact Resolution API. No >> one is going to use

Re: Build failed in Jenkins: core-it-maven-3-win #1233

Can someone take a look, please? Error: JAVA_HOME is set to an invalid directory. JAVA_HOME = "f:\jenkins\tools\java\latest-1.7-64" Please set the JAVA_HOME variable in your environment to match the location of your Java installation. Am 07/28/16 um 17:27 schrieb Apache Jenkins Server: > See

Re: [jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

Am 07/23/16 um 20:31 schrieb Karl Heinz Marbaise: > Hi Christian, > > Ok first activation problem looks like being solved I've retested this > with my example project...Thanks for fixing that... > > > But what is unclear to me why during the run information from another > profile in

Re: [jira] [Updated] (MNG-6070) Default profile in settings.xml must not use an id possibly already in use.

Am 07/23/16 um 20:31 schrieb Karl Heinz Marbaise: > Hi Christian, > > Ok first activation problem looks like being solved I've retested this > with my example project...Thanks for fixing that... > > > But what is unclear to me why during the run information from another > profile in

Re: Extending Maven to allow scope resolutions for other languages than Java

Am 07/18/16 um 20:39 schrieb Robert Scholte: > On Mon, 18 Jul 2016 15:54:24 +0200, Christian Schulte <c...@schulte.it> > wrote: > >> Am 07/18/16 um 15:02 schrieb Christofer Dutz: >>> Hi, >>> >>> >>> Unfortuantely I wrote this do

Re: maven git commit: [MNG-6069] Migrated to non deprecated API of Commons CLI o Migrated calls of OptionBuilder to Option.builder( ... )...build(). [Forced Update!]

Am 18.07.2016 um 19:59 schrieb Karl Heinz Marbaise: Hi Christian, thanks for the hint... So this means at the moment not to migrate this (or to merge the branch)..simply until a fixed version is available... I am not sure this will ever get fixed. The DefaultParser is based on a short

Re: maven git commit: [MNG-6069] Migrated to non deprecated API of Commons CLI o Migrated calls of OptionBuilder to Option.builder( ... )...build(). [Forced Update!]

Watch out for . The DefaultParser is severely broken regarding long options. See my example at CLI-255. Am 18.07.2016 um 19:49 schrieb khmarba...@apache.org: Repository: maven Updated Branches: refs/heads/MNG-6069 8a89efd9e -> 2b567a7d9 (forced

Re: Extending Maven to allow scope resolutions for other languages than Java

Am 07/18/16 um 15:54 schrieb Christian Schulte: > Am 07/18/16 um 15:02 schrieb Christofer Dutz: >> Hi, >> >> >> Unfortuantely I wrote this down as a Jira ticket, but it seems it wasn't >> created in the end so I'll post this via Email ;-) >> >&g

Re: Extending Maven to allow scope resolutions for other languages than Java

Am 07/18/16 um 15:02 schrieb Christofer Dutz: > Hi, > > > Unfortuantely I wrote this down as a Jira ticket, but it seems it wasn't > created in the end so I'll post this via Email ;-) > > > I am currently working on clean support for Apache Flex build with Maven. > Prior to 3.3.1 non-java

Re: releasing maven-shared-utils 3.1.0 with styled message API

Am 07/17/16 um 12:04 schrieb Robert Scholte: > On Sun, 17 Jul 2016 09:49:39 +0200, Hervé BOUTEMY > wrote: > >> I worked on documentation to finish from my pov my work on this API: >> http://maven.apache.org/shared-archives/maven-shared-utils-LATEST/ >> >> I'd like to

Re: MNG-4800

Am 16.07.2016 um 15:40 schrieb Robert Scholte: I understand that every element has an original scope, but I wonder if it is useful in the tree. I'd say based on the scope(s) you get a certain tree, where scopes don't matter anymore. This would probably also solve the test-scoped issue in the

Re: MNG-4800

Am 07/15/16 um 19:52 schrieb Robert Scholte: > I think you're right. The main issue here is c:1 is the first closest one, > but since the c:2 has compile scope, so should c:1. However, that doesn't > change the scope for transitive dependencies of c:1 > > A bit off-topic: Where is this scope

MNG-4800

Hi, I have a question regarding the description of MNG-4800. Why should the scope of x be compile? The part "instead of ... x:compile". Is this really correct? I see no reason why the scope of x should be updated to compile. It should be kept runtime because it is a runtime dependency of c no

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 07/07/16 um 17:49 schrieb Paul Benedict: > If there is a change that will prevent a build from working, asking for > users@ testing is not the way to do this. The way to do this is to > introduce emit a "warning" first in the next version of Maven, and then > convert it to an "error" in the

Re: [jira] [Created] (MNG-6059) Important use cases not covered, as child.inherit.append.path affects all children

Wouldn't it be better to re-open MNG-5951? Does not make much sense to release 3.4 introducing this when there already is a ticket telling us it does not fit the needs. Regards, Am 07/07/16 um 12:14 schrieb Andreas Sewe (JIRA): > Andreas Sewe created MNG-6059: > -

Re: 3.4.0 SNAPSHOT breaks Log4j build

Am 07/07/16 um 01:23 schrieb Christian Schulte: > And then there is this MNG-NOT-YET-FILED-BY-ME <https://issues.apache.org/jira/browse/MNG-6058> - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For a

Re: 3.4.0 SNAPSHOT breaks Log4j build

Am 07/06/16 um 23:49 schrieb Christian Schulte: > > I'll take a closer look at the project tomorrow. Could be it's the > Aether bug I mentioned in that other mail which got reverted and makes > the project build again. That would mean the project really should not > build and err

Re: 3.4.0 SNAPSHOT breaks Log4j build

Am 07/06/16 um 23:40 schrieb Stuart McCulloch: > On Wednesday, 6 July 2016 at 22:17, Christian Schulte wrote: >> Am 07/06/16 um 23:08 schrieb Stuart McCulloch: >>> On Wednesday, 6 July 2016 at 21:53, Christian Schulte wrote: >>>> Am 07/06/1

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 07/06/16 um 23:32 schrieb Christian Schulte: > Am 07/06/16 um 23:19 schrieb Christian Schulte: >> Am 07/06/16 um 22:41 schrieb Stuart McCulloch: >>> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote: >>>> Hi to all Maven users, >>>> >

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 07/06/16 um 23:19 schrieb Christian Schulte: > Am 07/06/16 um 22:41 schrieb Stuart McCulloch: >> On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote: >>> Hi to all Maven users, >>> >>> If you like to help making the next Maven release better it w

Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3)

Am 07/06/16 um 22:41 schrieb Stuart McCulloch: > On Wednesday, 6 July 2016 at 20:46, Karl Heinz Marbaise wrote: >> Hi to all Maven users, >> >> If you like to help making the next Maven release better it would be >> nice if you could help a little bit. >> >> Please be aware of this *** This

Re: 3.4.0 SNAPSHOT breaks Log4j build

Am 07/06/16 um 23:08 schrieb Stuart McCulloch: > On Wednesday, 6 July 2016 at 21:53, Christian Schulte wrote: >> Am 07/06/16 um 22:21 schrieb Ralph Goers: >>> This is an interesting situation. The classes that use Jackson are all >>> considered optional in Log4j, so

Re: 3.4.0 SNAPSHOT breaks Log4j build

Am 07/06/16 um 22:21 schrieb Ralph Goers: > This is an interesting situation. The classes that use Jackson are all > considered optional in Log4j, so having optional set to true is indeed what > is desired. However, we require those dependencies to compile and to run the > unit tests. With

Re: MNG-4883

Am 07/04/16 um 22:46 schrieb Stephen Connolly: > So when I have a pom with 1.0 that is the strongest hint > for that pom. That version will be used in that pom even if a transitive > dependency has 2.0 > > So one solution to that is to use ranges... if the transitive dependency > has a version

Re: MNG-4883

Am 07/04/16 um 22:37 schrieb Stephen Connolly: > 1.0 is just a hint, hints can be overridden By means of dependency mediation? So a "1.0" can be ignored during dependency mediation due to e.g. the nearest wins strategy eliminating that "1.0" but a "[1.0]" can never be eliminated by a nearer

MNG-4883

Hi, is version "1.0" really different to the version range "[1.0]"? I am asking because I would like to understand what MNG-4883 is about. If you download the attached 'maven-samples.zip' of that issue and build it, Maven will fail due to "overconstraint version ranges". If you take a look at the

Re: Maven color status

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

Re: Maven color status

Am 07/04/16 um 16:57 schrieb Hervé BOUTEMY: > Hi, > > To me, color is now feature complete: configuration has been added in > r1751085 > (thanks Sébastian), for those wanting to customize their own personal color > scheme. > > There is now only one issue: where to put the code? > It is

Re: Plugin resolution for Maven 3.5

Am 07/02/16 um 16:59 schrieb Robert Scholte: > > I agree that this should have been commons-io:2.4, but it matches the > documentation (g:a is unique and nearest wins). I expect that the problem > lies in the way Aether is used. > I assume that first the complete dependency graph is collected

Re: Plugin resolution for Maven 3.5

Am 07/02/16 um 15:25 schrieb Robert Scholte: > Hi, > > It is very likely that a previous version of maven-shared-utils did not > depend on commons-io, which made it required to specify commons-io with > the test-scope for this project. That's what I assume as well. > With this in mind it

Re: Plugin resolution for Maven 3.5

Am 07/01/16 um 20:11 schrieb Karl Heinz Marbaise: > Hi, > > wouldn't it make sense to create a branch for Maven 3.5.0 ? And > summarize all changes there ? Makes it more clear ? > > Cause there are some issues fixed related to JIRA...for 3.5.0 ? > > WDYT ? > > Already done. That's the

Plugin resolution for Maven 3.5

Hi, I am currently stumbling upon the following issue. Maven resolves plugins as if they were a direct dependency of Maven core. That means it will not consider any 'test' or 'provided' scope dependencies of plugins when building plugin runtime classpaths. I am not sure if this is the correct way

Re: [jira] [Commented] (MNG-5987) Document the algorithm calculating the order of plugin executions.

>> >> Key: MNG-5987 >> URL: https://issues.apache.org/jira/browse/MNG-5987 >> Project: Maven >> Issue Type: Improvement >>Reporter: Christian Schulte >>Priority: Critical >> >>

Re: maven git commit: [MNG-3507] ANSI Color logging for improved output visibility.

Am 06/23/16 um 21:16 schrieb Hervé BOUTEMY: > -1 > look at the implementation of these methods, and you'll see that reset() is > already integrated: that's the intend of these methods > Ok. I am running into an issue where 'cause.getMessage()' returns multiple lines screwing up the console

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

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.

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

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

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/17/16 um 09:39 schrieb Robert Scholte: > Hi, > > a few remarks to the API ( I like the idea of it ). > - use strong() instead of highlight() > - use text() instead of a() > Do we want to be able to nest styles (or mimic it)? > e.g *strong* please ensure to replace this method before *warn*

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/17/16 um 08:08 schrieb Hervé BOUTEMY: > there are concepts: that's what the API I propose expose [1] > Name of the different colors can still be refined, I had to find a first > naming > > if nobody objets, I'll update Maven core and maven-invoker-plugin with this > API like I already did

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/16/16 um 22:15 schrieb Christian Schulte: > Am 06/16/16 um 22:00 schrieb Gary Gregory: >> On Thu, Jun 16, 2016 at 12:55 PM, Christian Schulte <c...@schulte.it> wrote: >> >>> Am 06/16/16 um 21:07 schrieb Hervé BOUTEMY: >>>> the second commit mak

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/16/16 um 22:00 schrieb Gary Gregory: > On Thu, Jun 16, 2016 at 12:55 PM, Christian Schulte <c...@schulte.it> wrote: > >> Am 06/16/16 um 21:07 schrieb Hervé BOUTEMY: >>> the second commit makes really things awful here >>> Sorry, -1, please revert >&

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/16/16 um 21:07 schrieb Hervé BOUTEMY: > the second commit makes really things awful here > Sorry, -1, please revert I just reverted both commits. To me it's not clear what the benefit of colored log messages should be. Having errors in red and warnings in yellow (not just the log level name

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/16/16 um 19:59 schrieb Hervé BOUTEMY: > - blue for mojo is not really readable on my machine (Linux on black > background) > - yellow is the OSX way to display bold: on my Linux machine, bold is > rendered > as bold white > - bold is used not only to display execution id > Means we

Re: maven git commit: [MNG-3507] added color to Maven execution output messages

Am 06/16/16 um 19:59 schrieb Hervé BOUTEMY: > - blue for mojo is not really readable on my machine (Linux on black > background) > - yellow is the OSX way to display bold: on my Linux machine, bold is > rendered > as bold white > - bold is used not only to display execution id > > I'm really

Re: maven git commit: [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)

Am 06/15/16 um 23:59 schrieb Jason Dillon: > On June 15, 2016 at 12:07:32 AM, Christian Schulte (c...@schulte.it > <mailto:c...@schulte.it>) wrote: >> Am 06/15/16 um 00:17 schrieb Jason Dillon: >> > Making the colors configurable seems like a lot of overhead for wha

Re: maven git commit: [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)

Am 06/15/16 um 00:17 schrieb Jason Dillon: > Making the colors configurable seems like a lot of overhead for what is > otherwise fairly simple. > > I’d recommend leaving the colors asis for now, get this out to let users > actually make use of it, and then consider adding complexity later to

Re: [2/2] maven git commit: [MNG-6006] Import Aether to Maven codebase

Am 06/12/16 um 16:14 schrieb Karl Heinz Marbaise: > Hi Christian, > > On 6/12/16 4:06 PM, Christian Schulte wrote: >> Am 06/12/16 um 15:56 schrieb Karl Heinz Marbaise: >>> Hi, >>> >>> We might make a few weeks later a bug fix release 3.4.1 which con

Re: [2/2] maven git commit: [MNG-6006] Import Aether to Maven codebase

Am 06/12/16 um 15:56 schrieb Karl Heinz Marbaise: > Hi, > > We might make a few weeks later a bug fix release 3.4.1 which contains > those changes...but this changes behaviour so we might need to make a > 3.5.0 ... That same discussion will take place for Maven 3.5, 3.6, 3.7 and so on. That's

Re: https://issues.apache.org/jira/browse/MNG-5227

Am 06/12/16 um 15:40 schrieb Robert Scholte: >> >> Why? >> > > Let me quote myself: > "I've been talking about this change with a couple of fellow committers at > FOSDEM and it convinced me that you never ever want to manage optional. > They have too much effect on the dependencies using it.

Re: [2/2] maven git commit: [MNG-6006] Import Aether to Maven codebase

Am 06/12/16 um 15:49 schrieb Karl Heinz Marbaise: > Hi, > > this can not be done at the moment, cause the Aether thing is not clear > yet...Changes for package structure is not yet done. Meeting of Eclipse > board will be done mid june as far as i know... > > So -1 for this change... Also for

Re: https://issues.apache.org/jira/browse/MNG-5227

Am 06/12/16 um 15:01 schrieb Robert Scholte: >> Hi, >> >> based on the feedback of the tests for current Maven 3.4.0-SNAPSHOT >> testing I have taken a deeper look into some of the changes. >> >> Based on the above issue we now have changed the behaviour of Maven >> 3.4.0 compared to 3.3.9

Re: https://issues.apache.org/jira/browse/MNG-5227

ay the scope and version can be managed. What's wrong with that? It's a missing feature. > Give Christian Schulte the chance to clarify this again, based on 2 or 3 > poms. Hopefully that explains it a bit more. Issue has reached TLDR status

Re: maven git commit: [MNG-6038] use Gossip slf4j provider (with level color support)

Am 06/12/16 um 00:03 schrieb Michael Osipov: > Am 2016-06-11 um 13:27 schrieb Hervé BOUTEMY: >> if someone has an objection, just tell and we can easily revert > > Hervé, > > thank you for the hard work. > > I not sure wether this is related to recent changes to master or Maven > Core ITs

Re: 3.4.0-SNAPSHOT failure with findbugs Re: colorized Maven output

Am 06/10/16 um 22:33 schrieb Arnaud Héritier: > I need to investigate but I have a bug with findbugs and 3.4.0-SNAPSHOT It's a bug in the 'findbugs-maven-plugin' already fixed upstream but not released yet. You just need to build a recent https://github.com/gleclaire/findbugs-maven-plugin

Re: colorized Maven output

Am 06/09/16 um 09:04 schrieb Petar Tahchiev: > Hello, > > I checked on Windows with Herve's [1]. Unfortunately I am unable to build > my project with 3.4.0-SNAPSHOT. I have this dependency: > > > org.drools > drools-bom > pom >

Re: colorized Maven output

ll be fixed in the next FindBugs plugin release. <https://github.com/gleclaire/findbugs-maven-plugin/commit/7954b94eff5c6b0524e7fe26d8f114b3c5450b86> Regards, -- Christian Schulte - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: Massive number of failing ITs

uot;build still failing" mails caught my attention the same time the issue got raised in JIRA. Did not downgrade immediately because it looked like SLF4J 1.7.22 was on its way. Sorry for the inconvenience caused. Regards,

Re: Maven Core - Release 3.4.0?

Am 05/07/16 um 20:05 schrieb Karl Heinz Marbaise: > Hi to all, > > based on the number issues which have been fixed in the current 3.4.0... > > I would like to ask if there are objections to make a new release within > the next 2 or 3 weeks...except we have very important fixes to do?.. There

Minimum JDK requirement.

Hello, I know this has been discussed before. I do not find relevant thread(s). What was/is still the reason for keeping things targetted at Java 6? Whenever I stumble upon something with '-target <1.7', can I just set it to '-target 1.7'? I would like to use Java 7 features as soon as possible.

Re: Suggestions for Plugins / Shared Components

This would need to be enforced automatically in a way that a release with a version string not containing three digits cannot be performed. Maybe also get rid of -alpha, -beta, -whatever that way. Am 05/06/16 um 22:00 schrieb Karl Heinz Marbaise: > Hi to all, > > I would like to suggest to keep

Re: plexus-utils

It's working. Thanks. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Re: plexus-utils

Am 05/04/16 um 20:27 schrieb Karl Heinz Marbaise: > Hi Christian, > > On 5/4/16 8:25 PM, Christian Schulte wrote: >> Thanks. Joined @Github and filed an issue @Sonatype JIRA. > > Can you give the issue reference ? > <https://issues.sonatype.org/browse/OSSR

Re: plexus-utils

Thanks. Joined @Github and filed an issue @Sonatype JIRA. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

plexus-utils

Hi, is [https://github.com/codehaus-plexus/plexus-utils] the correct repository to open pull requests at? I would like to merge a pull request and create a 'plexus-utils-3.0.23' release. How is that done? Which issue tracker to use? Whome/where to ask? etc. Regards, -- Christian

Re: Maven Memory Consumption

Am 04/18/16 um 01:39 schrieb Christian Schulte: > Am 04/17/16 um 18:08 schrieb Bernd Eckenfels: >> Hello, >> >> I wondered about that as well. It was discussed 2012 on maven-dev. The >> statement looks like this: >> >> # Runtime r = Runtime.getRuntime();

Re: Maven Memory Consumption

Am 04/17/16 um 18:08 schrieb Bernd Eckenfels: > Hello, > > I wondered about that as well. It was discussed 2012 on maven-dev. The > statement looks like this: > > # Runtime r = Runtime.getRuntime(); > # long MB = 1024 * 1024; > # "Final Memory: " + ( r.totalMemory() - r.freeMemory() ) / MB +

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

Am 04/16/16 um 02:42 schrieb Dan Tran: > the discovery of java home at Linux is a fantastic feature. Depends on what packages you install. Install a JRE and a JDK and things get messed up. Gave up on all Linux almost a decade ago. So maybe things have changed recently. So +1 for the discovery

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

And I do have seen systems installing some shell script at '/usr/bin/java' not even beeing a Java launcher at all. So, +1 for the branch -∞ for `which java` Regards, - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: RFC on MNG-6003: Drastically reduce JAVA_HOME discovery code

Am 04/15/16 um 22:34 schrieb Michael Osipov: > In MNG-6003 [1], I propose to throw away all of this code and solely > rely on the dev's input. If he/she it not able to set it properly, > he/she shouldn't write code at all. Most of the time, on Unix/Linux, > this isn't even necessary because a

<    1   2   3   4   5   6   7   >