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
On Sat, 02 Jul 2016 16:31:41 +0200, Christian Schulte
wrote:
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.
Th
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 see
Hi,
there's this basic rule: always specify your direct dependencies if you
use them in your code, never rely on transitive dependencies.
So in this case commons-io is not directly used by the main classes, but
it is by the test-classes.
It is very likely that a previous version of maven-shar
Hi,
On 7/1/16 9:03 PM, Christian Schulte wrote:
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 ?
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 MNG-60
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 ?
Kind regards
Karl Heinz Marbaise
On 7/1/16 9:16 AM, Christian Schulte wrote:
Hi,
I am currently s
Not sure I completely understand the question, but we've always said that
you shouldn't use another plugin as a dependency. Re-usable logic should be
kept in a library instead.
/Anders
On Fri, Jul 1, 2016 at 9:16 AM, Christian Schulte wrote:
> Hi,
>
> I am currently stumbling upon the following
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
