[GitHub] maven-enforcer pull request #19: requireEnvironmentVariable doc: fix typo in...

[jmini]

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 you can review and apply these changes as the patch at:

https://github.com/apache/maven-enforcer/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit f1ffc7f8c8339800787807d6dba6c599d3ded4dc
Author: Jérémie Bresson 
Date:   2016-08-15T07:25:31Z

requireEnvironmentVariable doc: fix typo in xml




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: slf4j runtime dependency for plugin

[Fred Cooke]

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  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
 implementation,
 but the plugin itself is built without declaring one in its pom. (
 https://github.com/koraktor/mavanagaiata/issues/43)

 In some versions of Maven, I get a warning about slf4j not finding an
 implementation. In other versions, it is silent.

 Was an slf4j implementation provided in newer versions to the execution

>>> of
>>>
 plugins?

 Will there be a multiple-binding conflict if the plugin itself provides

>>> one
>>>
 of its own to get rid of the warning on certain versions of maven which
 result in that warning (I didn't see one when I tried)?

 If there is a risk of a conflict, which implementation would be
 preferred
 in order to converge on one provided by Maven?

 Is there another solution the plugin should seek?

 In general, what dependencies are plugins expected to provide, and what
 dependencies are expected to be provided by Maven, and how are conflicts
 resolved in the architecture?

 Feel free to comment on the GitHub issue directly, or here. I'll be
 watching both.

>>>
>>> I will cite what I have written on Stack Overflow
>>> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
>>> holds true:
>>>
>>> You *never* provide a log implementation. The client application has to
>>> do so. Otherwhise this would be a violation of separation of concerns.
>>> Don't do any assumptions about an unknown client.
>>>
>>>
>>> I agree with that sentiment...generally. But this is a maven plugin, so
>> I'm
>> trying to figure out what Maven is going to provide it when it executes.
>> If
>> it's not going to provide an implementation, then the plugin has to. If
>> you
>> have answers to the specific questions I asked above, I think it might
>> help.
>>
>
> It should not matter to you what Maven provides. It will always provide
> some backend. Otherwise Maven won't be able to log itself.  Even if Maven
> would not provide anything. It is not your task to force some
> implementation. It is a several failure of the client to do so.
>
> Michael
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

RE: slf4j runtime dependency for plugin

[Martin Gainty]

Fred:he is missing slf4j-nop as a runtime dependency specifically:
org.slf4j
slf4j-nop  
1.7.2runtime  

Martin--
__ 


> From: fred.co...@gmail.com
> Date: Mon, 15 Aug 2016 22:13:45 +1200
> Subject: Re: slf4j runtime dependency for plugin
> To: dev@maven.apache.org
> 
> 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  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
>  implementation,
>  but the plugin itself is built without declaring one in its pom. (
>  https://github.com/koraktor/mavanagaiata/issues/43)
> 
>  In some versions of Maven, I get a warning about slf4j not finding an
>  implementation. In other versions, it is silent.
> 
>  Was an slf4j implementation provided in newer versions to the execution
> 
> >>> of
> >>>
>  plugins?
> 
>  Will there be a multiple-binding conflict if the plugin itself provides
> 
> >>> one
> >>>
>  of its own to get rid of the warning on certain versions of maven which
>  result in that warning (I didn't see one when I tried)?
> 
>  If there is a risk of a conflict, which implementation would be
>  preferred
>  in order to converge on one provided by Maven?
> 
>  Is there another solution the plugin should seek?
> 
>  In general, what dependencies are plugins expected to provide, and what
>  dependencies are expected to be provided by Maven, and how are conflicts
>  resolved in the architecture?
> 
>  Feel free to comment on the GitHub issue directly, or here. I'll be
>  watching both.
> 
> >>>
> >>> I will cite what I have written on Stack Overflow
> >>> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> >>> holds true:
> >>>
> >>> You *never* provide a log implementation. The client application has to
> >>> do so. Otherwhise this would be a violation of separation of concerns.
> >>> Don't do any assumptions about an unknown client.
> >>>
> >>>
> >>> I agree with that sentiment...generally. But this is a maven plugin, so
> >> I'm
> >> trying to figure out what Maven is going to provide it when it executes.
> >> If
> >> it's not going to provide an implementation, then the plugin has to. If
> >> you
> >> have answers to the specific questions I asked above, I think it might
> >> help.
> >>
> >
> > It should not matter to you what Maven provides. It will always provide
> > some backend. Otherwise Maven won't be able to log itself.  Even if Maven
> > would not provide anything. It is not your task to force some
> > implementation. It is a several failure of the client to do so.
> >
> > Michael
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
  

MNG-5567: Zips on classpath

[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) there is apparently no harm in automatically putting everything "zip"
on the classpath
(c) there is no apparent reason to opt-out

I have an issue with (b) and (c). Here's why:

First, it violates the principle that developers should control what goes
on the classpath. I really can't believe Maven would wrestle this control
away. The assumption that every "zip" is meant to be on the classpath is
erroneous. This is not the case and Maven shouldn't automatically assume
it. Even if Maven was to assume it, the lack of opt-in behavior gives no
escape hatch.

Second, for projects that I personally deal with, these "zip" artifacts are
nothing but shared front-end web resources. These are not meant to on the
class path. The dependencies are there so other goals can unpack them
during the build and place them in the context root.

Third, it's possible a "zip" non-classpath resource could conflict with a
same named resource in the classpath. I haven't had to be concerned with
this (yet), but I will be on the lookout if MNG-5567 doesn't change.

Cheers,
Paul

Re: MNG-5567: Zips on classpath

[Michael Osipov]

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) there is apparently no harm in automatically putting everything "zip"
on the classpath
(c) there is no apparent reason to opt-out

I have an issue with (b) and (c). Here's why:

First, it violates the principle that developers should control what goes
on the classpath. I really can't believe Maven would wrestle this control
away. The assumption that every "zip" is meant to be on the classpath is
erroneous. This is not the case and Maven shouldn't automatically assume
it. Even if Maven was to assume it, the lack of opt-in behavior gives no
escape hatch.

Second, for projects that I personally deal with, these "zip" artifacts are
nothing but shared front-end web resources. These are not meant to on the
class path. The dependencies are there so other goals can unpack them
during the build and place them in the context root.


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) to have them on the classpath with the 
entire, convoluted lifecycle JAR has.


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 with a
same named resource in the classpath. I haven't had to be concerned with
this (yet), but I will be on the lookout if MNG-5567 doesn't change.


I conflict in resources names can also happen with JARs and you have no 
control of it at all as of today.


How would you try to solve the problem?

Michael

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5567: Zips on classpath

[Paul Benedict]

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) to have them on the classpath with the entire, convoluted
> lifecycle JAR has.
>

Yes, JARs are ZIPs with a different name, but not every ZIP is JAR. That
was the point I was trying to get across. Just because a Java project
employs ZIP files, it doesn't mean the ZIP is meant to be on the classpath.
To be clear regarding my personal experience in using ZIPs, I am not
abusing JARs as resource containers: neither as a .jar file extension nor
"jar" Maven project type. I agree that's an abuse and have always avoided
it.



> 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 with a
>> same named resource in the classpath. I haven't had to be concerned with
>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>
>
> I conflict in resources names can also happen with JARs and you have no
> control of it at all as of today.
>
> How would you try to solve the problem?
>

I propose introducing a new scope. All the scopes dictate when a dependency
makes it onto the classpath. In the case of a pure non-classpath resource
container, it never needs be on the classpath, but it does need to remain
available in the reactor. No current scope fits this need. If I may propose
the new scope name, I would call it "asset".

Furthermore, I would give "zip" types this new "asset" scope as the
default. If anyone wants to add such a dependency to the classpath, they
should specify the appropriate scope. The benefit here is that (1) people
who are currently using "zip" (custom handlers?) wouldn't get their
classpath upended by new behavior and (2) explicitly adding a "zip" to the
classpath requires them to think about what scope they desire.

Cheers,
Paul

Re: MNG-5567: Zips on classpath

[Robert Scholte]

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, have abused JARs as resource  
containers
(JS, images, css) to have them on the classpath with the entire,  
convoluted

lifecycle JAR has.



Yes, JARs are ZIPs with a different name, but not every ZIP is JAR. That
was the point I was trying to get across. Just because a Java project
employs ZIP files, it doesn't mean the ZIP is meant to be on the  
classpath.

To be clear regarding my personal experience in using ZIPs, I am not
abusing JARs as resource containers: neither as a .jar file extension nor
"jar" Maven project type. I agree that's an abuse and have always avoided
it.




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 with  
a
same named resource in the classpath. I haven't had to be concerned  
with

this (yet), but I will be on the lookout if MNG-5567 doesn't change.



I conflict in resources names can also happen with JARs and you have no
control of it at all as of today.

How would you try to solve the problem?



I propose introducing a new scope. All the scopes dictate when a  
dependency

makes it onto the classpath. In the case of a pure non-classpath resource
container, it never needs be on the classpath, but it does need to remain
available in the reactor. No current scope fits this need. If I may  
propose

the new scope name, I would call it "asset".

Furthermore, I would give "zip" types this new "asset" scope as the
default. If anyone wants to add such a dependency to the classpath, they
should specify the appropriate scope. The benefit here is that (1) people
who are currently using "zip" (custom handlers?) wouldn't get their
classpath upended by new behavior and (2) explicitly adding a "zip" to  
the

classpath requires them to think about what scope they desire.

Cheers,
Paul


Hi,

a scope is indeed the right way to control this. But that also means that  
plugins must be able to understand either general or their own scopes.
I've had a look at the ArtifactHandler and was wondering if the  
implementation is correct and you kind of confirms this.
The DefaultArtifactHandler has the field "addToClasspath". First of all:  
classpaths are too close related to Java, the DefaultArtifactHandler  
shouldn't care about this. But it also claims that certain types should  
always be handled the same way. IMO it should be the scope which should  
control these kind of things.
It looks like you're both referring to the maven-war-plugin where a zip  
has a different purpose.
With MPLUGIN-305 it should be possible to give the zip a different scope,  
so it doesn't end up on the classpath, but that it can be used for the  
war-file.


thanks,
Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: slf4j runtime dependency for plugin

[Christopher]

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
> implementation,
> >>> but the plugin itself is built without declaring one in its pom. (
> >>> https://github.com/koraktor/mavanagaiata/issues/43)
> >>>
> >>> In some versions of Maven, I get a warning about slf4j not finding an
> >>> implementation. In other versions, it is silent.
> >>>
> >>> Was an slf4j implementation provided in newer versions to the execution
> >> of
> >>> plugins?
> >>>
> >>> Will there be a multiple-binding conflict if the plugin itself provides
> >> one
> >>> of its own to get rid of the warning on certain versions of maven which
> >>> result in that warning (I didn't see one when I tried)?
> >>>
> >>> If there is a risk of a conflict, which implementation would be
> preferred
> >>> in order to converge on one provided by Maven?
> >>>
> >>> Is there another solution the plugin should seek?
> >>>
> >>> In general, what dependencies are plugins expected to provide, and what
> >>> dependencies are expected to be provided by Maven, and how are
> conflicts
> >>> resolved in the architecture?
> >>>
> >>> Feel free to comment on the GitHub issue directly, or here. I'll be
> >>> watching both.
> >>
> >> I will cite what I have written on Stack Overflow
> >> (http://stackoverflow.com/a/7107934/696632) five years ago and it still
> >> holds true:
> >>
> >> You *never* provide a log implementation. The client application has to
> >> do so. Otherwhise this would be a violation of separation of concerns.
> >> Don't do any assumptions about an unknown client.
> >>
> >>
> > I agree with that sentiment...generally. But this is a maven plugin, so
> I'm
> > trying to figure out what Maven is going to provide it when it executes.
> If
> > it's not going to provide an implementation, then the plugin has to. If
> you
> > have answers to the specific questions I asked above, I think it might
> help.
>
> It should not matter to you what Maven provides. It will always provide
> some backend. Otherwise Maven won't be able to log itself.  Even if
> Maven would not provide anything. It is not your task to force some
> implementation. It is a several failure of the client to do so.
>
> Michael
>

That would make more sense to me if there were a universally agreed upon
logging API, and all clients were guaranteed to provide *some* backend for
that standard logging API. Unfortunately, no logging API seems to be
universal, and the one provided in Java itself is awful. I'm not even sure
what Maven uses underneath, and it may not use SLF4J at all (which means it
has no reason to provide an implementation).

This is actually a pretty unfortunate circumstance in the first place...
Maven plugins should only be logging to the provided Maven logger itself,
and the plugin shouldn't care what backend Maven is using for that logger. This
particular plugin is doing the right thing... using the Maven logger and
relying on Maven for the backend. Unfortunately, it seems the
org.eclipse.jgit dependency does its own logging, and that's outside this
plugin's control.

Until there is a universal logging framework, these heuristics about what
the "right" thing to do are not going to be perfect. Ideals like "rely on
the client to provide the implementation" aren't going to fully match
reality. Personally, I'd like to see an slf4j-like API make its way into
Java itself. Then, perhaps these kinds of issues wouldn't come up as often.

Re: MNG-5567: Zips on classpath

[Michael Osipov]

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 with a

same named resource in the classpath. I haven't had to be concerned with
this (yet), but I will be on the lookout if MNG-5567 doesn't change.



I conflict in resources names can also happen with JARs and you have no
control of it at all as of today.

How would you try to solve the problem?



I propose introducing a new scope. All the scopes dictate when a dependency
makes it onto the classpath. In the case of a pure non-classpath resource
container, it never needs be on the classpath, but it does need to remain
available in the reactor. No current scope fits this need. If I may propose
the new scope name, I would call it "asset".


While this sounds reasonable, I highly doubt that this will happen 
before Maven 4.0.


You may want to raise an issue for this.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5567: Zips on classpath

[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 like MNG-5567 backed out until 4.0.

Cheers,
Paul

On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov 
wrote:

> 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 with a
>>>
 same named resource in the classpath. I haven't had to be concerned with
 this (yet), but I will be on the lookout if MNG-5567 doesn't change.


>>> I conflict in resources names can also happen with JARs and you have no
>>> control of it at all as of today.
>>>
>>> How would you try to solve the problem?
>>>
>>>
>> I propose introducing a new scope. All the scopes dictate when a
>> dependency
>> makes it onto the classpath. In the case of a pure non-classpath resource
>> container, it never needs be on the classpath, but it does need to remain
>> available in the reactor. No current scope fits this need. If I may
>> propose
>> the new scope name, I would call it "asset".
>>
>
> While this sounds reasonable, I highly doubt that this will happen before
> Maven 4.0.
>
> You may want to raise an issue for this.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-5567: Zips on classpath

[Robert Scholte]

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 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,
Paul

On Mon, Aug 15, 2016 at 11:53 AM, Michael Osipov 
wrote:


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  
with a


same named resource in the classpath. I haven't had to be concerned  
with

this (yet), but I will be on the lookout if MNG-5567 doesn't change.


I conflict in resources names can also happen with JARs and you have  
no

control of it at all as of today.

How would you try to solve the problem?



I propose introducing a new scope. All the scopes dictate when a
dependency
makes it onto the classpath. In the case of a pure non-classpath  
resource
container, it never needs be on the classpath, but it does need to  
remain

available in the reactor. No current scope fits this need. If I may
propose
the new scope name, I would call it "asset".



While this sounds reasonable, I highly doubt that this will happen  
before

Maven 4.0.

You may want to raise an issue for this.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5567: Zips on classpath

[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?

The 'import' scope was introduced in a patch release (2.0.9). I see no
reason something like this cannot go into 3.4 (minor version increment
already). Just my personal opinion, of course.

Regards,
-- 
Christian



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5567: Zips on classpath

[Michael Osipov]

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?


The 'import' scope was introduced in a patch release (2.0.9). I see no
reason something like this cannot go into 3.4 (minor version increment
already). Just my personal opinion, of course.


Probably not the stupidest idea after all. Maybe scope 'reactor'?


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: MNG-5567: Zips on classpath

[Michael Osipov]

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 like MNG-5567 backed out until 4.0.


MNG-5567 and a new scope are not related to each other. Just file an 
issue to track this request. Maybe Christian is right and we could 
introduce this in 3.4.


Michael

Aug 15, 2016 at 11:53 AM, Michael Osipov 

wrote:


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 with a


same named resource in the classpath. I haven't had to be concerned with
this (yet), but I will be on the lookout if MNG-5567 doesn't change.



I conflict in resources names can also happen with JARs and you have no
control of it at all as of today.

How would you try to solve the problem?



I propose introducing a new scope. All the scopes dictate when a
dependency
makes it onto the classpath. In the case of a pure non-classpath resource
container, it never needs be on the classpath, but it does need to remain
available in the reactor. No current scope fits this need. If I may
propose
the new scope name, I would call it "asset".



While this sounds reasonable, I highly doubt that this will happen before
Maven 4.0.

You may want to raise an issue for this.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Profile Activation

[Christopher]

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 Marbaise  wrote:

> Hi to all,
>
> I have the following profile:
>
>
>
>profile-not-value-true
>
>  
>profilea
>!true
>  
>
>
>  
>
>  com.soebes.maven.plugins
>  echo-maven-plugin
>  
>
>  initialize
>  
>echo
>  
>
>  
>  
>
>  profile not value true
>
>  
>
>  
>
>  
>
> So the question is: What would you expect you need to do to activate
> this profile?
>
> Currently this profile is activated cause if I don't define the property
> "profilea" at all it seemed to that Maven is assuming this means "not
> value 'true'" ?
>
> I have assumed it should be activated if the property exists which means
> giving it on command line like this:
>
> mvn -Dprofilea
>
>
>
> WDYT ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-5567: Zips on classpath

[Paul Benedict]

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, Aug 15, 2016 at 1:16 PM, Michael Osipov  wrote:

> 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 like MNG-5567 backed out until 4.0.
>>
>
> MNG-5567 and a new scope are not related to each other. Just file an issue
> to track this request. Maybe Christian is right and we could introduce this
> in 3.4.
>
> Michael
>
>
> Aug 15, 2016 at 11:53 AM, Michael Osipov 
>
>> wrote:
>>
>> 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
> with a
>
> same named resource in the classpath. I haven't had to be concerned
>> with
>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>
>>
>> I conflict in resources names can also happen with JARs and you have
> no
> control of it at all as of today.
>
> How would you try to solve the problem?
>
>
> I propose introducing a new scope. All the scopes dictate when a
 dependency
 makes it onto the classpath. In the case of a pure non-classpath
 resource
 container, it never needs be on the classpath, but it does need to
 remain
 available in the reactor. No current scope fits this need. If I may
 propose
 the new scope name, I would call it "asset".


>>> While this sounds reasonable, I highly doubt that this will happen before
>>> Maven 4.0.
>>>
>>> You may want to raise an issue for this.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: MNG-5567: Zips on classpath

[Paul Benedict]

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, if possible.
Please let me know anyway which I can help.

Cheers,
Paul

On Mon, Aug 15, 2016 at 2:12 PM, Paul Benedict  wrote:

> 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, Aug 15, 2016 at 1:16 PM, Michael Osipov 
> wrote:
>
>> 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 like MNG-5567 backed out until 4.0.
>>>
>>
>> MNG-5567 and a new scope are not related to each other. Just file an
>> issue to track this request. Maybe Christian is right and we could
>> introduce this in 3.4.
>>
>> Michael
>>
>>
>> Aug 15, 2016 at 11:53 AM, Michael Osipov 
>>
>>> wrote:
>>>
>>> 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
>> with a
>>
>> same named resource in the classpath. I haven't had to be concerned
>>> with
>>> this (yet), but I will be on the lookout if MNG-5567 doesn't change.
>>>
>>>
>>> I conflict in resources names can also happen with JARs and you have
>> no
>> control of it at all as of today.
>>
>> How would you try to solve the problem?
>>
>>
>> I propose introducing a new scope. All the scopes dictate when a
> dependency
> makes it onto the classpath. In the case of a pure non-classpath
> resource
> container, it never needs be on the classpath, but it does need to
> remain
> available in the reactor. No current scope fits this need. If I may
> propose
> the new scope name, I would call it "asset".
>
>
 While this sounds reasonable, I highly doubt that this will happen
 before
 Maven 4.0.

 You may want to raise an issue for this.


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org



>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>

Re: slf4j runtime dependency for plugin

[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+).

Adding the nop logger as a dep seems like the wrong thing to do and will
(IIRC) cause a warning/error at runtime if there's another one present.
Leaving it out (IIRC) falls back to that anyway with a warning given. IE, I
don't think adding that does any good whatsoever.

IIRCs because it's been a long time since I had this misconfigured :-)

On Tue, Aug 16, 2016 at 4:47 AM, Christopher  wrote:

> 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
> > implementation,
> > >>> but the plugin itself is built without declaring one in its pom. (
> > >>> https://github.com/koraktor/mavanagaiata/issues/43)
> > >>>
> > >>> In some versions of Maven, I get a warning about slf4j not finding an
> > >>> implementation. In other versions, it is silent.
> > >>>
> > >>> Was an slf4j implementation provided in newer versions to the
> execution
> > >> of
> > >>> plugins?
> > >>>
> > >>> Will there be a multiple-binding conflict if the plugin itself
> provides
> > >> one
> > >>> of its own to get rid of the warning on certain versions of maven
> which
> > >>> result in that warning (I didn't see one when I tried)?
> > >>>
> > >>> If there is a risk of a conflict, which implementation would be
> > preferred
> > >>> in order to converge on one provided by Maven?
> > >>>
> > >>> Is there another solution the plugin should seek?
> > >>>
> > >>> In general, what dependencies are plugins expected to provide, and
> what
> > >>> dependencies are expected to be provided by Maven, and how are
> > conflicts
> > >>> resolved in the architecture?
> > >>>
> > >>> Feel free to comment on the GitHub issue directly, or here. I'll be
> > >>> watching both.
> > >>
> > >> I will cite what I have written on Stack Overflow
> > >> (http://stackoverflow.com/a/7107934/696632) five years ago and it
> still
> > >> holds true:
> > >>
> > >> You *never* provide a log implementation. The client application has
> to
> > >> do so. Otherwhise this would be a violation of separation of concerns.
> > >> Don't do any assumptions about an unknown client.
> > >>
> > >>
> > > I agree with that sentiment...generally. But this is a maven plugin, so
> > I'm
> > > trying to figure out what Maven is going to provide it when it
> executes.
> > If
> > > it's not going to provide an implementation, then the plugin has to. If
> > you
> > > have answers to the specific questions I asked above, I think it might
> > help.
> >
> > It should not matter to you what Maven provides. It will always provide
> > some backend. Otherwise Maven won't be able to log itself.  Even if
> > Maven would not provide anything. It is not your task to force some
> > implementation. It is a several failure of the client to do so.
> >
> > Michael
> >
>
> That would make more sense to me if there were a universally agreed upon
> logging API, and all clients were guaranteed to provide *some* backend for
> that standard logging API. Unfortunately, no logging API seems to be
> universal, and the one provided in Java itself is awful. I'm not even sure
> what Maven uses underneath, and it may not use SLF4J at all (which means it
> has no reason to provide an implementation).
>
> This is actually a pretty unfortunate circumstance in the first place...
> Maven plugins should only be logging to the provided Maven logger itself,
> and the plugin shouldn't care what backend Maven is using for that logger.
> This
> particular plugin is doing the right thing... using the Maven logger and
> relying on Maven for the backend. Unfortunately, it seems the
> org.eclipse.jgit dependency does its own logging, and that's outside this
> plugin's control.
>
> Until there is a universal logging framework, these heuristics about what
> the "right" thing to do are not going to be perfect. Ideals like "rely on
> the client to provide the implementation" aren't going to fully match
> reality. Personally, I'd like to see an slf4j-like API make its way into
> Java itself. Then, perhaps these kinds of issues wouldn't come up as often.
>

Re: Profile Activation

[Chas Honton]

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
> 
> 
>   profilea
>   !true
> 
>   
> 
> Sadly, this feature does not exist.
> 
>> On Fri, Aug 12, 2016, 11:45 Karl Heinz Marbaise  wrote:
>> 
>> Hi to all,
>> 
>> I have the following profile:
>> 
>> 
>>   
>>   profile-not-value-true
>>   
>> 
>>   profilea
>>   !true
>> 
>>   
>>   
>> 
>>   
>> com.soebes.maven.plugins
>> echo-maven-plugin
>> 
>>   
>> initialize
>> 
>>   echo
>> 
>>   
>> 
>> 
>>   
>> profile not value true
>>   
>> 
>>   
>> 
>>   
>> 
>> 
>> So the question is: What would you expect you need to do to activate
>> this profile?
>> 
>> Currently this profile is activated cause if I don't define the property
>> "profilea" at all it seemed to that Maven is assuming this means "not
>> value 'true'" ?
>> 
>> I have assumed it should be activated if the property exists which means
>> giving it on command line like this:
>> 
>> mvn -Dprofilea
>> 
>> 
>> 
>> WDYT ?
>> 
>> Kind regards
>> Karl Heinz Marbaise
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: slf4j runtime dependency for plugin

[Christian Schulte]

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.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org