On Sun 5 Nov 2017 at 21:17, Robert Scholte wrote:
> One thing I'd like to change is that if a module is a dependency it must
> really behave like one. It should not be the MavenProject, that should
> only be used for building *that* project. It should act as if it was
> downloaded via the artifa
On Mon 6 Nov 2017 at 01:48, Charles Honton wrote:
> Both these use cases sound like adding incredible complexity to support
> less than 1% situations, and worse, encouraging monolithic builds.
>
> In the first case, the module creating a shaded jar can mark its
> constituent jars as optional; pre
Both these use cases sound like adding incredible complexity to support less
than 1% situations, and worse, encouraging monolithic builds.
In the first case, the module creating a shaded jar can mark its constituent
jars as optional; preventing the transitive dependencies.
In the second case,
The VOTE to release Commons Lang 3.7 is underway. This will fix the NOW.
Gary
On Nov 5, 2017 14:06, "Mark Derricutt" wrote:
> On 3 Nov 2017, at 22:48, Rory O'Donnell wrote:
>
> JDK 10 Early Access build 29 is available at : - jdk.java.net/10/
>
> Looks like Surefire is the first casualty:
>
>
slachiewicz opened a new pull request #29: Update to Mockito 2.11
URL: https://github.com/apache/maven-enforcer/pull/29
Fixes MENFORCER-278
This is an automated message from the Apache Git Service.
To respond to the message, p
Hello,
Adding annotations and processor as a compiletime dependency sounds like a
reasonable thing. It would however be cool if the JAR could describe which
package needs to go on the classpath and which is processor impl. (and having a
different artifact for runtime)
Gruss
Bernd
Von: Mark De
On 5 Nov 2017, at 10:42, Robert Scholte wrote:
> I would like to drop strict scopes in general and give plugins the
> opportunity to depend on
> specific scoped dependencies.
How would this help with annotations tho? The main issue I'm facing is having a
standard m-c-p plugin definition in a pa
One thing I'd like to change is that if a module is a dependency it must really
behave like one. It should not be the MavenProject, that should only be used
for building *that* project. It should act as if it was downloaded via the
artifact resolver
Robert
Verzonden vanaf mijn Samsung Galaxy-s
One thing I'd like to change is that if a module is a dependency it must really
behave like one. It should not be the MavenProject, that should only be used
for building *that* project. It should act as if it was downloaded via the
artifact resolver
Robert
Verzonden vanaf mijn Samsung Galaxy-s
On 3 Nov 2017, at 22:48, Rory O'Donnell wrote:
> JDK 10 Early Access build 29 is available at : - jdk.java.net/10/
Looks like Surefire is the first casualty:
Caused by: java.lang.NullPointerException
at
org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLea
There are two sets of problems that, assuming we want to fix, both need
some way to rally a concurrent multimodule build at.
1. There is the shade like class of problems, where a plugin wants to
modify the effective transitive dependencies of a module.
2. There is the extensibility class of probl
On Sun, 05 Nov 2017 07:04:54 +0100, Hervé BOUTEMY
wrote:
Le samedi 4 novembre 2017, 22:35:35 CET Robert Scholte a écrit :
On Sat, 04 Nov 2017 18:34:14 +0100, Romain Manni-Bucau
wrote:
> 2017-11-04 18:17 GMT+01:00 Stephen Connolly
>
> :
>> On Sat 4 Nov 2017 at 17:11, Romain Manni-Bucau
12 matches
Mail list logo
