+1
On 1 July 2016 at 21:24, Karl Heinz Marbaise wrote:
> Hi,
>
> We solved 24 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828&version=12331366
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2
GitHub user antoinebrl opened a pull request:
https://github.com/apache/maven-shared/pull/14
[MSHARED-562] Color recognition based on color related methods' name
this modification take into account the background color and not only the
foreground one. The distinction is made by star
On 5 Jul 2016, at 8:37, Stephen Connolly wrote:
> 1.0 is just a hint, hints can be overridden
> [1.0] is a hard requirement
The later also forces maven to download the metadata, and check the version
exists in said metadata, which - even if its in the repository, but the
meta-data is broken ( a
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 lik
That's my understanding... and if you have two conflicting hard
dependencies for the same artifact with different versions then Maven
should fail the build until you exclude the one you don't want with
exclusions
On 4 July 2016 at 21:42, Christian Schulte wrote:
> Am 07/04/16 um 22:37 schrieb St
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 like [2.0] then that basically says I must
have version 2.0 no
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 depend
1.0 is just a hint, hints can be overridden
[1.0] is a hard requirement
On 4 July 2016 at 21:35, Christian Schulte wrote:
> 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 attac
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
Not to that extreme obviously. But I am just saying the colorization might not
need a separate new component. It should fit somewhere in the existing
components. And if the choice means that you only get colorization with 3.4.0
and plugins that depends on that latest component... so be it ..
M
Hi,
ony more PMC vote needed...
Kind regards
Karl Heinz Marbaise
On 7/1/16 1:24 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 24 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828&version=12331366
There are still a couple of issues left in JIRA:
https://issues.a
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
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..
Manfred
Karl Heinz Marbaise wrote on 2016-07-04 10:38:
> Hi,
>
> On 7/4/16 6:5
Hi,
On 7/4/16 6:52 PM, Christian Schulte wrote:
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
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 current
because the code has to be available for plugins without requiring Maven 3.4
(even if color won't be enabled when run with older Maven versions)
Regards,
Hervé
Le lundi 4 juillet 2016 17:21:57 Arnaud Héritier a écrit :
> What was the reason to not have it in core ?
>
> On Mon, Jul 4, 2016 at 4
What was the reason to not have it in core ?
On Mon, Jul 4, 2016 at 4:57 PM, Hervé BOUTEMY wrote:
> 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 on
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 currently in maven-shared-utils, but maven-shared-utils depends on
ma
GitHub user retomerz opened a pull request:
https://github.com/apache/maven-plugins/pull/87
Reintroduce verbose support for dependency:tree
This patch reintroduce the support of the "verbose" parameter for
dependency:tree.
This feature was removed as part of MDEP-494.
You can m
19 matches
Mail list logo
