git experts: please help
I created MNG-5397 Jira issue for Use SLF4J for logging, with a classical comment to link to svn revision. I just added a link to equivalent git commit, now we're using git. One thing I used to do with svn in such a case is changing svn:log to add Jira issue reference to the revision commit log. Question: how can I do the same on actual git commit, now that svn is RO? Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: git experts: please help
You can't. Once a commit has been pushed there's no change that can be done. In practice, if you want the 2-way reference, you need to add the jira-reference to the commit up-front with the classical [MNG-5379] prefix in the message. Kristia 2012/12/2 Hervé BOUTEMY herve.bout...@free.fr: I created MNG-5397 Jira issue for Use SLF4J for logging, with a classical comment to link to svn revision. I just added a link to equivalent git commit, now we're using git. One thing I used to do with svn in such a case is changing svn:log to add Jira issue reference to the revision commit log. Question: how can I do the same on actual git commit, now that svn is RO? Regards, Hervé - 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: git experts: please help
Hello, you could use git notes http://git-scm.com/2010/08/25/notes.html for this. Regards Mirko -- Sent from my mobile On Dec 2, 2012 9:42 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: You can't. Once a commit has been pushed there's no change that can be done. In practice, if you want the 2-way reference, you need to add the jira-reference to the commit up-front with the classical [MNG-5379] prefix in the message. Kristia 2012/12/2 Hervé BOUTEMY herve.bout...@free.fr: I created MNG-5397 Jira issue for Use SLF4J for logging, with a classical comment to link to svn revision. I just added a link to equivalent git commit, now we're using git. One thing I used to do with svn in such a case is changing svn:log to add Jira issue reference to the revision commit log. Question: how can I do the same on actual git commit, now that svn is RO? Regards, Hervé - 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: git experts: please help
yes, that would do the job: great! But the article explains lots of problems to effectively use this on a shared repository: do you know if it's ok with actual git version (1.7.*) and Apache setup? (notice: I'm using git through my IDE which doesn't tell anything about notes) Regards, Hervé Le dimanche 2 décembre 2012 09:53:24 Mirko Friedenhagen a écrit : Hello, you could use git notes http://git-scm.com/2010/08/25/notes.html for this. Regards Mirko You can't. Once a commit has been pushed there's no change that can be done. In practice, if you want the 2-way reference, you need to add the jira-reference to the commit up-front with the classical [MNG-5379] prefix in the message. Kristia 2012/12/2 Hervé BOUTEMY herve.bout...@free.fr: I created MNG-5397 Jira issue for Use SLF4J for logging, with a classical comment to link to svn revision. I just added a link to equivalent git commit, now we're using git. One thing I used to do with svn in such a case is changing svn:log to add Jira issue reference to the revision commit log. Question: how can I do the same on actual git commit, now that svn is RO? Regards, Hervé - 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: Re-spinning 3.1.0
Downloads from central in the last 12 months: Logback: 1,136,846 Log4J2: 6,748 Do you have the number for all log4j artifacts? log4j2 just got released but is a native successor of log4j1. LieGrue, strub From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Sent: Sunday, December 2, 2012 12:21 AM Subject: Re: Re-spinning 3.1.0 On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit : [1]: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2 just for side-by-side comparison: https://github.com/qos-ch/logback/graphs/contributors Cool, thanks. A couple more data points: Downloads from central in the last 12 months: Logback: 1,136,846 Log4J2: 6,748 Projects integrating Logback: http://logback.qos.ch 8 of which are Apache projects - 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 - We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: git experts: please help
Hervé, I have not used this yet. However it seems mostly merging would be a problem. Just annotating commits in the appropriate Jira/Ticket namespace will probably run seldomly into this situation. Normally I would put the ticket into the summary line as well. Regards Mirko -- Sent from my mobile On Dec 2, 2012 10:15 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: yes, that would do the job: great! But the article explains lots of problems to effectively use this on a shared repository: do you know if it's ok with actual git version (1.7.*) and Apache setup? (notice: I'm using git through my IDE which doesn't tell anything about notes) Regards, Hervé Le dimanche 2 décembre 2012 09:53:24 Mirko Friedenhagen a écrit : Hello, you could use git notes http://git-scm.com/2010/08/25/notes.html for this. Regards Mirko You can't. Once a commit has been pushed there's no change that can be done. In practice, if you want the 2-way reference, you need to add the jira-reference to the commit up-front with the classical [MNG-5379] prefix in the message. Kristia 2012/12/2 Hervé BOUTEMY herve.bout...@free.fr: I created MNG-5397 Jira issue for Use SLF4J for logging, with a classical comment to link to svn revision. I just added a link to equivalent git commit, now we're using git. One thing I used to do with svn in such a case is changing svn:log to add Jira issue reference to the revision commit log. Question: how can I do the same on actual git commit, now that svn is RO? Regards, Hervé - 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
Modernizing IT's in core (and elsewhere ?)
Some time ago, I modernized the surefire IT's using a builder on top of Verifier. I think they are much simpler and more concise than they used to be. Typical samples can be seen here; https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire907PerThreadWithoutThreadCountIT.java https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire628ConsoleOutputBeforeAndAfterClassIT.java https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire809GroupExpressionsIT.java Now I just worked on an IT for MNG-5208 and I must admit I felt the step back to old-school verifier tests feels painful. The test can be seen at https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5208EventSpyParallelTest.java I would like to do something about the core it's, maybe define a simpler standard for newer tests. I'm really just seeking input on this ;) I think there are a number of issues even with my revised tests. As can be seen the signal to noise ratio becomes worse than ever; while the test can be precisely expressed as a one-liner, we consistently add 35 lines of java boiler-plate including license header. The builder I made for surefire could be generalized and moved into verifier; I'm really interested in both feedback and other pointers to nice ways this has been solved.. Maybe I'm missing something big ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re-spinning 3.1.0
I can run a query. I would be fine using Log4J1. Well used in the field and I doubt there would be any surprises. No one suggested using it, but I think that's a more sensible choice than a project no one uses. I don't see much value in being on the bleeding edge of a logging project. On Dec 2, 2012, at 1:20 AM, Mark Struberg strub...@yahoo.de wrote: Downloads from central in the last 12 months: Logback: 1,136,846 Log4J2: 6,748 Do you have the number for all log4j artifacts? log4j2 just got released but is a native successor of log4j1. LieGrue, strub From: Jason van Zyl ja...@tesla.io To: Maven Developers List dev@maven.apache.org Sent: Sunday, December 2, 2012 12:21 AM Subject: Re: Re-spinning 3.1.0 On Dec 1, 2012, at 3:11 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 1 décembre 2012 10:08:21 Jason van Zyl a écrit : [1]: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2 just for side-by-side comparison: https://github.com/qos-ch/logback/graphs/contributors Cool, thanks. A couple more data points: Downloads from central in the last 12 months: Logback: 1,136,846 Log4J2: 6,748 Projects integrating Logback: http://logback.qos.ch 8 of which are Apache projects - 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 - We all have problems. How we deal with them is a measure of our worth. -- Unknown - 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 - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: Modernizing IT's in core (and elsewhere ?)
On Dec 2, 2012, at 5:48 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Some time ago, I modernized the surefire IT's using a builder on top of Verifier. I think they are much simpler and more concise than they used to be. Typical samples can be seen here; https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire907PerThreadWithoutThreadCountIT.java https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire628ConsoleOutputBeforeAndAfterClassIT.java https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire809GroupExpressionsIT.java Now I just worked on an IT for MNG-5208 and I must admit I felt the step back to old-school verifier tests feels painful. The test can be seen at https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5208EventSpyParallelTest.java I would like to do something about the core it's, maybe define a simpler standard for newer tests. I'm really just seeking input on this ;) I think there are a number of issues even with my revised tests. As can be seen the signal to noise ratio becomes worse than ever; while the test can be precisely expressed as a one-liner, we consistently add 35 lines of java boiler-plate including license header. The builder I made for surefire could be generalized and moved into verifier; I'm really interested in both feedback and other pointers to nice ways this has been solved.. Maybe I'm missing something big ;) I think the way the ITs used to work was better. Where a single project was entirely self-contained and there was a declarative file that described the desired outputs. They couldn't not be run in an IDE but I think that could be fixed. The problem with the current setup is that they are impenetrable for anyone who might want to contribute. I can count on one hand the number of ITs contributed by outsiders. Imagine if a single unit test was a completely self contained project and we used something like JBehave so that someone could describe the desired output given the POM for the test project? I still think that we need to be able to debug and run from the IDE but we can probably make a custom test running. I would not change any of the existing tests, but if you wanted to use your builder and it makes the test more succinct go for it. Kristian - 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 - We all have problems. How we deal with them is a measure of our worth. -- Unknown
Re: Modernizing IT's in core (and elsewhere ?)
2012/12/2 Jason van Zyl ja...@tesla.io: I think the way the ITs used to work was better. Where a single project was entirely self-contained and there was a declarative file that described the desired outputs. Well I think this is one of the design goals I *almost* managed to achieve when I refactored the surefire IT's; the supplied test project can run with mvn clean install straight out of the box to demonstrate the problem (as described here http://maven.apache.org/surefire/maven-surefire-plugin/developing.html). (This is where I think invoker fails miserably). In surefire I did this by using the system properties for the plugin parameters as well as defining standard properties in the poms for all the props without predefined -D values. Writing the actual IT to do the assertion is a walk in the park, and there's a quite high percentage of surefire patches that actually contain well-functioning IT's. (This may be related to personal beliefs of anyone submitting patches to a test framework ;) The core IT's are probably the most complex ITs in all of maven. They are still not *that* much more complex than the surefire IT's used to be, where the simplification seems to have paid off well. The effort of rewriting may not be worth it (although it was in surefire), but establishing a clear norm for nice tests that can be documented is always a good thing. I'm no big fan of BDD frameworks like jbehave or cucumber; I think simple java based DSL's do the job better; especially with what is essentially a very limited domain like this. I like runnable junit tests that apply to real runnable projects that can be made by end users. I'm a programmer dammit ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Modernizing IT's in core (and elsewhere ?)
I think trying anything new that's easier is good. The only thing we need to be cognizant of is making sure the body of ITs work to test all the versions of Maven. But I think project self-containment is a good goal. I just liked the setup where there was a project and a file that described the output so you could just run it with doing anything else other than setting up the project and declaratively stating what the results should be. On Dec 2, 2012, at 9:47 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: 2012/12/2 Jason van Zyl ja...@tesla.io: I think the way the ITs used to work was better. Where a single project was entirely self-contained and there was a declarative file that described the desired outputs. Well I think this is one of the design goals I *almost* managed to achieve when I refactored the surefire IT's; the supplied test project can run with mvn clean install straight out of the box to demonstrate the problem (as described here http://maven.apache.org/surefire/maven-surefire-plugin/developing.html). (This is where I think invoker fails miserably). In surefire I did this by using the system properties for the plugin parameters as well as defining standard properties in the poms for all the props without predefined -D values. Writing the actual IT to do the assertion is a walk in the park, and there's a quite high percentage of surefire patches that actually contain well-functioning IT's. (This may be related to personal beliefs of anyone submitting patches to a test framework ;) The core IT's are probably the most complex ITs in all of maven. They are still not *that* much more complex than the surefire IT's used to be, where the simplification seems to have paid off well. The effort of rewriting may not be worth it (although it was in surefire), but establishing a clear norm for nice tests that can be documented is always a good thing. I'm no big fan of BDD frameworks like jbehave or cucumber; I think simple java based DSL's do the job better; especially with what is essentially a very limited domain like this. I like runnable junit tests that apply to real runnable projects that can be made by end users. I'm a programmer dammit ;) Kristian - 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 - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
core-integration-testing-maven-3 jobs hangs
The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders
Re: Re-spinning 3.1.0
I'm going to start the preparation for rolling the release. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: core-integration-testing-maven-3 jobs hangs
Hi Anders It looks like ASF Jenkins has been upgraded to 1.492, which should help us with the unwanted constant rebuilds in some of our other projects. Which jobs are hung? I can only see one: core-integration-testing-maven-3-embedded On 2012-12-02 20:12, Anders Hammar wrote: The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core-integration-testing-maven-3 jobs hangs
Can we have a thread dump of that? K Den 2. des. 2012 kl. 21:39 skrev Dennis Lundberg denn...@apache.org: Hi Anders It looks like ASF Jenkins has been upgraded to 1.492, which should help us with the unwanted constant rebuilds in some of our other projects. Which jobs are hung? I can only see one: core-integration-testing-maven-3-embedded On 2012-12-02 20:12, Anders Hammar wrote: The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders -- Dennis Lundberg - 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: Re-spinning 3.1.0
On Sat, Dec 1, 2012 at 7:08 PM, Jason van Zyl ja...@tesla.io wrote: On Dec 1, 2012, at 1:42 AM, Arnaud Héritier aherit...@gmail.com wrote: Ok. Yes that's sure it has to be discussed. That's why I reopened the subject. About the implementation : * as a user I have really no preference, I just want the feature * as a developer I played with both and for me these are just loggers . We may organize a fight between Ceki and Ralph but it won't help I think. I agree that log4j2 is in beta which is annoying (? Or not. We are talking about a logging lib that is doing some println - but with colors ) It's not a fight Arnaud, I want the discussion to be about objective evaluation. I agree. But in fact there is from my point of view no real evaluation to do now. log4j2 is young and logback the reference implementation commonly used. * as PMC and ASF member I suppose I should say that our projects are the best and we should privilege our own stuffs for the safety of our ecosystem. That, Arnaud, is nepotism. If the single strongest selection criterion here is nepotism then I believe there is no hope for any ecosystem. If nepotism above maturity, precedent, and use in the field become subordinate to nepotism and our view of good is bounded by only what's done at Apache then I believe we are truly in decline. I believe the ecosystem goes far beyond just what exists at Apache. Being at Apache is no guarantee for success, or health -- even with its powerful marketing and, at times, irrational protectionism. How is SVN doing compared to Git? How is Apache HTTPD doing compared to NGinx? How is Mina doing compared to Netty? MyBatis is thriving outside the walls of Apache since it left, and Logback is selected everywhere even projects at Apache. There are good things at Apache, there are good things outside Apache. I see it as an irrational train of through to have to select everything from Apache. To me it smacks of a form of nationalism which I believe is unhealthy. Honestly how did Log4J2 not have to go through the incubator? There are barely more than two people who have contributed, by Incubator standards for diversity -- if you are placing high value on the Apache way -- it doesn't really cut muster. I don't think it would be allowed out of the incubator[1] would it? Compared to something like CXF which spent how long in the incubator? This looks to be a completely new project. That development on Log4J stops and that the choice is not to help work on Logback -- which is clearly the de facto standard -- but start something else to me seems unwise. To use the project that Ceki started and then stop working on that to create something to compete with a successful project that Ceki created outside of Apache just seems like some really nasty business. I see it as an attempt to legitimize a project that has no traction with a project that does. If you were going to select something at work for a critical project you were working on would you really pick Log4J2 over Logback? I honestly don't think anyone would. I don't believe the mechanics of selecting and building software in the outside world should be anything different here. At the point of selection you pick best of breed to mitigate risk and integration problems. LOL it was mainly a sarcasm this 3rd point. I should have add a smiley. For me if we had to choose now log4J2 as the implementation it could be done with this reason. I have nothing against log4J and I'm sure it will have a great future and may be a good challenger for logback. I may understand this reason to select it and I have nothing against it, nor I'm afraid about it because I'm sure that like for logback we'll have the support of the dev team. At any rate we can compare the implementations and discuss. As the RM I don't want to integrate a logging framework in 3.1.0. +1 Fine for me. [1]: http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Flogging%2Flog4j%2Flog4j2 Cheers. - Arnaud Le 1 déc. 2012 à 09:26, Jason van Zyl ja...@tesla.io a écrit : On Dec 1, 2012, at 12:17 AM, Arnaud Héritier aherit...@gmail.com wrote: Hi Jason, Couldn't we have a look at olamy's log4j2 branch to see if we could sanitize / merge it to propose at least one change for the end user and demonstrate the interest of the change about logs : a colorized console. Not without discussion about the implementation. To me the obvious choice is Logback and using Log4J2 makes no sense. Olivier disagrees so there will be a discussion. I've been working on the release but I plan to make a branch using Logback so we have a basis for discussion. I remember you did that in mvnsh/teslashell a long time ago (as an extension ?) and perhaps it could be easy to add properly this feature in 3.1.0 (otherwise it won't be before a 3.2.0). Myself I'm using a 3.1.0 fork with this patch and I' m really
Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0
I agree but sincerely I'm sure that less than 0,01% of our users will customize their logs. On Sat, Dec 1, 2012 at 9:27 PM, Anders Hammar and...@hammar.net wrote: In any case doing a choice nowadays for 3.1.0 won't prevent us to change it in the future. I really hope that the ability to switch from a logger implementation to another won't require several days of developments or I really missed something about it. Well, very likely it would affect the end users as the logger configuration would be different. And that could be confusing and also have people convert their adapted logger config files. /Anders Cheers Arnaud Regards, Hervé Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit : Hi Jason, Couldn't we have a look at olamy's log4j2 branch to see if we could sanitize / merge it to propose at least one change for the end user and demonstrate the interest of the change about logs : a colorized console. I remember you did that in mvnsh/teslashell a long time ago (as an extension ?) and perhaps it could be easy to add properly this feature in 3.1.0 (otherwise it won't be before a 3.2.0). Myself I'm using a 3.1.0 fork with this patch and I' m really satisfied (it's so good to quickly see highlighted warning and errors ). I merged it back in the last 3.1.0 tag you did without issue Wdyt? - Arnaud Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a écrit : I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0. Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different. I'll wait until tomorrow to re-spin. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: core-integration-testing-maven-3 jobs hangs
It's the core-integration-testing-maven-3 job that hangs. I've aborted it a few times hoping it would fix itself somehow. No luck though. Also, there's some problems with Jenkins not finding git installation on some nodes. But that's a different topic, but possibly related to the upgrade? /Anders On Sun, Dec 2, 2012 at 9:38 PM, Dennis Lundberg denn...@apache.org wrote: Hi Anders It looks like ASF Jenkins has been upgraded to 1.492, which should help us with the unwanted constant rebuilds in some of our other projects. Which jobs are hung? I can only see one: core-integration-testing-maven-3-embedded On 2012-12-02 20:12, Anders Hammar wrote: The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0
Thanks a lot to have pushed it. I tested it with success I like it, at least something that will improve the user experience soon. Note : Like Olivier's branch the default logging setup has an issue because the default color is set to black (or white) which are backgrounds colors commonly used. This is something we'll have to take care. The best should be to not touch the default foreground color for INFO level and just add colors for others levels. Cheers, On Sat, Dec 1, 2012 at 6:47 PM, Jason van Zyl ja...@tesla.io wrote: I already have started a logback version, but I don't think this should affect rolling the 3.1.0. On Dec 1, 2012, at 6:57 AM, Arnaud Héritier aherit...@gmail.com wrote: I pushed the prototype developed by olivier using log4j2 in the branch feature/colorized-console/log4j2 I updated with latest master changes You can test the distro of this code : http://cl.ly/1B1z051O0T10 Tonight I'll try to do a logback version cheers Arnaud On Sat, Dec 1, 2012 at 11:15 AM, Arnaud Héritier aherit...@gmail.com wrote: On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: I just created and fixed MNG-5395 and MNG-5396, which are logger names enhancements from the actual values that will give value even with slf4j- simple These should be a starting point for more global discussion about our logging conventions then fixed in our global codebase, since IMHO, these issues show how we didn't use the logger names until now then we have a lot of place where our logging pratice is not good Of course, I'm interested in colorized output, but since it has impact on logging implementation choice, which will require a strong discussion, this can't be done for the moment :| A strong discussion ? seriously ? We have 3 choices from my point of view : * We do nothing, we keep the slf4j-simple * We choose logback which is mature and used by a lot of people. Nowadays from my point of view it is the reference implementation * We choose log4j2 which is really promising but always in beta. But we may do this political to support this project which is rising from the ashes (http://logging.apache.org/log4j/2.x/manual/index.html) In any case doing a choice nowadays for 3.1.0 won't prevent us to change it in the future. I really hope that the ability to switch from a logger implementation to another won't require several days of developments or I really missed something about it. Cheers Arnaud Regards, Hervé Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit : Hi Jason, Couldn't we have a look at olamy's log4j2 branch to see if we could sanitize / merge it to propose at least one change for the end user and demonstrate the interest of the change about logs : a colorized console. I remember you did that in mvnsh/teslashell a long time ago (as an extension ?) and perhaps it could be easy to add properly this feature in 3.1.0 (otherwise it won't be before a 3.2.0). Myself I'm using a 3.1.0 fork with this patch and I' m really satisfied (it's so good to quickly see highlighted warning and errors ). I merged it back in the last 3.1.0 tag you did without issue Wdyt? - Arnaud Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a écrit : I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0. Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different. I'll wait until tomorrow to re-spin. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl
Re: Colorized console and logging implementation choice was Re: Re-spinning 3.1.0
+1 I don't think we'll have another minor release before the end of the year. For sure it won't be included in a bug fix release. We already release a minor release without (or so few) end-user value, we won't start to add new feature in a bug fix release :-) Arnaud On Sat, Dec 1, 2012 at 7:33 PM, Benson Margulies bimargul...@gmail.comwrote: OK, 3.1.1 or 3.1-m2 or whatever before Christmas. Let's get this fish out of the store and move on to the next one. On Sat, Dec 1, 2012 at 1:31 PM, Gary Gregory garydgreg...@gmail.com wrote: Oh do please give us a color console for Christmas :) Gary On Dec 1, 2012, at 12:47, Jason van Zyl ja...@tesla.io wrote: I already have started a logback version, but I don't think this should affect rolling the 3.1.0. On Dec 1, 2012, at 6:57 AM, Arnaud Héritier aherit...@gmail.com wrote: I pushed the prototype developed by olivier using log4j2 in the branch feature/colorized-console/log4j2 I updated with latest master changes You can test the distro of this code : http://cl.ly/1B1z051O0T10 Tonight I'll try to do a logback version cheers Arnaud On Sat, Dec 1, 2012 at 11:15 AM, Arnaud Héritier aherit...@gmail.com wrote: On Sat, Dec 1, 2012 at 9:40 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: I just created and fixed MNG-5395 and MNG-5396, which are logger names enhancements from the actual values that will give value even with slf4j- simple These should be a starting point for more global discussion about our logging conventions then fixed in our global codebase, since IMHO, these issues show how we didn't use the logger names until now then we have a lot of place where our logging pratice is not good Of course, I'm interested in colorized output, but since it has impact on logging implementation choice, which will require a strong discussion, this can't be done for the moment :| A strong discussion ? seriously ? We have 3 choices from my point of view : * We do nothing, we keep the slf4j-simple * We choose logback which is mature and used by a lot of people. Nowadays from my point of view it is the reference implementation * We choose log4j2 which is really promising but always in beta. But we may do this political to support this project which is rising from the ashes (http://logging.apache.org/log4j/2.x/manual/index.html) In any case doing a choice nowadays for 3.1.0 won't prevent us to change it in the future. I really hope that the ability to switch from a logger implementation to another won't require several days of developments or I really missed something about it. Cheers Arnaud Regards, Hervé Le samedi 1 décembre 2012 09:17:52 Arnaud Héritier a écrit : Hi Jason, Couldn't we have a look at olamy's log4j2 branch to see if we could sanitize / merge it to propose at least one change for the end user and demonstrate the interest of the change about logs : a colorized console. I remember you did that in mvnsh/teslashell a long time ago (as an extension ?) and perhaps it could be easy to add properly this feature in 3.1.0 (otherwise it won't be before a 3.2.0). Myself I'm using a 3.1.0 fork with this patch and I' m really satisfied (it's so good to quickly see highlighted warning and errors ). I merged it back in the last 3.1.0 tag you did without issue Wdyt? - Arnaud Le 1 déc. 2012 à 00:20, Jason van Zyl ja...@tesla.io a écrit : I'm done with the issues that cropped up so I'm ready to re-spin 3.1.0. Anyone want to add anything or discuss anything before I spin this? I'm not in any rush so if folks want to talk about logging we can. But given the fact once SLF4J initializes it can't change the implementation plugins integrating with Maven need to use the implementation we choose. This is how everything else in the world that integrates SLF4J has to operate so I don't really see us being any different. I'll wait until tomorrow to re-spin. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier Thanks,
Re: core-integration-testing-maven-3 jobs hangs
On 2012-12-02 22:01, Anders Hammar wrote: It's the core-integration-testing-maven-3 job that hangs. I've aborted it a few times hoping it would fix itself somehow. No luck though. Also, there's some problems with Jenkins not finding git installation on some nodes. But that's a different topic, but possibly related to the upgrade? If you mean the Windows node, I've already asked about that on builds@a.o but haven't gotten a reply yet. /Anders On Sun, Dec 2, 2012 at 9:38 PM, Dennis Lundberg denn...@apache.org wrote: Hi Anders It looks like ASF Jenkins has been upgraded to 1.492, which should help us with the unwanted constant rebuilds in some of our other projects. Which jobs are hung? I can only see one: core-integration-testing-maven-3-embedded On 2012-12-02 20:12, Anders Hammar wrote: The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core-integration-testing-maven-3 jobs hangs
The Windows node is one, but I believe I saw the same problem on some other node as well. /Anders (mobile) Den 2 dec 2012 22:37 skrev Dennis Lundberg denn...@apache.org: On 2012-12-02 22:01, Anders Hammar wrote: It's the core-integration-testing-maven-3 job that hangs. I've aborted it a few times hoping it would fix itself somehow. No luck though. Also, there's some problems with Jenkins not finding git installation on some nodes. But that's a different topic, but possibly related to the upgrade? If you mean the Windows node, I've already asked about that on builds@a.o but haven't gotten a reply yet. /Anders On Sun, Dec 2, 2012 at 9:38 PM, Dennis Lundberg denn...@apache.org wrote: Hi Anders It looks like ASF Jenkins has been upgraded to 1.492, which should help us with the unwanted constant rebuilds in some of our other projects. Which jobs are hung? I can only see one: core-integration-testing-maven-3-embedded On 2012-12-02 20:12, Anders Hammar wrote: The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core-integration-testing-maven-3 jobs hangs
The Windows node is one, but I believe I saw the same problem on some other node as well. The same problem on the solaris node as well. /Anders /Anders (mobile) Den 2 dec 2012 22:37 skrev Dennis Lundberg denn...@apache.org: On 2012-12-02 22:01, Anders Hammar wrote: It's the core-integration-testing-maven-3 job that hangs. I've aborted it a few times hoping it would fix itself somehow. No luck though. Also, there's some problems with Jenkins not finding git installation on some nodes. But that's a different topic, but possibly related to the upgrade? If you mean the Windows node, I've already asked about that on builds@a.o but haven't gotten a reply yet. /Anders On Sun, Dec 2, 2012 at 9:38 PM, Dennis Lundberg denn...@apache.org wrote: Hi Anders It looks like ASF Jenkins has been upgraded to 1.492, which should help us with the unwanted constant rebuilds in some of our other projects. Which jobs are hung? I can only see one: core-integration-testing-maven-3-embedded On 2012-12-02 20:12, Anders Hammar wrote: The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. /Anders -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: core-integration-testing-maven-3 jobs hangs
The core-integration-testing-maven-3 jobs has started to hang since yesterday morning (whatever timezone the CI is showing). I have no clue how to figure out why. I've disabled the core-integration-testing-maven-3 job for now. We're just blocking other build jobs as it is now. As I pointed out, I have no idea how to solve this. Don't know if we can get a thread dump. /Anders /Anders
