[GitHub] maven-enforcer pull request #19: requireEnvironmentVariable doc: fix typo in...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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