Re: 'Get thee to the core' a concrete opportunity
On 10/12/2011, at 9:44 AM, Benson Margulies wrote: On the substance of the original problem: user runs 'mvn site:site' site:site finds javadoc and checkstyle, trigger a forked lifecycle to generate sources. In this particular case, 'generate-sources' in module 'b' depends on running out through 'process-classes' in module 'a'. b has a compile-scope dependency on agroup:aartifact:aversion:wsdl. The Javadoc plugin specifies this: @execute phase=generate-sources So there isn't a way to convince it to do something else in the forked lifecycle. Is the lifecycle calculator supposed to figure this out? It has no way to tell which execution in 'a' produces agroup:aartifact:aversion:wsdl, so it has no way to tell that 'process-classes' is going to be required. This is the more fundamental question that would need to be addressed - there's no way to express that in Maven right now. However, adding 'process-classes' to the top-level command line doesn't help, apparently because it doesn't travel from the initial execution plan to the forked execution plan. Once you have the fix I made today, you can get around this by running 'mvn install' to stuff the wsdl artifact into the local repo before running site:site. But if the intent is to avoid this requirement, how is it supposed to work? Perhaps an alternative would be to additionally bind that generation to the pre-site phase in 'a' as well. Not sure if that'll make it available, but worth a try. That would require running mvn site instead of mvn site:site (which is standard anyway). Otherwise, I think you're faced with documenting mvn install without doing major lifecycle surgery. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 'Get thee to the core' a concrete opportunity
On Mon, Dec 12, 2011 at 8:01 PM, Brett Porter br...@apache.org wrote: On 10/12/2011, at 9:44 AM, Benson Margulies wrote: On the substance of the original problem: user runs 'mvn site:site' site:site finds javadoc and checkstyle, trigger a forked lifecycle to generate sources. In this particular case, 'generate-sources' in module 'b' depends on running out through 'process-classes' in module 'a'. b has a compile-scope dependency on agroup:aartifact:aversion:wsdl. The Javadoc plugin specifies this: @execute phase=generate-sources So there isn't a way to convince it to do something else in the forked lifecycle. Is the lifecycle calculator supposed to figure this out? It has no way to tell which execution in 'a' produces agroup:aartifact:aversion:wsdl, so it has no way to tell that 'process-classes' is going to be required. This is the more fundamental question that would need to be addressed - there's no way to express that in Maven right now. However, adding 'process-classes' to the top-level command line doesn't help, apparently because it doesn't travel from the initial execution plan to the forked execution plan. Once you have the fix I made today, you can get around this by running 'mvn install' to stuff the wsdl artifact into the local repo before running site:site. But if the intent is to avoid this requirement, how is it supposed to work? Perhaps an alternative would be to additionally bind that generation to the pre-site phase in 'a' as well. Not sure if that'll make it available, but worth a try. That would require running mvn site instead of mvn site:site (which is standard anyway). Otherwise, I think you're faced with documenting mvn install without doing major lifecycle surgery. Brett, Thank you very much for the detailed analysis. In the case at hand, running 'mvn install' before 'mvn site' is really not onerous, and it works fine -- now that I fixed the problems with the ReactorReader. --benson - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter http://twitter.com/brettporter - 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: 'Get thee to the core' a concrete opportunity
Brett, What are you debugging in these days? On Thu, Dec 8, 2011 at 12:31 PM, Brett Porter br...@apache.org wrote: Are you running Maven from the IDE, or using the mvnDebug remote debugging? If you have the Maven projects open, and then attach to a Maven process built from those sources, you should be able to trace into them instead - or at least set a breakpoint in there. Been ages since I used Eclipse though, so not sure if that's still valid there. On 08/12/2011, at 10:34 PM, Benson Margulies wrote: I want to see if I can chase MNG-5214 to its lair. I need a little bit of coaching to get the debugging process going. In the test case, there's a maven plugin which declares various maven 2 components as provided dependencies, notably the DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me the source to the 2.2.1 version even though, since I'm running M3, I'm using the M3 version. I'm suspecting that you core spelunkers can tell me how to get Eclipse unconfused. If there's a doc, please point me at it. If there isn't, please clue me in, and I'll write it. On Wed, Dec 7, 2011 at 9:27 PM, Benson Margulies bimargul...@gmail.com wrote: MSITE-623 describes the situation, but, in fact, it's not MSITE at all. In the case at hand, the artifact resolver is returning the current target/classes pathname that goes with the 'jar' artifact as the answer to a question about the 'wsdl' artifact. Maven 2.2.1 does fine. Where do I start? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: 'Get thee to the core' a concrete opportunity
Olivier, You're pointing at the original problem: that process-classses doesn't get included in the forked lifecycle. I'm trying to start with the second problem: that the resolver gives a bogus answer. --benson On Thu, Dec 8, 2011 at 11:05 AM, Olivier Lamy ol...@apache.org wrote: 2011/12/8 Benson Margulies bimargul...@gmail.com: I want to see if I can chase MNG-5214 to its lair. I need a little bit of coaching to get the debugging process going. In the test case, there's a maven plugin which declares various maven 2 components as provided dependencies, notably the DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me the source to the 2.2.1 version even though, since I'm running M3, I'm using the M3 version. I'm suspecting that you core spelunkers can tell me how to get Eclipse unconfused. If there's a doc, please point me at it. If there isn't, please clue me in, and I'll write it. Perso I have same issue even with idea :-) Yup maven ide integration doesn't override core dependencies with your running core. BTW looks to be an issue with @aggregator and forked lifecycle in javadoc aggregator mojo. I recommend you have a look how this forkedLifecycle is calculated. Various places to investigate are : * maven-reporting-exec component in shared path * in core: DefaultLifecycleExecutor especially methods: calculateForkedExecutions and executeForkedExecutions (that's the point where javadoc aggregator is executed in case of the site plugin in 3.x ) HTH On Wed, Dec 7, 2011 at 9:27 PM, Benson Margulies bimargul...@gmail.com wrote: MSITE-623 describes the situation, but, in fact, it's not MSITE at all. In the case at hand, the artifact resolver is returning the current target/classes pathname that goes with the 'jar' artifact as the answer to a question about the 'wsdl' artifact. Maven 2.2.1 does fine. Where do I start? - 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: 'Get thee to the core' a concrete opportunity
On 12/08/2011 06:34 AM, Benson Margulies wrote: In the test case, there's a maven plugin which declares various maven 2 components as provided dependencies, notably the DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me the source to the 2.2.1 version even though, since I'm running M3, I'm using the M3 version. FWIW - using a NetBeans 7.2 dev build (close to 7.1 RC2), I: 1. Opened the M3 root POM (File Open Project) so the IDE knows where all the submodule projects are. 2. Opened the Maven Embedder module. Accept suggestion to prime. 3. Under File Project Properties Run, set Main Class to org.apache.maven.cli.MavenCli, and Arguments to -f .../pom.xml clean install for a project using nbm-maven-plugin 3.6 (more or less arbitrarily). 4. Opened sources for nbm-maven-plugin. Accept suggestion to prime. Go to Type on DefaultArtifactResolver offers both the 3.0.x source project version, and the 2.0.6 repository version (since both are in classpath of an open project). Accept the first. 5. Set a breakpoint in the constructor (int threads = ...). 6. Debug Project on Maven Embedder. 7. Breakpoint hit in the correct DefaultArtifactResolver.java. Debug Step Over shows threads=5 in the Variables view as expected (the 2.0.6 version has no such constructor code). Alternately, if bundled Maven binary (currently 3.0.3) suffices: 3. [can be skipped but then Step Over will not work] Window Debugging Sources with test project selected, Add Source Root, select .../maven-compat/src/main/java/ (will be default filechooser location if DAR.java selected in editor). 6. Right-click test project, Custom Goals..., clean install under Goals, jpda.listen=maven (i.e. launch Maven itself inside debugger) under Properties. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 'Get thee to the core' a concrete opportunity
On the substance of the original problem: user runs 'mvn site:site' site:site finds javadoc and checkstyle, trigger a forked lifecycle to generate sources. In this particular case, 'generate-sources' in module 'b' depends on running out through 'process-classes' in module 'a'. b has a compile-scope dependency on agroup:aartifact:aversion:wsdl. Is the lifecycle calculator supposed to figure this out? It has no way to tell which execution in 'a' produces agroup:aartifact:aversion:wsdl, so it has no way to tell that 'process-classes' is going to be required. However, adding 'process-classes' to the top-level command line doesn't help, apparently because it doesn't travel from the initial execution plan to the forked execution plan. Once you have the fix I made today, you can get around this by running 'mvn install' to stuff the wsdl artifact into the local repo before running site:site. But if the intent is to avoid this requirement, how is it supposed to work? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 'Get thee to the core' a concrete opportunity
2011/12/8 Benson Margulies bimargul...@gmail.com: I want to see if I can chase MNG-5214 to its lair. I need a little bit of coaching to get the debugging process going. In the test case, there's a maven plugin which declares various maven 2 components as provided dependencies, notably the DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me the source to the 2.2.1 version even though, since I'm running M3, I'm using the M3 version. I'm suspecting that you core spelunkers can tell me how to get Eclipse unconfused. If there's a doc, please point me at it. If there isn't, please clue me in, and I'll write it. Perso I have same issue even with idea :-) Yup maven ide integration doesn't override core dependencies with your running core. BTW looks to be an issue with @aggregator and forked lifecycle in javadoc aggregator mojo. I recommend you have a look how this forkedLifecycle is calculated. Various places to investigate are : * maven-reporting-exec component in shared path * in core: DefaultLifecycleExecutor especially methods: calculateForkedExecutions and executeForkedExecutions (that's the point where javadoc aggregator is executed in case of the site plugin in 3.x ) HTH On Wed, Dec 7, 2011 at 9:27 PM, Benson Margulies bimargul...@gmail.com wrote: MSITE-623 describes the situation, but, in fact, it's not MSITE at all. In the case at hand, the artifact resolver is returning the current target/classes pathname that goes with the 'jar' artifact as the answer to a question about the 'wsdl' artifact. Maven 2.2.1 does fine. Where do I start? - 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: 'Get thee to the core' a concrete opportunity
Are you running Maven from the IDE, or using the mvnDebug remote debugging? If you have the Maven projects open, and then attach to a Maven process built from those sources, you should be able to trace into them instead - or at least set a breakpoint in there. Been ages since I used Eclipse though, so not sure if that's still valid there. On 08/12/2011, at 10:34 PM, Benson Margulies wrote: I want to see if I can chase MNG-5214 to its lair. I need a little bit of coaching to get the debugging process going. In the test case, there's a maven plugin which declares various maven 2 components as provided dependencies, notably the DefaultArtifactResolver. So, my IDE keeps trying (I think) to show me the source to the 2.2.1 version even though, since I'm running M3, I'm using the M3 version. I'm suspecting that you core spelunkers can tell me how to get Eclipse unconfused. If there's a doc, please point me at it. If there isn't, please clue me in, and I'll write it. On Wed, Dec 7, 2011 at 9:27 PM, Benson Margulies bimargul...@gmail.com wrote: MSITE-623 describes the situation, but, in fact, it's not MSITE at all. In the case at hand, the artifact resolver is returning the current target/classes pathname that goes with the 'jar' artifact as the answer to a question about the 'wsdl' artifact. Maven 2.2.1 does fine. Where do I start? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
I took a run at JXR-88, and ended up creating JXR-89, which claims that aggregation is not functional at all in JXR at the moment. I'd be happy to be proved confused. On Sun, Jun 19, 2011 at 4:33 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: I opened MNG-5119 to track this. We can use the Wiki too [2], if useful at any time. I already did some minor improvements and published 3.0.4-SNAPSHOT site [3] (sync pending) to see the actual state, to be compared with 3.0.3 [4] I'm starting to test ideas on shared components, since they are the other place where components (not plugins) need documentation improvement Regards, Hervé [1] http://jira.codehaus.org/browse/MNG-5119 [2] https://cwiki.apache.org/confluence/display/MAVEN/Proposals [3] http://maven.apache.org/ref/3.0.4-SNAPSHOT/ [4] http://maven.apache.org/ref/3.0.3/ Le samedi 18 juin 2011, Benson Margulies a écrit : Returning to the very start of this thread: Now that I seem to have caught up with my current box of itches on plugins for the moment, I'd be more than happy to join this parade. Could some more experience committer grab a defect JIRA that has a some value to it, throw it up here on the list, and shout 'pull'? On Mon, Jun 13, 2011 at 5:25 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: While we have a good standard for plugin site organization [1] that was debated a few years ago to improve Maven documentation, we have nothing for components. And the actual state is not good: see Maven core, where even simplest description of every component is not done but inherited from parent... I think we could define something for components like plugins, relatively easy to follow and definitely useful as a starting point. I have a few ideas: - a site descriptor with links to javadoc and jxr (since code is the most important thing expected from components), and a FAQ - an introduction with a list of component interfaces and implementations provided (I have no precise idea on the form) Any other idea? I'll try to implement some ideas on Maven core for the next version: we'll write a guide later with practices found. Regards, Hervé [1] http://maven.apache.org/guides/development/guide-plugin-documentation.ht ml Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit : HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls.
Re: Get thee to the Core...
I opened MNG-5119 to track this. We can use the Wiki too [2], if useful at any time. I already did some minor improvements and published 3.0.4-SNAPSHOT site [3] (sync pending) to see the actual state, to be compared with 3.0.3 [4] I'm starting to test ideas on shared components, since they are the other place where components (not plugins) need documentation improvement Regards, Hervé [1] http://jira.codehaus.org/browse/MNG-5119 [2] https://cwiki.apache.org/confluence/display/MAVEN/Proposals [3] http://maven.apache.org/ref/3.0.4-SNAPSHOT/ [4] http://maven.apache.org/ref/3.0.3/ Le samedi 18 juin 2011, Benson Margulies a écrit : Returning to the very start of this thread: Now that I seem to have caught up with my current box of itches on plugins for the moment, I'd be more than happy to join this parade. Could some more experience committer grab a defect JIRA that has a some value to it, throw it up here on the list, and shout 'pull'? On Mon, Jun 13, 2011 at 5:25 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: While we have a good standard for plugin site organization [1] that was debated a few years ago to improve Maven documentation, we have nothing for components. And the actual state is not good: see Maven core, where even simplest description of every component is not done but inherited from parent... I think we could define something for components like plugins, relatively easy to follow and definitely useful as a starting point. I have a few ideas: - a site descriptor with links to javadoc and jxr (since code is the most important thing expected from components), and a FAQ - an introduction with a list of component interfaces and implementations provided (I have no precise idea on the form) Any other idea? I'll try to implement some ideas on Maven core for the next version: we'll write a guide later with practices found. Regards, Hervé [1] http://maven.apache.org/guides/development/guide-plugin-documentation.ht ml Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit : HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm
Re: Get thee to the Core...
Returning to the very start of this thread: Now that I seem to have caught up with my current box of itches on plugins for the moment, I'd be more than happy to join this parade. Could some more experience committer grab a defect JIRA that has a some value to it, throw it up here on the list, and shout 'pull'? On Mon, Jun 13, 2011 at 5:25 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: While we have a good standard for plugin site organization [1] that was debated a few years ago to improve Maven documentation, we have nothing for components. And the actual state is not good: see Maven core, where even simplest description of every component is not done but inherited from parent... I think we could define something for components like plugins, relatively easy to follow and definitely useful as a starting point. I have a few ideas: - a site descriptor with links to javadoc and jxr (since code is the most important thing expected from components), and a FAQ - an introduction with a list of component interfaces and implementations provided (I have no precise idea on the form) Any other idea? I'll try to implement some ideas on Maven core for the next version: we'll write a guide later with practices found. Regards, Hervé [1] http://maven.apache.org/guides/development/guide-plugin-documentation.html Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit : HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the
Re: Get thee to the Core...
While we have a good standard for plugin site organization [1] that was debated a few years ago to improve Maven documentation, we have nothing for components. And the actual state is not good: see Maven core, where even simplest description of every component is not done but inherited from parent... I think we could define something for components like plugins, relatively easy to follow and definitely useful as a starting point. I have a few ideas: - a site descriptor with links to javadoc and jxr (since code is the most important thing expected from components), and a FAQ - an introduction with a list of component interfaces and implementations provided (I have no precise idea on the form) Any other idea? I'll try to implement some ideas on Maven core for the next version: we'll write a guide later with practices found. Regards, Hervé [1] http://maven.apache.org/guides/development/guide-plugin-documentation.html Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit : HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by
Re: Get thee to the Core...
a good candidate for a proposal? [1] Yes, improving logging and its documentation would be useful. Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Proposals Le vendredi 10 juin 2011, Ralph Goers a écrit : On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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: Get thee to the Core...
Hi all, Long time lurker, I'm de-lurking because I like to harp on a bit about how to run a successful open source project (based off Karl Fogel's teachings at http://producingoss.org) - got to love opinionated lurkers right? ;p My comments in-line below: * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) I typically see this being successful when there are readily accessible issue trackers, documentation, developer guidelines, a community manager (or several) and more. In order to not scare a new developer away from something difficult (like Maven core), you want them to grok it in a day or so by supplying: * A 30,000 foot view * A how to build and run the core * A list of _really_ simple bug fixes that new developers can try out so they can follow the development process. My favourite is to say Hey, we just switched on Findbugs - and there are 3 issues to fix in class X. The feeling of accomplishment that a new developer will get from successfully making a change is really, really important. * Crucially they need some really patient community leads/managers/whatever to be there for them in real-time. This is the hardest part. Maven already has some of this stuff covered, which is great! But I think it's perhaps lacking a little in the documentation around the core and maybe some more dedicated community managers/leads/whatever wouldn't go amiss either. A really good example of great interaction is with the ossrh mailing list with Juven as the de-facto community manager. He's so quick and polite to respond to issues that users volunteers start responding in kind and get involved (in my case the tiniest of doc patches, but hey I wouldn't have normally bothered). Remember, every user/developer is a potential volunteer :-). * apply patches from people that genuinely can help (suggested by Brett) I think the applying or rejecting of patches could be sped up (from my anecdotal watching of JIRAs over the past year). It can help to have a dedicated person for this, quick response times to patches means a much higher chance of having that user/developer join the project! I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. This would be brilliant. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) blatantly looking a SonatypeInterns can be really useful in these sorts of situations (where you have to play catch-up on the docs)/blatantly looking at Sonatype Feel free to ignore any of the above - I just couldn't resist sticking my nose in. Cheers, Martijn - (Maven fan - most of the time ;p) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
Ralph, are you working on log4j-2.0?
Is it (close to) production ready?
Of course, I'd have no problem to use it. This would allow us to improve
log4j-2.0 plus we'd quickly get fixes/changes if we need them.
LieGrue,
strub
--- On Sat, 6/11/11, Ralph Goers ralph.go...@dslextreme.com wrote:
From: Ralph Goers ralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers List dev@maven.apache.org
Date: Saturday, June 11, 2011, 5:43 AM
I'm not sure what you are after
John. Logback provides a formatter where you can do
logger.debug(Hello, {}, John) and it will replace the
curly braces with John. My Log4J 2.0 will do the
same thing. MessageFormat is fairly slow, but if you
wanted to use that instead my Log4J 2.0 implementation will
allow you to create a new Class that implements the Message
interface and use that if you want.
Ralph
On Jun 10, 2011, at 8:28 AM, John Casey wrote:
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for tests,
etc.
But moving the whole Logger mess over to slf4j
would be really great. There are lots of tests (I sadly also
found productive code too) still using System.out.println.
The question is if we (internally) drop
org.codehaus.plexus.logging.Logger completely and use slf4j
directly, or if we pimp up the plexus Logger and add various
stuff.
I've been thinking about this for some time now,
actually. If you look at the MAE stuff in the sandbox, I'm
pretty sure that's using log4j directly.
Personally, I don't understand what value the Plexus
logger/loggermanager has, especially given the
configurability of these other logging frameworks.
I'd be in favor of providing a default logging
configuration file in either the Maven app directory or in
~/.m2, and then letting people customize from the command
line to highlight specific components/packages.
Although, having said that, one of my pet peeves about
the logging frameworks is they haven't shifted to using
String.format, MessageFormat.format, or whatever
under-the-covers as a way of limiting string concatenation
in cases where a particular log level has been disabled.
Even something as simple as the attached code would be
a nice facade for logging, IMO...but it's more of a
wish-list item than anything else.
In short, yes, let's think about switching to a better
logging framework. We can deprecate the plexus logger, and
eventually get rid of it!
We would need to do some compat code anyway, but
I'm not sure if it pays off to restrict ourself. At least
not after I saw that even the LoggerManager uses
System.err.println:
// TODO: use a logger!
System.err.println( There was no such logger ' +
key + ' + hashCode() + . );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com
wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson Margulies
wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness
is the
difficulty of
understanding, in some cases, why it does
what it
does.
This suggests to me three efforts that
might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow component
(indeed
class) by component
log control as an alternative to the giant
-X spew.
Now that is an interesting idea. For the past
year I have
been working on creating Log4j 2.0 pretty much
by
myself. This would be a great way to
integrate it into
something useful.
Ralph
-
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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
Logger.java
-
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: Get thee to the Core...
I'll take a look... I'm keen to see logging done right - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jun 2011 06:50, Ralph Goers ralph.go...@dslextreme.com wrote:
Re: Get thee to the Core...
Yes - I have been working on it. I wouldn't call it close to production ready.
I would call it time for more user involvement. I've been working on it for
almost a year taking everything I've learned from Log4j 1.x, SLF4J/Logback and
a proprietary framework I wrote for my employer. The Logging PMC is fairly
small and we could really use more people to join in. It is still in my own
sandbox area but I would love feedback. While I have a lot of the core
functionality working I haven't written any documentation yet.
Ralph
On Jun 10, 2011, at 11:26 PM, Mark Struberg wrote:
Ralph, are you working on log4j-2.0?
Is it (close to) production ready?
Of course, I'd have no problem to use it. This would allow us to improve
log4j-2.0 plus we'd quickly get fixes/changes if we need them.
LieGrue,
strub
--- On Sat, 6/11/11, Ralph Goers ralph.go...@dslextreme.com wrote:
From: Ralph Goers ralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers List dev@maven.apache.org
Date: Saturday, June 11, 2011, 5:43 AM
I'm not sure what you are after
John. Logback provides a formatter where you can do
logger.debug(Hello, {}, John) and it will replace the
curly braces with John. My Log4J 2.0 will do the
same thing. MessageFormat is fairly slow, but if you
wanted to use that instead my Log4J 2.0 implementation will
allow you to create a new Class that implements the Message
interface and use that if you want.
Ralph
On Jun 10, 2011, at 8:28 AM, John Casey wrote:
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for tests,
etc.
But moving the whole Logger mess over to slf4j
would be really great. There are lots of tests (I sadly also
found productive code too) still using System.out.println.
The question is if we (internally) drop
org.codehaus.plexus.logging.Logger completely and use slf4j
directly, or if we pimp up the plexus Logger and add various
stuff.
I've been thinking about this for some time now,
actually. If you look at the MAE stuff in the sandbox, I'm
pretty sure that's using log4j directly.
Personally, I don't understand what value the Plexus
logger/loggermanager has, especially given the
configurability of these other logging frameworks.
I'd be in favor of providing a default logging
configuration file in either the Maven app directory or in
~/.m2, and then letting people customize from the command
line to highlight specific components/packages.
Although, having said that, one of my pet peeves about
the logging frameworks is they haven't shifted to using
String.format, MessageFormat.format, or whatever
under-the-covers as a way of limiting string concatenation
in cases where a particular log level has been disabled.
Even something as simple as the attached code would be
a nice facade for logging, IMO...but it's more of a
wish-list item than anything else.
In short, yes, let's think about switching to a better
logging framework. We can deprecate the plexus logger, and
eventually get rid of it!
We would need to do some compat code anyway, but
I'm not sure if it pays off to restrict ourself. At least
not after I saw that even the LoggerManager uses
System.err.println:
// TODO: use a logger!
System.err.println( There was no such logger ' +
key + ' + hashCode() + . );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com
wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson Margulies
wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness
is the
difficulty of
understanding, in some cases, why it does
what it
does.
This suggests to me three efforts that
might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow component
(indeed
class) by component
log control as an alternative to the giant
-X spew.
Now that is an interesting idea. For the past
year I have
been working on creating Log4j 2.0 pretty much
by
myself. This would be a great way to
integrate it into
something useful.
Ralph
-
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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
Logger.java
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional
Re: Get thee to the Core...
Well, I make no guarantee that it is done right. I do guarantee that if you want to help I'll welcome it. On Jun 11, 2011, at 12:12 AM, Stephen Connolly wrote: I'll take a look... I'm keen to see logging done right - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jun 2011 06:50, Ralph Goers ralph.go...@dslextreme.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
Are there any other log4j-2.0 activities?
If not, then why not move it to the trunk (or an official 2.0 branch)?
I will give it a try.
LieGrue,
strub
--- On Sat, 6/11/11, Ralph Goers ralph.go...@dslextreme.com wrote:
From: Ralph Goers ralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers List dev@maven.apache.org
Date: Saturday, June 11, 2011, 7:19 AM
Yes - I have been working on
it. I wouldn't call it close to production ready. I
would call it time for more user involvement. I've been
working on it for almost a year taking everything I've
learned from Log4j 1.x, SLF4J/Logback and a proprietary
framework I wrote for my employer. The Logging PMC is
fairly small and we could really use more people to join
in. It is still in my own sandbox area but I would
love feedback. While I have a lot of the core functionality
working I haven't written any documentation yet.
Ralph
On Jun 10, 2011, at 11:26 PM, Mark Struberg wrote:
Ralph, are you working on log4j-2.0?
Is it (close to) production ready?
Of course, I'd have no problem to use it. This would
allow us to improve log4j-2.0 plus we'd quickly get
fixes/changes if we need them.
LieGrue,
strub
--- On Sat, 6/11/11, Ralph Goers ralph.go...@dslextreme.com
wrote:
From: Ralph Goers ralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers List dev@maven.apache.org
Date: Saturday, June 11, 2011, 5:43 AM
I'm not sure what you are after
John. Logback provides a formatter where you
can do
logger.debug(Hello, {}, John) and it will
replace the
curly braces with John. My Log4J 2.0 will
do the
same thing. MessageFormat is fairly slow,
but if you
wanted to use that instead my Log4J 2.0
implementation will
allow you to create a new Class that implements
the Message
interface and use that if you want.
Ralph
On Jun 10, 2011, at 8:28 AM, John Casey wrote:
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for
tests,
etc.
But moving the whole Logger mess over to
slf4j
would be really great. There are lots of tests (I
sadly also
found productive code too) still using
System.out.println.
The question is if we (internally) drop
org.codehaus.plexus.logging.Logger completely and
use slf4j
directly, or if we pimp up the plexus Logger and
add various
stuff.
I've been thinking about this for some time
now,
actually. If you look at the MAE stuff in the
sandbox, I'm
pretty sure that's using log4j directly.
Personally, I don't understand what value the
Plexus
logger/loggermanager has, especially given the
configurability of these other logging
frameworks.
I'd be in favor of providing a default
logging
configuration file in either the Maven app
directory or in
~/.m2, and then letting people customize from the
command
line to highlight specific components/packages.
Although, having said that, one of my pet
peeves about
the logging frameworks is they haven't shifted to
using
String.format, MessageFormat.format, or whatever
under-the-covers as a way of limiting string
concatenation
in cases where a particular log level has been
disabled.
Even something as simple as the attached code
would be
a nice facade for logging, IMO...but it's more of
a
wish-list item than anything else.
In short, yes, let's think about switching to
a better
logging framework. We can deprecate the plexus
logger, and
eventually get rid of it!
We would need to do some compat code
anyway, but
I'm not sure if it pays off to restrict ourself.
At least
not after I saw that even the LoggerManager uses
System.err.println:
// TODO: use a logger!
System.err.println( There was no such
logger ' +
key + ' + hashCode() + . );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com
wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson
Margulies
wrote:
I'd like to offer a small
suggestion.
One of the big barriers to maven
happiness
is the
difficulty of
understanding, in some cases, why
it does
what it
does.
This suggests to me three efforts
that
might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow
component
(indeed
class) by component
log control as an alternative to
the giant
-X spew.
Now that is an interesting idea. For
the past
year I have
been working on creating Log4j 2.0
pretty much
by
myself. This would be a great
way to
integrate it into
something useful.
Ralph
-
To unsubscribe, e-mail
Re: Get thee to the Core...
Interesting thread. So we are using Splunk as our log viewer and it has built in ability to map message ids to the localized strings. But, it's expensive for Splunk to do this (both in $ and processing time). So while its architecturally more pure it requires a good log viewer that everyone has access to. On 6/10/11 10:45 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
Re: Get thee to the Core...
Oops, sorry all. I was responding to Ralph about logging. This doesn't really have much to do with Maven. On 6/11/11 9:03 AM, Clark, Gil W. gil_cl...@intuit.com wrote: Interesting thread. So we are using Splunk as our log viewer and it has built in ability to map message ids to the localized strings. But, it's expensive for Splunk to do this (both in $ and processing time). So while its architecturally more pure it requires a good log viewer that everyone has access to. On 6/10/11 10:45 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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
Re: Get thee to the Core...
No problem, just let it flow ;) Actually I'm not sure why all this internationalization on internal error messages at all ^^ To be honest: it _s u c k s_ to have german error messages in my logs! Or imagine to live in Hungary: You can google almost _nothing_ that will help you if you only have the hungarian error message... You would be able to find tons of answers to an actual problem if you _would_ have the english version of the error message - but instead you are stuck with a useless german, hungarian, swedish or whatever error text. What is the benefit of having i18n logs at all? This will only be browsed by engineers anyway. Messages who address end users are certainly a different thing - but I would not handle those via a logger mechanism! But even error messages (shown to the end user via e.g. an error page) will not be handled via a logger. So for me all the i18n discussion is moot for the _logger_ backend (but certainly a valuable feature for a Error-Message system). LieGrue, strub --- On Sat, 6/11/11, Clark, Gil W. gil_cl...@intuit.com wrote: From: Clark, Gil W. gil_cl...@intuit.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Saturday, June 11, 2011, 4:06 PM Oops, sorry all. I was responding to Ralph about logging. This doesn't really have much to do with Maven. On 6/11/11 9:03 AM, Clark, Gil W. gil_cl...@intuit.com wrote: Interesting thread. So we are using Splunk as our log viewer and it has built in ability to map message ids to the localized strings. But, it's expensive for Splunk to do this (both in $ and processing time). So while its architecturally more pure it requires a good log viewer that everyone has access to. On 6/10/11 10:45 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven
Re: Get thee to the Core...
well if you are i18n-ing your logging messages you should always include a code in the log message, that way you just google the code and presto changeo you have your answer... what I find is there is a logging level above which it makes sense to i18n... usually somewhere around info/warn, but below which it well only be engineers so leave at english... what I'd like to see is some sort of logging escalation facility, so that when some event occurs, previous/subsequent log messages are escalated to give context... i.e. a thread local of the last 5 or so log records so that when you log an event you get access to the context even though the logging level was above the context's level there is nothing worse than digging through 5gb of logs from multiple threads trying to pull out the context for the one event you are after... that is another thing that the i18n via logging codes gives you, ie trotting context escalation for specifuc codes - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jun 2011 17:38, Mark Struberg strub...@yahoo.de wrote:
Re: Get thee to the Core...
We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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: Get thee to the Core...
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for tests, etc.
But moving the whole Logger mess over to slf4j would be really great. There are
lots of tests (I sadly also found productive code too) still using
System.out.println.
The question is if we (internally) drop org.codehaus.plexus.logging.Logger
completely and use slf4j directly, or if we pimp up the plexus Logger and add
various stuff.
I've been thinking about this for some time now, actually. If you look
at the MAE stuff in the sandbox, I'm pretty sure that's using log4j
directly.
Personally, I don't understand what value the Plexus
logger/loggermanager has, especially given the configurability of these
other logging frameworks.
I'd be in favor of providing a default logging configuration file in
either the Maven app directory or in ~/.m2, and then letting people
customize from the command line to highlight specific components/packages.
Although, having said that, one of my pet peeves about the logging
frameworks is they haven't shifted to using String.format,
MessageFormat.format, or whatever under-the-covers as a way of limiting
string concatenation in cases where a particular log level has been
disabled.
Even something as simple as the attached code would be a nice facade for
logging, IMO...but it's more of a wish-list item than anything else.
In short, yes, let's think about switching to a better logging
framework. We can deprecate the plexus logger, and eventually get rid of it!
We would need to do some compat code anyway, but I'm not sure if it pays off to
restrict ourself. At least not after I saw that even the LoggerManager uses
System.err.println:
// TODO: use a logger!
System.err.println( There was no such logger ' + key + ' + hashCode() +
. );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the
difficulty of
understanding, in some cases, why it does what it
does.
This suggests to me three efforts that might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow component (indeed
class) by component
log control as an alternative to the giant -X spew.
Now that is an interesting idea. For the past year I have
been working on creating Log4j 2.0 pretty much by
myself. This would be a great way to integrate it into
something useful.
Ralph
-
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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
/*
* Copyright 2011 Red Hat, Inc.
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.commonjava.util.logging;
import org.slf4j.LoggerFactory;
import java.text.MessageFormat;
import java.util.IllegalFormatException;
public final class Logger
{
private final org.slf4j.Logger logger;
public Logger( Class? clazz )
{
logger = LoggerFactory.getLogger( clazz );
}
public Logger( String name )
{
logger = LoggerFactory.getLogger( name );
}
public Logger( org.slf4j.Logger logger )
{
this.logger = logger;
}
public org.slf4j.Logger getLogger()
{
return logger;
}
public Logger debug( String format, Object...params )
{
if ( logger.isDebugEnabled() )
{
logger.debug( format( format, params ) );
}
return this;
}
public Logger debug( String format, Throwable error, Object...params )
{
if ( logger.isDebugEnabled() )
{
logger.debug( format( format, params ), error );
}
return this;
}
public Logger error( String format, Object...params )
{
if ( logger.isErrorEnabled
Re: Get thee to the Core...
personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: Get thee to the Core...
lest anyone think I'm doing NIH, the logging frameworks I have implemented myself (they were under commercial license for previous employer) were less than perfect, but having seen my mistakes I think I have a better handle on the right path to take! On 10 June 2011 16:42, Stephen Connolly stephen.alan.conno...@gmail.com wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: Get thee to the Core...
On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: but having seen my mistakes I think I have a better handle on the right path to take! Strange enough, that's almost definitely what Ceki Gülcü would say ... :-) -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
the problem is: logging gets tricky once you have OSGIi or ThreadContextClassLoaders in place... So I'd favour slf4j. We don't need a 'perfect' solution - we just need something better than we had in place ;) LieGrue, strub --- On Fri, 6/10/11, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 3:46 PM On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: but having seen my mistakes I think I have a better handle on the right path to take! Strange enough, that's almost definitely what Ceki Gülcü would say ... :-) -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - 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: Get thee to the Core...
HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work on that list. Brett's last thing was All good things to discuss on the dev list :). -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Best regards, Evgeny Mandrikov aka Godin http://godin.net.ru http://twitter.com/_godin_ http://www.SonarSource.com http://www.sonarsource.com/
Re: Get thee to the Core...
On 2011-06-09 23:45, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. I'm game for working on changing the logging implementation. Having spent some time patching commons-logging, and releasing version 1.1.1, I know my way around logging code. 2: get the dependency plugin caught up with the core. 3: think of more help: goals that answers questions that people have. One really useful exercise would be to mine the user list for recurring themes. On Thu, Jun 9, 2011 at 5:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven
Re: Get thee to the Core...
I'm not sure what you are after John. Logback provides a formatter where you
can do
logger.debug(Hello, {}, John) and it will replace the curly braces with
John. My Log4J 2.0 will do the same thing. MessageFormat is fairly slow,
but if you wanted to use that instead my Log4J 2.0 implementation will allow
you to create a new Class that implements the Message interface and use that if
you want.
Ralph
On Jun 10, 2011, at 8:28 AM, John Casey wrote:
On 6/10/11 3:48 AM, Mark Struberg wrote:
We partly use slf4j internally already for tests, etc.
But moving the whole Logger mess over to slf4j would be really great. There
are lots of tests (I sadly also found productive code too) still using
System.out.println.
The question is if we (internally) drop org.codehaus.plexus.logging.Logger
completely and use slf4j directly, or if we pimp up the plexus Logger and
add various stuff.
I've been thinking about this for some time now, actually. If you look at the
MAE stuff in the sandbox, I'm pretty sure that's using log4j directly.
Personally, I don't understand what value the Plexus logger/loggermanager
has, especially given the configurability of these other logging frameworks.
I'd be in favor of providing a default logging configuration file in either
the Maven app directory or in ~/.m2, and then letting people customize from
the command line to highlight specific components/packages.
Although, having said that, one of my pet peeves about the logging frameworks
is they haven't shifted to using String.format, MessageFormat.format, or
whatever under-the-covers as a way of limiting string concatenation in cases
where a particular log level has been disabled.
Even something as simple as the attached code would be a nice facade for
logging, IMO...but it's more of a wish-list item than anything else.
In short, yes, let's think about switching to a better logging framework. We
can deprecate the plexus logger, and eventually get rid of it!
We would need to do some compat code anyway, but I'm not sure if it pays off
to restrict ourself. At least not after I saw that even the LoggerManager
uses System.err.println:
// TODO: use a logger!
System.err.println( There was no such logger ' + key + ' + hashCode() +
. );
dumdidum :)
LieGrue,
strub
--- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote:
From: Ralph Goersralph.go...@dslextreme.com
Subject: Re: Get thee to the Core...
To: Maven Developers Listdev@maven.apache.org
Date: Friday, June 10, 2011, 5:03 AM
On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote:
I'd like to offer a small suggestion.
One of the big barriers to maven happiness is the
difficulty of
understanding, in some cases, why it does what it
does.
This suggests to me three efforts that might offer an
opportunity to
learn core code without drowning.
1: take up slf4j, and thus allow component (indeed
class) by component
log control as an alternative to the giant -X spew.
Now that is an interesting idea. For the past year I have
been working on creating Log4j 2.0 pretty much by
myself. This would be a great way to integrate it into
something useful.
Ralph
-
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
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
Logger.java
-
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: Get thee to the Core...
Actually, SLF4J's tie to Ceki's I18n project is one thing I really dislike. IMO, localization should be done at the last possible moment. If you really want an internationalized log then you should be logging message ids and data and then doing the localization in your log viewer, not as you are writing the records. Ralph On Jun 10, 2011, at 8:42 AM, Stephen Connolly wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: Get thee to the Core...
SLF4J isn't a logging framework. It is an API. While Logback is much better than Log4J 1.x it still has significant architectural problems. Ralph On Jun 10, 2011, at 9:20 AM, Mark Struberg wrote: the problem is: logging gets tricky once you have OSGIi or ThreadContextClassLoaders in place... So I'd favour slf4j. We don't need a 'perfect' solution - we just need something better than we had in place ;) LieGrue, strub --- On Fri, 6/10/11, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: Re: Get thee to the Core... To: Maven Developers List dev@maven.apache.org Date: Friday, June 10, 2011, 3:46 PM On Fri, Jun 10, 2011 at 5:43 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: but having seen my mistakes I think I have a better handle on the right path to take! Strange enough, that's almost definitely what Ceki Gülcü would say ... :-) -- Capitalism is the astounding belief that the most wickedest of men will do the most wickedest of things for the greatest good of everyone. John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes) - 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: Get thee to the Core...
Well, I could use feedback on https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/ On Jun 10, 2011, at 8:43 AM, Stephen Connolly wrote: lest anyone think I'm doing NIH, the logging frameworks I have implemented myself (they were under commercial license for previous employer) were less than perfect, but having seen my mistakes I think I have a better handle on the right path to take! On 10 June 2011 16:42, Stephen Connolly stephen.alan.conno...@gmail.com wrote: personally, there are a number of issues I have had with how slf4j/logback handles message formatting for i18n... other than the logging frameworks I have rolled myself, slf4j is the closest I've seen to logging done right... but it is still a bit far off the right path... Oh logging why do you have to be so fragmented and crap in java On 10 June 2011 16:28, John Casey jdca...@commonjava.org wrote: On 6/10/11 3:48 AM, Mark Struberg wrote: We partly use slf4j internally already for tests, etc. But moving the whole Logger mess over to slf4j would be really great. There are lots of tests (I sadly also found productive code too) still using System.out.println. The question is if we (internally) drop org.codehaus.plexus.logging.Logger completely and use slf4j directly, or if we pimp up the plexus Logger and add various stuff. I've been thinking about this for some time now, actually. If you look at the MAE stuff in the sandbox, I'm pretty sure that's using log4j directly. Personally, I don't understand what value the Plexus logger/loggermanager has, especially given the configurability of these other logging frameworks. I'd be in favor of providing a default logging configuration file in either the Maven app directory or in ~/.m2, and then letting people customize from the command line to highlight specific components/packages. Although, having said that, one of my pet peeves about the logging frameworks is they haven't shifted to using String.format, MessageFormat.format, or whatever under-the-covers as a way of limiting string concatenation in cases where a particular log level has been disabled. Even something as simple as the attached code would be a nice facade for logging, IMO...but it's more of a wish-list item than anything else. In short, yes, let's think about switching to a better logging framework. We can deprecate the plexus logger, and eventually get rid of it! We would need to do some compat code anyway, but I'm not sure if it pays off to restrict ourself. At least not after I saw that even the LoggerManager uses System.err.println: // TODO: use a logger! System.err.println( There was no such logger ' + key + ' + hashCode() + . ); dumdidum :) LieGrue, strub --- On Fri, 6/10/11, Ralph Goersralph.go...@dslextreme.com wrote: From: Ralph Goersralph.go...@dslextreme.com Subject: Re: Get thee to the Core... To: Maven Developers Listdev@maven.apache.org Date: Friday, June 10, 2011, 5:03 AM On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: Get thee to the Core...
CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work on that list. Brett's last thing was All good things to discuss on the dev list :). -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
Hello, I've only been lurking on the dev@ list for a couple of months, so, some of these may have already been asked, shot-down, stomped on like a cockroach, etc. but I've used maven for a couple of years now and wondered I caveat my requests/suggestions with: These could already be intended in the suggestions below, but with me not being familiar with the intent or detail of all the forwarded suggestions below, please feel free to slap me if they are well known intents. Also, my comments may not even be considered core, but they are something I've always wondered about, so I'm throwing them out there; you did say fresh ideas...: Why not allow an expanded dialect for the pom files (if it's not already in progress)? By that I mean open-up the format via some sort of plugin mechanism or core support so pom files could be written in other languages aside from XML. Perhaps something like JSON? I'm no JSON expert, but it seems to be alot less hand-coding and concise when compared to XML and could lead to much less tedium when writing poms by hand and should be just as flexible. No intention to start a war with this comment, it's just always been a curiosity point for me. Not even close to any sort of thorough thought-out process, but, what about adding an annotation mechanism to source files that Maven could use in-lieu of a pom file? It may require a pre-processor of some sort to get the proverbial ball rolling, but could be almost entirely dynamic from there. For example, if a class is annotated with something such as this: @MVN package com.foo; @MVNDep(groupId=bar, artifactID=bar, version=1.0, ...) import bar.baz.MyDep ... could tell a maven plugin/pre-processor task to dynamically build a pom in-memory (or even serialized output to a physical pom file). Classes that aren't annotated could be excluded from the dynamic pom or use the default dynamic generated pom. Regardless, those were just a few of my ramblings... On Jun 9, 2011, at 12:21 PM, John Casey wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a
Re: Get thee to the Core...
Why not allow an expanded dialect for the pom files (if it's not already in progress)? By that I mean open-up the format via some sort of plugin mechanism or core support so pom files could be written in other languages aside from XML. Perhaps something like JSON? I'm no JSON expert, but it seems to be alot less hand-coding and concise when compared to XML and could lead to much less tedium when writing poms by hand and should be just as flexible. No intention to start a war with this comment, it's just always been a curiosity point for me. You should check out Polyglot Maven [1]. /Anders [1] http://polyglot.sonatype.org/
Re: Get thee to the Core...
Looks interesting... I didn't want to work any more this afternoon anyway. ;) On Jun 9, 2011, at 2:34 PM, Anders Hammar wrote: Why not allow an expanded dialect for the pom files (if it's not already in progress)? By that I mean open-up the format via some sort of plugin mechanism or core support so pom files could be written in other languages aside from XML. Perhaps something like JSON? I'm no JSON expert, but it seems to be alot less hand-coding and concise when compared to XML and could lead to much less tedium when writing poms by hand and should be just as flexible. No intention to start a war with this comment, it's just always been a curiosity point for me. You should check out Polyglot Maven [1]. /Anders [1] http://polyglot.sonatype.org/ Cheers! Randy -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work on that list. Brett's last thing was All good things to discuss on the dev list :). -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work on that list. Brett's last thing was All good things to discuss on the dev list :). -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail:
Re: Get thee to the Core...
FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) It's on my todo list, but that would require time to actually work
Re: Get thee to the Core...
Thanks a lot Stephen!!! As I previously wrote before, my main issue is that even I'm quiet familiar with maven and basic APIs (I can develop plugins) I don't know how internals work, if you have something to share I can read to get more confident I would really appreciate it, then I'll request of course to open a new sandbox :) Have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 11:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that we should use email...but blogs are so much more accessible from places like feedly and google. I think we need to create documentation that is accessible from
Re: Get thee to the Core...
I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. 2: get the dependency plugin caught up with the core. 3: think of more help: goals that answers questions that people have. One really useful exercise would be to mine the user list for recurring themes. On Thu, Jun 9, 2011 at 5:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a particular thing done using Maven components. Or rather, how does Maven go about doing a particular task? Maybe this would turn into documentation eventually...but I almost see it as more of a forum at first. We have email for this, and that will be the eventual response, that
Re: Get thee to the Core...
On Fri, Jun 10, 2011 at 6:56 AM, Simone Tripodi simonetrip...@apache.org wrote: I don't know how internals work, if you have something to share I can read to get more confident I would really appreciate it I think that's the nub of the problem for a lot of people. We can hack a plugin but we don't understand how core works. We need to start putting more material together to explain and educate people so that it becomes more accessible. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
Simone, can you please do one favour for me... Can you please try svn mkdir https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone-test -m a test of sandbox access by a non-maven committer and if that works then svn rm https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone-test -m the test worked I just want to check if the sandbox is still open. On 9 June 2011 22:26, Simone Tripodi simonetrip...@apache.org wrote: Thanks a lot Stephen!!! As I previously wrote before, my main issue is that even I'm quiet familiar with maven and basic APIs (I can develop plugins) I don't know how internals work, if you have something to share I can read to get more confident I would really appreciate it, then I'll request of course to open a new sandbox :) Have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 11:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm feeling) I'm almost in favor of a more formalized parent/child dual POM syntax than versionless parents. Why not go all the way and recognize child POMs as the slave modules they are? I disagree with blogs, but that may be a starting point. I was thinking about blogging as a way of answering specific engineering-related questions about how to get a
RE: Get thee to the Core...
-Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Friday, 10 June 2011 10:12 AM To: Maven Developers List Subject: Re: Get thee to the Core... Simone, can you please do one favour for me... Can you please try svn mkdir https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone- test -m a test of sandbox access by a non-maven committer and if that works then svn rm https://svn.apache.org/repos/asf/maven/sandbox/trunk/simone- test -m the test worked I just want to check if the sandbox is still open. According to the auth file: [/maven/sandbox] @committers = rw so thats a yes. Gav... On 9 June 2011 22:26, Simone Tripodi simonetrip...@apache.org wrote: Thanks a lot Stephen!!! As I previously wrote before, my main issue is that even I'm quiet familiar with maven and basic APIs (I can develop plugins) I don't know how internals work, if you have something to share I can read to get more confident I would really appreciate it, then I'll request of course to open a new sandbox :) Have a nice day, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 11:21 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: FYI Simone, our sandbox is supposed to be open for all _APACHE_ committers, so if you want to work on stuff you can just fork what you are working on into the sandbox to show us your skills of a hacker rather than having to live in patch land On 9 June 2011 22:17, Simone Tripodi simonetrip...@apache.org wrote: Hi guys, I just accidentally and quickly had a look at the thread (got interested because saw Olivier in :P) and since I'm interested on contributing - and have been playing with @Inject Guice extensions for a while[1][2][3][4][5] - I could provide my help. My BIG issue is I don't know Maven core at all :( Do you have useful references I can start reading in order to understand how it works and be useful? Many thanks in advance, have a nice day! Simo [1] http://99soft.github.com/rocoto/ [2] http://99soft.github.com/sli4j/ [3] http://99soft.github.com/guartz/ [4] http://code.google.com/p/mybatis/wiki/Guice [5] http://incubator.apache.org/bval/cwiki/obtaining-a-validator.html (see Using Google Guice) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 10:00 PM, Olivier Lamy ol...@apache.org wrote: 2011/6/9 John Casey jdca...@commonjava.org: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) Agree to be not anymore dependant from the old good friend plexus. I like to be able to use core components (ModelBuilder etc..) without having to use plexus (now the sisu bridge) and being able to use in other containers. (btw we won't be able to remove sisu bridge now) Using @Inject standard looks nice too me. * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really
Re: Get thee to the Core...
On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
