Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
On Sep 9, 2012, at 11:08 PM, Ralph Goers wrote: Jason made a comment in a previous reply that said Ceki is also a committer, and will help us fix anything when necessary so that, again, we can focus on Maven and not logging. http://people.apache.org/committer-index.html doesn't list him as a committer on Maven I didn't say he was a committer on Maven. Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/
Le 9 sept. 2012 15:44, Jason van Zyl ja...@tesla.io a écrit : I noted in the issue where the tool is and there's a standard Maven plugin page there. Probably as well documented as how to do it with Plexus :-) For sure and I agree on that :-) (as responsible of that fact too :-) ) But as we always have to learn from the past errors. It's probably time to take care of the cliché: maven doc sucks ! I have a series of posts I'm writing which can be the basis of documentation. Great and will be perfect to have that too in maven.apache.org website (the page http://maven.apache.org/developers/mojo-api-specification.html looks to be a good candidate for that) Code here[1], and the documentation is here[2]. [1]: https://github.com/sonatype/sisu-maven-plugin [2]: http://sonatype.github.com/sisu-maven-plugin/ On Sep 9, 2012, at 8:35 AM, Olivier Lamy wrote: 2012/9/3 jvan...@apache.org: Author: jvanzyl Date: Mon Sep 3 01:07:31 2012 New Revision: 1380105 URL: http://svn.apache.org/viewvc?rev=1380105view=rev Log: o Enabled support and discovery of JSR-330 components o Added Slf4j logger factory to support generic JSR-330 logging o Exported Guice package for components that access Guice (or better it's injector) directly Widen export of Guice packages (not ideal, need to look into ways to avoid this) o use specific exports o for now we will attempt to hide all of Guice in plugin realms and we'll do a bit of testing closes #3 Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare -- Olivier
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
But it would be nice to allow the end user the ability to swap out the logging implementation if they want. Yes, that would be very good. I know there's been questions on the mailing list how to tweak the logging (don't remember exactly what the wanted to do). So having something that would make it possible to switch to their favorite logging implementation would be good (even though it has to implement the slf4j api). /Anders Ralph On Sep 9, 2012, at 12:44 PM, Benson Margulies wrote: On Sun, Sep 9, 2012 at 3:34 PM, Mark Struberg strub...@yahoo.de wrote: No client code changes unless the client wants to change it to take advantage of SLF4J. It's not the classes which change but the classpath does. It might then contain clashing classes. That is what I'm afraid of to be honest. Because we do not have the 'other side' (random plugins and projects) under our own control. So, to be clear, we are not talking about the bridges *at all*. Thus, I claim that Mark's concern boils down to the following: Let's say that we add slf4j-api, slf4j-logback, and logback-whatever to the classpath. If I am following, you are worried that some plugin author somewhere is already using logback with a different version and might get an unpleasant surprise when the version we pick shows up. I find this scenario hard to credit. However, if it really worried us, we could shade the back end, and then the only possible means for trouble would be a plugin that wanted to use an incompatible version. If that's not what's worrying you, please humor me with a complete, concrete, example. If it is, can you cite an example of an existing plugin that would bust? LieGrue, strub - Original Message - From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Cc: Sent: Sunday, September 9, 2012 8:43 PM Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/] On Sep 9, 2012, at 2:24 PM, Benson Margulies wrote: Again, let's deal with this one thing at a time: 1. Use slf4j-api as our primary facade/api for loggin in Maven. I'm in favor, because it's much more common and popular than plexus. 2. Picking an slf4j-X to deliver logging to somewhere. I'm somewhat in favor of java.util.logging for this, because of the baroque classpath interactions of log4j initialization. But if others prefer log4j or even something else, OK. Yah, it's SLF4J so pick an implementation. 3. Tossing one or more X-slf4j bridges into the default plugin classpath. If Mark's concerns about surprises have any foundations in technical reality, this is where they would turn up. I'm doubtful, but on the other hand, what if we just didn't do this, and left it to individual plugin authors to do this if, in fact, they wanted mapping from some other logging API? I'm not suggesting this. I've routed the Mojo.getLog() through SLF4J so it just does what it does now except the backing implementation is the SLF4J implementation. If the user wants to use SLF4J and/or @Inject loggers than they have to specify the dependency. No client code changes unless the client wants to change it to take advantage of SLF4J. It would be good for some others to join this discussion. On Sun, Sep 9, 2012 at 1:35 PM, Jason van Zyl ja...@tesla.io wrote: I think you're trying to preemptively solve for an issue that we may not have. I believe that if the right JARs are in the classpath first we will easily be able to tell running the integration tests for Maven and the integration tests for all the plugins if there's going to be an issue. I believe the Ceki has probably run into every integration scenario imaginable over the last 10 years and he'll help us if required. I have runt into nasty problems where the classpath and classloaders cannot be controlled directly from the host system, but this is obviously within our purview to control. On Sep 9, 2012, at 1:22 PM, Mark Struberg wrote: Generally I use jul-to-slf4j and jcl-over-slf4j and then I don't care what components use what logging framework. Yes, only that this sometimes causes really unfriendly classcast exceptions :/ How can we deal with those? Is there a retry possible? Imo not easily. Could we scan the plugin classpath upfront? Can a different class lookup strategy in our ClassRealms help? Don't we care at all and people must exclude log4j et all manually if they like to use a new maven version? LieGrue strub - Original Message - From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Cc: Sent: Sunday, September 9, 2012 7:08 PM Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
On Sep 9, 2012 8:08:34 pm, Ralh Goers wrote: First, I also would recommend moving from plexus logging to SLF4J. Cool. Mark's concerns with incompatibilities only come about with the log4j bridge if you are trying to use APis that the SLF4J bridge hasn't implemented. Something being used in a plugin really shouldn't be using those. Exactly. Although Ceki is generally careful not to break compatibility, it has happened. For example, you cannot mix applications that use SLF4J 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much tied to the SLF4J version. See http://www.slf4j.org/news.html. If core is using SLF4J and an incompatible change is made again it probably won't be that big of a deal. Typically, when compatibility has been broken it really hasn't impacted code that uses the SLF4J API. SLF4J's user facing API, that is classes or interfaces located in the org.slf4j package such as Logger, Marker, MDC and LoggerFactory have been there and remain unchanged since day one (2005). Thus, a user never has to worry about with which version of slf4j-api a dependency was compiled with. A user can pick any version of slf4j-api-api.jar and as long as the version of the binding of her choice matches, slf4j will function correctly. See also [1,2]. The internal interfaces, those in the org.slf4j.spi or org.slf4j.helpers packages, may change incompatibly. One of the most notable occasions was in the 1.6.0 release when the LocationAwareLogger interface was changed. It was done so in response to a bug report [3] filed by... Ralph. The reader will appreciate the irony. More objectively though, Ralph filed a valid bug report and the only way to fix it was by making an incompatible change in an *internal* interface. Unfortunately, given the ubiquity of SLF4J, such incompatible changes somehow manage to leak into user-space and annoy the hell out of many developers. SLF4J is designed so that the problems occurring when deploying SLF4J are obvious with obvious solutions -- SLF4J is stupid by design. (Feel free to quote.) Mark mentioned shading as a way to fix any problems with SLF4J conflicts. I am not sure if shading will work with SLF4J. Implementations must provide a class named org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder and org.slf4j.impl.StaticMDCBinder. Jason made a comment in a previous reply that said Ceki is also a committer, and will help us fix anything when necessary so that, again, we can focus on Maven and not logging. http://people.apache.org/committer-index.html doesn't list him as a committer on Maven and Ceki has said publicly and privately that he is unlikely to contribute to ASF projects. However, while the statement is incorrect I don't understand why what Ceki would or wouldn't do would have any bearing on whether Maven adopts SLF4J. If need be, I'll happily answer questions and guide you through the process of migrating to SLF4J. However, I agree with Ralph, my person should have no bearing to whether Maven adopts SLF4J or not. Finally, I've been working on Log4j 2 for over 3 years now. The reason I started working on it was due to deficiencies in Logback that occur in large scale web applications and probably don't matter in something like Maven. But it would be nice to allow the end user the ability to swap out the logging implementation if they want. Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. In my not so humble opinion, all other questions are moot if you don't have a working policy for swapping-in/swapping-out logging frameworks. Lacking the necessary knowledge about how Maven bootstraps itself or how it manages its classloaders, I am not in a position to formulate such policy. On the other hand, there is more than enough expert knowledge here to address this problem. I intend to follow your future discussions with interest. [1] http://www.slf4j.org/manual.html#compatibility [2] http://www.slf4j.org/codes.html#version_mismatch [3] http://bugzilla.slf4j.org/show_bug.cgi?id=127 -- Ceki http://tinyurl.com/proLogback - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! LieGrue, strub PS: there is a _huge_ difference whether you like to use a logging framework in a container or in an end-user application. In a container you just don't know what the user will throw into your container. And we did tried SLF4J for containers a few times and did hit those fundamental problems pretty early on. I'm pretty sure you know exactly what I mean. Others can grab the MyFaces, tomcat, OpenWebBeans, OpenJPA, ... lists for more info. Most time we either ended up doing our own logging facade or used JUL (yea it sucks big times, but at least it doesn't create classpath conflicts). - Original Message - From: ceki c...@qos.ch To: Maven Developers List dev@maven.apache.org Cc: Sent: Monday, September 10, 2012 12:39 PM Subject: Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/] On Sep 9, 2012 8:08:34 pm, Ralh Goers wrote: First, I also would recommend moving from plexus logging to SLF4J. Cool. Mark's concerns with incompatibilities only come about with the log4j bridge if you are trying to use APis that the SLF4J bridge hasn't implemented. Something being used in a plugin really shouldn't be using those. Exactly. Although Ceki is generally careful not to break compatibility, it has happened. For example, you cannot mix applications that use SLF4J 1.6.x with code that uses SLF4J 1.5.x. Likewise, Logback is very much tied to the SLF4J version. See http://www.slf4j.org/news.html. If core is using SLF4J and an incompatible change is made again it probably won't be that big of a deal. Typically, when compatibility has been broken it really hasn't impacted code that uses the SLF4J API. SLF4J's user facing API, that is classes or interfaces located in the org.slf4j package such as Logger, Marker, MDC and LoggerFactory have been there and remain unchanged since day one (2005). Thus, a user never has to worry about with which version of slf4j-api a dependency was compiled with. A user can pick any version of slf4j-api-api.jar and as long as the version of the binding of her choice matches, slf4j will function correctly. See also [1,2]. The internal interfaces, those in the org.slf4j.spi or org.slf4j.helpers packages, may change incompatibly. One of the most notable occasions was in the 1.6.0 release when the LocationAwareLogger interface was changed. It was done so in response to a bug report [3] filed by... Ralph. The reader will appreciate the irony. More objectively though, Ralph filed a valid bug report and the only way to fix it was by making an incompatible change in an *internal* interface. Unfortunately, given the ubiquity of SLF4J, such incompatible changes somehow manage to leak into user-space and annoy the hell out of many developers. SLF4J is designed so that the problems occurring when deploying SLF4J are obvious with obvious solutions -- SLF4J is stupid by design. (Feel free to quote.) Mark mentioned shading as a way to fix any problems with SLF4J conflicts. I am not sure if shading will work with SLF4J. Implementations must provide a class named org.slf4j.impl.StaticLoggerBinder, org.slf4j.impl.StaticMarkerBinder and org.slf4j.impl.StaticMDCBinder. Jason made a comment in a previous reply that said Ceki is also a committer, and will help us fix anything when necessary so that, again, we can focus on Maven and not logging. http://people.apache.org/committer-index.html doesn't list him as a committer on Maven and Ceki has said publicly and privately that he is unlikely to contribute to ASF projects. However, while the statement is incorrect I don't understand why what Ceki would or wouldn't do would have any bearing on whether Maven adopts SLF4J. If need be, I'll happily answer questions and guide you through the process of migrating to SLF4J. However, I agree with Ralph, my person should have no bearing to whether Maven adopts SLF4J or not. Finally, I've been working on Log4j 2 for
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
Mark, I hope I did not convey the wrong message in my previous email. Commit r1380105 provides a backward compatible way for existing Maven plug-ins to continue using org.codehaus.plexus.Logger. The said Plexus logger would delegate to org.slf4j.Logger to perform actual logging. By a policy for swapping out logging back-ends, I meant formulating a policy leveraging SLF4J's own binding mechanism within Maven. For the purposes of this discussion), if slf4j-simple.jar is the default logging back-end in Maven, Maven's logging pluggability policy for switching to j.u.l. could be as straightforward as removing slf4j-simple.jar from $MAVEN_HOME/lib and replacing it with slf4j-jul.jar in $MAVEN_HOME/lib. Switching to log4j would entail replacing slf4j-jul.jar with slf4j-log4j12.jar and log4j.jar in $MAVEN_HOME/lib. Switching logback would mean replacing slf4j-log4j12.jar and log4j.jar with logback-core.jar and logback-classic.jar in $MAVEN_HOME/lib. You get the idea. As mentioned in my previous message, I don't know if the above would work due to my ignorance of exactly how Maven bootstraps. As for exporting SLF4J to Maven plug-ins, you are correct to observe that this would tie Maven to the SLF4J API. In my undeniably biased view, attempts at mitigating such coupling invariably yield poor results. Please see for further discussion. http://www.slf4j.org/faq.html#optional_dependency http://tinyurl.com/soWrapping On 10.09.2012 13:06, Mark Struberg wrote: Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! PS: there is a _huge_ difference whether you like to use a logging framework in a container or in an end-user application. In a container you just don't know what the user will throw into your container. And we did tried SLF4J for containers a few times and did hit those fundamental problems pretty early on. I'm pretty sure you know exactly what I mean. Others can grab the MyFaces, tomcat, OpenWebBeans, OpenJPA, ... lists for more info. Most time we either ended up doing our own logging facade or used JUL (yea it sucks big times, but at least it doesn't create classpath conflicts). -- Ceki http://tinyurl.com/proLogback - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Followup: use the #evaluate Velocity macro in the skin Velocity emplate
Hi all guys, I invested some time on trying the upgrade and I miserably failed :( The fact is that I didn't get explicit warnings/errors, the macro was simply ignored and rendered as #evaluate String, with arguments. Can someone please, with more doxia background, help me on give a try? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 29, 2012 at 8:15 AM, Lukas Theussl ltheu...@apache.org wrote: FYI: I've had troubles trying to upgrade velocity beyond version 1.5: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 IIRC, the main problem was backward compatibility. It should be ok with current skin versions but that's not tested. HTH, -Lukas Hervé BOUTEMY wrote: Hi Simone, Velocity is a direct dependency of doxia-site-renderer [2] and maven- reporting-exec [3] and ultimately of maven-site-plugin. I had a look at m-site-p trunk sources and actual Velocity version is 1.5. For immediate tests, you can try to override Velocity dependency in your pom's m-site-p plugin configuration. And later, add a Jira issue and change dependency in m-site-p trunk if you know Velocity well and are sure this won't break actual user sites (using Velocity 1.5 implicitely). I added explicit Velocity version in r1378417. Regards, Hervé [2] http://maven.apache.org/doxia/doxia-sitetools/index.html [3] http://maven.apache.org/shared/maven-reporting-exec/ Le mardi 28 aoűt 2012 14:02:12 Simone Tripodi a écrit : Hi all guys, as per subject, before cutting the current fluido RC, Robert and I gave some tries to evaluate strings inside the skin template using the #evaluate Velocity macro[1] but with no success... I guess mainly because the used velocity engine is a previous version which doesn't support that yet, but my question is if someone can point me to the direction on how I can provide my help on performing that upgrade. TIA, all the best! -Simo [1] http://velocity.apache.org/engine/devel/vtl-reference-guide.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote: Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! You shouldn't be fine with this. When you wrap SFL4J with a facade you will lose all the stack trace info that tells you where your log events are being generated as they will all point to the facade instead of the actual code doing the logging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
Sorry - I should have added - unless your facade uses LocationAwareLogger instead of the normal Logger. Ralph On Sep 10, 2012, at 9:21 AM, Ralph Goers wrote: On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote: Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! You shouldn't be fine with this. When you wrap SFL4J with a facade you will lose all the stack trace info that tells you where your log events are being generated as they will all point to the facade instead of the actual code doing the logging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ETA] Sites on svnpubsub
Hi, Except someone complains I will start release of maven-scm-publish-plugin tomorrow. 2012/9/5 Olivier Lamy ol...@apache.org: Hi Folks, First reminder, moving site and distribution to svnpubsub is mandatory for the end of the year (the good is dist and sync are very very fast opposite to the current rsync process) As you remember, Hervé started some times ago a test site http://maventest.apache.org which is a mix of cms and simple svnpubsub tru the plugin maven-scm-publish-plugin [1]. I have recently work a bit on that and tested/improved a bit the plugin (kudo to Hervé and Benson for starting that !). Note it works on svn and git (including gh-pages github feature). I have tested that on other Apache projects (direct memory.a.o and archiva.a.o) and I think it works fine. Feel free to have a look at the documentation. My goal is to release this plugin around next week (that's why I started a scm release first as I need some fixes/features). Then I have finished importing all of the content to http://maventest.apache.org . At this point we are ok to switch to svnpubsub for sites too. BTW we will have to document more the procedure when releasing a plugin/component/project. Any questions/comments are really welcome. Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy [1] http://maven.apache.org/plugins/maven-scm-publish-plugin/ -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
wait men, we speak about maven right? how often do you configure your logs to be verbose? it is often simply [level] - message other usages are advanced (an user will never activate it - i agree when you dev you can but dev are not targeted users IMO?) so for such a simple need whatever framework you use will be fine no? *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/9/10 Ralph Goers ralph.go...@dslextreme.com Sorry - I should have added - unless your facade uses LocationAwareLogger instead of the normal Logger. Ralph On Sep 10, 2012, at 9:21 AM, Ralph Goers wrote: On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote: Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! You shouldn't be fine with this. When you wrap SFL4J with a facade you will lose all the stack trace info that tells you where your log events are being generated as they will all point to the facade instead of the actual code doing the logging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Followup: use the #evaluate Velocity macro in the skin Velocity emplate
Hi Simone, I will try to have a look if you create a JIRA with a test project that I can play with. No promises though, my velocity skills are quite rusty by now... -Lukas Simone Tripodi wrote: Hi all guys, I invested some time on trying the upgrade and I miserably failed :( The fact is that I didn't get explicit warnings/errors, the macro was simply ignored and rendered as #evaluate String, with arguments. Can someone please, with more doxia background, help me on give a try? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Aug 29, 2012 at 8:15 AM, Lukas Theussl ltheu...@apache.org wrote: FYI: I've had troubles trying to upgrade velocity beyond version 1.5: http://jira.codehaus.org/browse/DOXIASITETOOLS-39 IIRC, the main problem was backward compatibility. It should be ok with current skin versions but that's not tested. HTH, -Lukas Hervé BOUTEMY wrote: Hi Simone, Velocity is a direct dependency of doxia-site-renderer [2] and maven- reporting-exec [3] and ultimately of maven-site-plugin. I had a look at m-site-p trunk sources and actual Velocity version is 1.5. For immediate tests, you can try to override Velocity dependency in your pom's m-site-p plugin configuration. And later, add a Jira issue and change dependency in m-site-p trunk if you know Velocity well and are sure this won't break actual user sites (using Velocity 1.5 implicitely). I added explicit Velocity version in r1378417. Regards, Hervé [2] http://maven.apache.org/doxia/doxia-sitetools/index.html [3] http://maven.apache.org/shared/maven-reporting-exec/ Le mardi 28 aoűt 2012 14:02:12 Simone Tripodi a écrit : Hi all guys, as per subject, before cutting the current fluido RC, Robert and I gave some tries to evaluate strings inside the skin template using the #evaluate Velocity macro[1] but with no success... I guess mainly because the used velocity engine is a previous version which doesn't support that yet, but my question is if someone can point me to the direction on how I can provide my help on performing that upgrade. TIA, all the best! -Simo [1] http://velocity.apache.org/engine/devel/vtl-reference-guide.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - 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 - 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 implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
Yep lots of people mess this up big time... I should know having ended up writing my own logging adapter at one point in time... The only api that came close to offering all the required features was slf4j... And the missing features were in my view less optimal and largely driven by the telecoms architect's policy doc... I18nized logs for info and higher is a bit nuts... And can kill perf (as you need the ability to reorder the positional params which slf4j's performance impl prevents) Mark I humbly think you are arguing in a hole... But feel free to enlighten me with a good reason On Monday, 10 September 2012, Ralph Goers wrote: Sorry - I should have added - unless your facade uses LocationAwareLogger instead of the normal Logger. Ralph On Sep 10, 2012, at 9:21 AM, Ralph Goers wrote: On Sep 10, 2012, at 7:06 AM, Mark Struberg wrote: Absolutely. In light of commit r1380105, the next step is for you (Maven folks) to formulate a policy for swapping out logging back-ends. Well that is what this is all about. And we have this solution available in Maven since 2004. There is already a logging facade which is widely used: org.codehaus.plexus.Logger This is used in whole Maven including all plugins which exist. All Maven messages get routed through it. I just see no reason for swapping out A1 for A2. At least not if A1 is working for years and all the Maven APIs are using it. I'm talking about 100 API signatures we would need to change in an incompatible way sooner or later! I'm perfectly fine to back the plexus.Logger facade with SLF4J as default impl, but please let's not get this into our API or export it to users! You shouldn't be fine with this. When you wrap SFL4J with a facade you will lose all the stack trace info that tells you where your log events are being generated as they will all point to the facade instead of the actual code doing the logging. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
There are people who embed Maven, and they are likely to find it congenial that they can make it talk to the logging framework of their choice by dropping in slf4j-X as needed. For the ordinary command-line, Jason and I and others think that we just pick a backend, put the appropriate jar into M2_HOME/lib, and set up a reasonable default configuration, suitable tweaked by -X. Yes, we could do like CXF and have our own -- arguably, we already do, with Plexus. (Mark's point, I think.) CXF has particular discontents with slf4J related to I18N that Maven has never cared about. My view is that SLF4J has become so ubiquitous that the number of people who will find it congenial will overwhelm the number of people who find it inconvenient or problematic. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
the simplest possible maven plugin, sort of
In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: SLF4J implementation [was Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/or
On Sep 10, 2012, at 8:04 AM, Benson Margulies wrote: There are people who embed Maven, and they are likely to find it congenial that they can make it talk to the logging framework of their choice by dropping in slf4j-X as needed. For the ordinary command-line, Jason and I and others think that we just pick a backend, put the appropriate jar into M2_HOME/lib, and set up a reasonable default configuration, suitable tweaked by -X. Yes, we could do like CXF and have our own -- arguably, we already do, with Plexus. (Mark's point, I think.) CXF has particular discontents with slf4J related to I18N that Maven has never cared about. My view is that SLF4J has become so ubiquitous that the number of people who will find it congenial will overwhelm the number of people who find it inconvenient or problematic. Yes, I think that's the conclusion that most come to. I think most of us agree that SLF4J is the best choice for a logging facade. That said I will finish off my branch to route everything via SLF4J. I will also write up how to swap out the logging implementation but to start I will just put in slf4j-simple. I'm not picky about the implementation because it's easy to change the simple implementation is the closest to the behaviour that's there now. I just need to sort out how to flip over to a file when that command line option is set and then I'll be finished. I'll do this tonight. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
Re: the simplest possible maven plugin, sort of
On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. Dan On a related front, have any readers used any of the 'not in java' plugin development support, such as bsh? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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: the simplest possible maven plugin, sort of
On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud
Re: the simplest possible maven plugin, sort of
I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
plugin-plugin 1 (or 3), me 0
My plugin has an @Mojo on itself. I'm so far failing to figure out what I'm missing. INFO] --- maven-plugin-plugin:3.1:descriptor (default-descriptor) @ r4dws-client-codegen-maven-plugin --- ... [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.952s [INFO] Finished at: Mon Sep 10 15:11:58 EDT 2012 [INFO] Final Memory: 17M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.1:descriptor (default-descriptor) on project r4dws-client-codegen-maven-plugin: Error extracting plugin descriptor: 'No mojo definitions were found for plugin: com.basistech.rlp:r4dws-client-codegen-maven-plugin.' - [Help 1] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin-plugin 1 (or 3), me 0
Did you apply exactly pom sample from http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html ? 2012/9/10 Benson Margulies bimargul...@gmail.com: My plugin has an @Mojo on itself. I'm so far failing to figure out what I'm missing. INFO] --- maven-plugin-plugin:3.1:descriptor (default-descriptor) @ r4dws-client-codegen-maven-plugin --- ... [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.952s [INFO] Finished at: Mon Sep 10 15:11:58 EDT 2012 [INFO] Final Memory: 17M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.1:descriptor (default-descriptor) on project r4dws-client-codegen-maven-plugin: Error extracting plugin descriptor: 'No mojo definitions were found for plugin: com.basistech.rlp:r4dws-client-codegen-maven-plugin.' - [Help 1] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: plugin-plugin 1 (or 3), me 0
On Mon, Sep 10, 2012 at 3:25 PM, Olivier Lamy ol...@apache.org wrote: Did you apply exactly pom sample from http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using-annotations.html Sadly, I did not. I thought I did, but I was wrong. Now I'm fine. ? 2012/9/10 Benson Margulies bimargul...@gmail.com: My plugin has an @Mojo on itself. I'm so far failing to figure out what I'm missing. INFO] --- maven-plugin-plugin:3.1:descriptor (default-descriptor) @ r4dws-client-codegen-maven-plugin --- ... [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 3.952s [INFO] Finished at: Mon Sep 10 15:11:58 EDT 2012 [INFO] Final Memory: 17M/81M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:3.1:descriptor (default-descriptor) on project r4dws-client-codegen-maven-plugin: Error extracting plugin descriptor: 'No mojo definitions were found for plugin: com.basistech.rlp:r4dws-client-codegen-maven-plugin.' - [Help 1] - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - 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: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/
Perso due to this change I'm more for a 3.1 (it's just a matter of jiras bulk change :-) ) 2012/9/9 Robert Scholte rfscho...@apache.org: It looks to me the changes fit more a 3.0.5 I always had in mind, that with the 3.1 we would make the pom-parser more strict meaning: - don't warn but fail for plugins without versions - don't warn but fail for duplicate dependency entries (there are probably more...) Robert Op Sun, 09 Sep 2012 12:31:06 +0200 schreef Anders Hammar and...@hammar.net: Anyone -1 of bumping to v3.1 for core? /Anders On Sat, Sep 8, 2012 at 9:39 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 on bump to 3.1 On Friday, 7 September 2012, Anders Hammar wrote: I know. But there wasn't much visible change in v3.0 either. And I'm thinking that it would be easier to communicate a dependency on Maven 3.1+ than 3.0.5+ if some component utilizes the JSR330 support. Version numbers are cheap. Why not bump and get some attention? :-) /Anders On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl ja...@tesla.io wrote: There are no visible user changes, so I don't think so. There aren't even any changes to integrators unless they want to use take advantage of the changes. On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote: Maybe this even should bump the version to v3.1? /Anders On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy ol...@apache.org wrote: Maybe I miss something but we don't have any associated jira entry for reference in release notes neither core it test. Do you have a bit of time for that ? Thanks -- Olivier 2012/9/3 jvan...@apache.org: Author: jvanzyl Date: Mon Sep 3 01:07:31 2012 New Revision: 1380105 URL: http://svn.apache.org/viewvc?rev=1380105view=rev Log: o Enabled support and discovery of JSR-330 components o Added Slf4j logger factory to support generic JSR-330 logging o Exported Guice package for components that access Guice (or better it's injector) directly Widen export of Guice packages (not ideal, need to look into ways to avoid this) o use specific exports o for now we will attempt to hide all of Guice in plugin realms and we'll do a bit of testing closes #3 Added: maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLogger.java maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLoggerFactory.java Modified: maven/maven-3/trunk/apache-maven/pom.xml maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java maven/maven-3/trunk/maven-embedder/pom.xml maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/apache-maven/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/apache-maven/pom.xml?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/apache-maven/pom.xml (original) +++ maven/maven-3/trunk/apache-maven/pom.xml Mon Sep 3 01:07:31 2012 @@ -83,6 +83,10 @@ groupIdorg.sonatype.aether/groupId artifactIdaether-connector-wagon/artifactId /dependency +dependency + groupIdorg.slf4j/groupId + artifactIdslf4j-nop/artifactId +/dependency /dependencies build Modified: maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff - 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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/
+1 for 3.1 On 2012-09-07 22:19, Anders Hammar wrote: I know. But there wasn't much visible change in v3.0 either. And I'm thinking that it would be easier to communicate a dependency on Maven 3.1+ than 3.0.5+ if some component utilizes the JSR330 support. Version numbers are cheap. Why not bump and get some attention? :-) /Anders On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl ja...@tesla.io wrote: There are no visible user changes, so I don't think so. There aren't even any changes to integrators unless they want to use take advantage of the changes. On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote: Maybe this even should bump the version to v3.1? /Anders On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy ol...@apache.org wrote: Maybe I miss something but we don't have any associated jira entry for reference in release notes neither core it test. Do you have a bit of time for that ? Thanks -- Olivier 2012/9/3 jvan...@apache.org: Author: jvanzyl Date: Mon Sep 3 01:07:31 2012 New Revision: 1380105 URL: http://svn.apache.org/viewvc?rev=1380105view=rev Log: o Enabled support and discovery of JSR-330 components o Added Slf4j logger factory to support generic JSR-330 logging o Exported Guice package for components that access Guice (or better it's injector) directly Widen export of Guice packages (not ideal, need to look into ways to avoid this) o use specific exports o for now we will attempt to hide all of Guice in plugin realms and we'll do a bit of testing closes #3 Added: maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLogger.java maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLoggerFactory.java Modified: maven/maven-3/trunk/apache-maven/pom.xml maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java maven/maven-3/trunk/maven-embedder/pom.xml maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/apache-maven/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/apache-maven/pom.xml?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/apache-maven/pom.xml (original) +++ maven/maven-3/trunk/apache-maven/pom.xml Mon Sep 3 01:07:31 2012 @@ -83,6 +83,10 @@ groupIdorg.sonatype.aether/groupId artifactIdaether-connector-wagon/artifactId /dependency +dependency + groupIdorg.slf4j/groupId + artifactIdslf4j-nop/artifactId +/dependency /dependencies build Modified: maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + +// javax.inject, sisu-inject (JSR-330) +imports.put( javax.inject.*, coreRealm ); +imports.put( javax.enterprise.inject.*, coreRealm ); +imports.put( org.sonatype.inject.*, coreRealm ); +imports.put( org.slf4j.*, coreRealm ); + +// com.google +// +// We may potentially want to export these, but right now I'm not sure that anything Guice specific needs +// to be made available to plugin authors. If we find people are getting fancy and want to take advantage +// of Guice specifics we can expose that later. Really some testing needs to be done to see full hiding +// of Guice has any impact on what we may categorize as a standard JSR-330 based Tesla/Maven plugin. +// +// imports.put( com.google.inject.*, coreRealm ); +// imports.put( com.google.inject.binder.*, coreRealm ); +// imports.put( com.google.inject.matcher.*, coreRealm ); +// imports.put( com.google.inject.name.*, coreRealm ); +// imports.put( com.google.inject.spi.*, coreRealm ); +// imports.put( com.google.inject.util.*, coreRealm ); } /** Modified: maven/maven-3/trunk/maven-embedder/pom.xml URL:
Preparing a release of Changes Plugin
Hi I've been working my way towards a release of the Changes Plugin. Now I'm all done. Unless someone has anything really urgent I'll start the release process soon. There are other projects depending on a release because of http://jira.codehaus.org/browse/MCHANGES-285 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1380105 - in /maven/maven-3/trunk: ./ apache-maven/ maven-core/src/main/java/org/apache/maven/classrealm/ maven-embedder/ maven-embedder/src/main/java/org/apache/maven/cli/
+1 for 3.1 On 10 September 2012 21:19, Dennis Lundberg denn...@apache.org wrote: +1 for 3.1 On 2012-09-07 22:19, Anders Hammar wrote: I know. But there wasn't much visible change in v3.0 either. And I'm thinking that it would be easier to communicate a dependency on Maven 3.1+ than 3.0.5+ if some component utilizes the JSR330 support. Version numbers are cheap. Why not bump and get some attention? :-) /Anders On Fri, Sep 7, 2012 at 10:03 PM, Jason van Zyl ja...@tesla.io wrote: There are no visible user changes, so I don't think so. There aren't even any changes to integrators unless they want to use take advantage of the changes. On Sep 7, 2012, at 4:01 PM, Anders Hammar wrote: Maybe this even should bump the version to v3.1? /Anders On Fri, Sep 7, 2012 at 5:37 PM, Olivier Lamy ol...@apache.org wrote: Maybe I miss something but we don't have any associated jira entry for reference in release notes neither core it test. Do you have a bit of time for that ? Thanks -- Olivier 2012/9/3 jvan...@apache.org: Author: jvanzyl Date: Mon Sep 3 01:07:31 2012 New Revision: 1380105 URL: http://svn.apache.org/viewvc?rev=1380105view=rev Log: o Enabled support and discovery of JSR-330 components o Added Slf4j logger factory to support generic JSR-330 logging o Exported Guice package for components that access Guice (or better it's injector) directly Widen export of Guice packages (not ideal, need to look into ways to avoid this) o use specific exports o for now we will attempt to hide all of Guice in plugin realms and we'll do a bit of testing closes #3 Added: maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLogger.java maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/PlexusLoggerFactory.java Modified: maven/maven-3/trunk/apache-maven/pom.xml maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java maven/maven-3/trunk/maven-embedder/pom.xml maven/maven-3/trunk/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/apache-maven/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/apache-maven/pom.xml?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/apache-maven/pom.xml (original) +++ maven/maven-3/trunk/apache-maven/pom.xml Mon Sep 3 01:07:31 2012 @@ -83,6 +83,10 @@ groupIdorg.sonatype.aether/groupId artifactIdaether-connector-wagon/artifactId /dependency +dependency + groupIdorg.slf4j/groupId + artifactIdslf4j-nop/artifactId +/dependency /dependencies build Modified: maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java?rev=1380105r1=1380104r2=1380105view=diff == --- maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java (original) +++ maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java Mon Sep 3 01:07:31 2012 @@ -198,6 +198,26 @@ public class DefaultClassRealmManager imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParser, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlPullParserException, coreRealm ); imports.put( org.codehaus.plexus.util.xml.pull.XmlSerializer, coreRealm ); + +// javax.inject, sisu-inject (JSR-330) +imports.put( javax.inject.*, coreRealm ); +imports.put( javax.enterprise.inject.*, coreRealm ); +imports.put( org.sonatype.inject.*, coreRealm ); +imports.put( org.slf4j.*, coreRealm ); + +// com.google +// +// We may potentially want to export these, but right now I'm not sure that anything Guice specific needs +// to be made available to plugin authors. If we find people are getting fancy and want to take advantage +// of Guice specifics we can expose that later. Really some testing needs to be done to see full hiding +// of Guice has any impact on what we may categorize as a standard JSR-330 based Tesla/Maven plugin. +// +// imports.put( com.google.inject.*, coreRealm ); +// imports.put( com.google.inject.binder.*, coreRealm ); +// imports.put( com.google.inject.matcher.*, coreRealm ); +// imports.put( com.google.inject.name.*, coreRealm ); +// imports.put( com.google.inject.spi.*, coreRealm ); +// imports.put(
Dynamically determining the currently executing goal name
I would like to dynamically determine the currently executing goal from a MOJO. I attempted this using reflection but the new annotations are not available at runtime. All other solutions I have seen appear to require access to the executing MOJO's groupId and artifactId. Anyone have a solution? Is there an issue with having the annotations available at runtime? -- View this message in context: http://maven.40175.n5.nabble.com/Dynamically-determining-the-currently-executing-goal-name-tp5721050.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the simplest possible maven plugin, sort of
Our experience in geronimo has always been that maven does not support this, and I thought for maven 3 it was announced that it never ever would. We have a proflie to build up through the plugin, then you can do the full build. Releasing is a pain as you have to do the manual profile build with the release-version code to get the plugin available in the local maven repo before running the actual release. If I'm wrong for any version of maven I'd love to know how :-) thanks david jencks On Sep 10, 2012, at 1:45 PM, Daniel Kulp wrote: Interesting… I wonder how I've managed to do CXF releases for all these years then. :-) Seriously, for CXF =2.5.x, I use Maven 2.2.1 and it just works. Parts of the build certainly do use the plugins that are built as part of the reactor. That said, we use install as the default target and not test or anything. I'm fairly certain it wouldn't work if we didn't use install as the target, but I'm not sure if that would work with 3.x either. The clean target doesn't work if the plugin is part of the reactor and not in .m2/repository. I'll give you that. Dan On Sep 10, 2012, at 2:59 PM, Anders Hammar and...@hammar.net wrote: I'm fairly sure this didn't work in Maven 2.x. It was one of the unsolvable Maven 2.x bugs which was fixed in Maven 3. The workaround would be to use an older released version of the plugin. Don't think running a build twice is/was a workable workaround as I can't see how that would work in a release process. /Anders On Mon, Sep 10, 2012 at 8:11 PM, Arnaud Héritier aherit...@gmail.com wrote: On Mon, Sep 10, 2012 at 5:30 PM, Benson Margulies bimargul...@gmail.comwrote: On Mon, Sep 10, 2012 at 11:25 AM, Daniel Kulp dk...@apache.org wrote: On Sep 10, 2012, at 11:14 AM, Benson Margulies bimargul...@gmail.com wrote: In Maven 2.x, the following was true; the reactor could not apply a plugin it had just built. So, if a particular problem required a plugin (e.g., for generating code), the plugin has to be an independent project that is built in advance. Is this still true in 3.x? I don't think this is/was true. CXF has always used it's own codegen plugins within its reactor build, even with Maven 2.x. Dan, I'll try it again, but I could have sworn that this only works by running 'mvn' twice, so that there's a SNAPSHOT in ~/.m2/repository. I'm almost sure I had the same experience like Benson. It doesn't work in one step because maven reads all projects in the reactor, then tries to resolve the plugin where you are using it and cannot because it was built. Arnaud - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - 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
