Am 08/15/16 um 22:21 schrieb Fred Cooke:
> Something doesn't have to be in Java to be universal (as SLF4J really is),
> and conversely, something being in Java doesn't make the world instantly
> catch up (eg YodaTime vs J8+).
Or java.util.logging. Almost not used anywhere.
--
The behavior is AND. You can have multiple profiles for OR.
Chas
> On Aug 15, 2016, at 11:45 AM, Christopher wrote:
>
> If there could be "AND" and "OR" primitives for profile activation
> conditions, you could do something like:
>
>
>
> !profilea
>
>
Something doesn't have to be in Java to be universal (as SLF4J really is),
and conversely, something being in Java doesn't make the world instantly
catch up (eg YodaTime vs J8+).
Adding the nop logger as a dep seems like the wrong thing to do and will
(IIRC) cause a warning/error at runtime if the
Michael, Robert, and Christian, thank you all for your input. I found the
discussion very helpful and fruitful.
The issue for introducing a new scope for non-functional resources is here:
https://issues.apache.org/jira/browse/MNG-6080
I would like to take part in the development of this feature,
This thread is about altering the implementation of MNG-5567. I am unsure
why you think it's unrelated to the new scope; that is being proposed as
the new implementation. If the new scope can be introduced in 3.4, then I
think MNG-5567 should be too; otherwise rolled back.
Cheers,
Paul
On Mon, Au
If there could be "AND" and "OR" primitives for profile activation
conditions, you could do something like:
!profilea
profilea
!true
Sadly, this feature does not exist.
On Fri, Aug 12, 2016, 11:45 Karl Heinz
Am 2016-08-15 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? If a new scope
cannot be introduced, then I would
Am 2016-08-15 um 20:08 schrieb Christian Schulte:
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?
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 r
My mistake: it's MPLUGIN-302, Dependency Annotation
On Mon, 15 Aug 2016 19:57:25 +0200, Paul Benedict
wrote:
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 s
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? If a new scope
cannot be introduced, then I would like MNG-5567 backed out until 4.0.
Cheers,
Pa
Am 2016-08-15 um 17:59 schrieb Paul Benedict:
On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov
wrote:
Control of the classpath is the dependency list itself, isn't it?
There is opt-in/-out att all for any kind of dependency.
Third, it's possible a "zip" non-classpath resource could conflict
On Mon, Aug 15, 2016 at 2:37 AM Michael Osipov wrote:
> Am 2016-08-14 um 23:21 schrieb Christopher:
> > On Sun, Aug 14, 2016 at 4:31 PM Michael Osipov
> wrote:
> >
> >> Am 2016-08-12 um 23:48 schrieb Christopher:
> >>> Hi,
> >>>
> >>> I use a plugin which has a runtime dependency on an slf4j
> i
On Mon, 15 Aug 2016 17:59:14 +0200, Paul Benedict
wrote:
On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov
wrote:
JARs are ZIPs with a different name, no less but a bit more. java(1)
treats ZIP files as first-class citizens. We have taken away to option
previously. People, including me, hav
On Mon, Aug 15, 2016 at 10:29 AM, Michael Osipov
wrote:
> JARs are ZIPs with a different name, no less but a bit more. java(1)
> treats ZIP files as first-class citizens. We have taken away to option
> previously. People, including me, have abused JARs as resource containers
> (JS, images, css) t
Am 2016-08-15 um 17:18 schrieb Paul Benedict:
I would like to reopen MNG-5567 because I find the solution incomplete. As
the ticket stands today, any "zip" listed as a dependency will get put on
the classpath. The rationale behind that decision was:
(a) the classpath supports "zip" extensions
(b
I would like to reopen MNG-5567 because I find the solution incomplete. As
the ticket stands today, any "zip" listed as a dependency will get put on
the classpath. The rationale behind that decision was:
(a) the classpath supports "zip" extensions
(b) there is apparently no harm in automatically p
Fred:he is missing slf4j-nop as a runtime dependency specifically:
org.slf4j
slf4j-nop
1.7.2runtime
Martin--
__
> From: fred.co...@gmai
Clearly it's going to matter to him if Maven fails to provide and it
doesn't work. Some sort of dependency isolation not right somewhere?
Something seems to be going on. You're right, but he's seeing behaviour
that indicates something is amiss.
On Mon, Aug 15, 2016 at 6:37 PM, Michael Osipov wrot
GitHub user jmini opened a pull request:
https://github.com/apache/maven-enforcer/pull/19
requireEnvironmentVariable doc: fix typo in xml
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jmini/maven-enforcer patch-1
Alternatively
20 matches
Mail list logo
