Discussions

News: Release of a new Maven plugin : the Maven Author Plugin

Bookmark and Share Get thread feed

  1. Release of a new Maven plugin : the Maven Author Plugin (14 messages)

    A new Maven plugin has been released : the Maven Author Plugin. This Maven plugin generates an HTML report showing informations gathered from other Maven reports (Checkstyle, FindBugs, PMD, Lint4j, JavaNCSS, JCoverage, Cobertura, Emma, Clover, Tasks List, etc.) and categorized by authors of source files. http://mvn-author-plug.sourceforge.net
    Reply to this

    Threaded Messages (14)

  2. Duh![ Go to top ]

    As if the author Javadoc tag had any usefulness, relevance, or accuracy whatsoever, especially in a collaborative, distributed, open source project. Current Apache policy, by the way, is to strip all @author tags from source files.
    Reply to this Reply to original

  3. Re: Duh![ Go to top ]

    What I would really love is a system that does comprehensive analysis of SVN commits. Particularly I would like to learn the retention rate of various person's commits as I think think this might give some indication of code quality.
    Reply to this Reply to original

  4. Re: Duh! - StatSVN[ Go to top ]

    Hi www.StatSVN.org may provide this for you. It works with Ant, Maven 1 and there is also a link to a Maven2 plugin. Hope this helps Benoit
    Reply to this Reply to original

  5. for maven 1.x?[ Go to top ]

    Looks like that plugin is for Maven 1.x, who would use Maven 1.x by the way?
    Reply to this Reply to original

  6. I would[ Go to top ]

    ...for its stability, or at least for the stability that anything with the "maven" name on it ever achieves. Should I switch?
    Reply to this Reply to original

  7. Re: I would[ Go to top ]

    ...for its stability, or at least for the stability that anything with the "maven" name on it ever achieves. Should I switch?
    How does this stability differ from maven 2? Maven 2 is architecturally superios to maven 1. Maven 1 was a good concept, implemented in a bad way. I think you should use both, Ant and Maven 2 and definitely switch to maven 2:-)
    Reply to this Reply to original

  8. Re: why use maven 1.x[ Go to top ]

    who would use Maven 1.x by the way?
    People who have an established project that has a fully working build mechanism (using Maven 1), that has its timescales (which clearly take priority over which version of Maven to use), and that has its own custom Maven1 plugins and where the time taken to move to Maven2 is excessive compared to the benefits of doing so. Moving to Maven2 is not as simple as changing to have pom.xml, especially when you have custom plugins and would have to spend significant time writing Maven2 equivalents, not to mention the time needed to get up to speed on Maven2. Simple prioritisation of issues often dictates that such things wont happen.
    Reply to this Reply to original

  9. Re: why use maven 1.x[ Go to top ]

    who would use Maven 1.x by the way?

    People who have an established project that has a fully working build mechanism (using Maven 1), that has its timescales (which clearly take priority over which version of Maven to use), and that has its own custom Maven1 plugins and where the time taken to move to Maven2 is excessive compared to the benefits of doing so.

    Moving to Maven2 is not as simple as changing to have pom.xml, especially when you have custom plugins and would have to spend significant time writing Maven2 equivalents, not to mention the time needed to get up to speed on Maven2. Simple prioritisation of issues often dictates that such things wont happen.
    I think that Mergere maestro has a script to convert a Maven 1 project in a Maven 2 project although I've never tried it. BTW, Maven 2 rocks :)
    Reply to this Reply to original

  10. Re: why use maven 1.x[ Go to top ]

    BTW, Maven 2 rocks :)
    It's good, but let's not get too carried away. M2 is an incremental improvement over M1 and a declarative model is (imvho) generally better than an imperative one (which is why I prefer Maven to Ant), but the implementation still leaves a lot to be desired. A couple of examples: * version handling is weak, particularly in the context of dependencies * many plugins are of alpha or beta quality * plugins tend not to play well together - plugins that generate source code are particularly problematic * the public repositories are poorly managed, and managing a repository yourself is an unnecessary pita * etc. etc. Don't get me wrong, I'd rather deal with Maven than a twisty maze of Ant scripts, but let's not be blinded to the (significant!) issues that remain...
    Reply to this Reply to original

  11. Re: why use maven 1.x[ Go to top ]

    BTW, Maven 2 rocks :)

    It's good, but let's not get too carried away. M2 is an incremental improvement over M1 and a declarative model is (imvho) generally better than an imperative one (which is why I prefer Maven to Ant), but the implementation still leaves a lot to be desired.

    A couple of examples:
    * version handling is weak, particularly in the context of dependencies
    What do you mean? It manages dependencies/version as defined within their POM. So yes, if some distro now depends on a different version, it would download and use that. If you don't like it, either discuss with the maintainer or create your own maven and resolve these dependencies.

    * many plugins are of alpha or beta quality
    * plugins tend not to play well together - plugins that generate source code are particularly problematic
    This doesn't necessarily reflect upon the maven itself. If the plugins had an issue with the maven API that would be different. Most of these plugins are developed by someone else, so their quality is not equivalent to maven's quality. Though I understand that if you don't have the right plugins, then maven itself might become useless.

    * the public repositories are poorly managed, and managing a repository yourself is an unnecessary pita
    * etc. etc.

    It beats having to manage dependencies using ant and distributing them along with the source to every developer. With maven, a software company can set up a repo and all of their developers benefit from it, without having to check them into source control and distribute. Of course you still distribute them with the app for runtime. Ilya
    Reply to this Reply to original

  12. Re: why use maven 1.x[ Go to top ]

    What do you mean?
    The two problems with version handling / dependency resolution that I repeatedly run into are: 1. no standard version number format, resulting in unexpected behaviour in the presence of unusual version numbers (such w.x.y-RCz or yyyymmdd). Why Maven imposes a standard directory structure then neglects to impose a standard version numbering scheme (to make dependency resolution deterministic) is beyond me... 2. Maven doesn't provide different "strengths" of dependency, which is critical in the presence of a large dependency graph with lots of shared dependencies. See MNG-2480 for more details.
    * plugins tend not to play well together - plugins that generate source code are particularly problematic
    This doesn't necessarily reflect upon the maven itself. If the plugins had an issue with the maven API that would be different.
    The problems I've seen with plugins not playing well together stem from limitations in the way Maven determines the order in which to execute multiple plugins bound to the same lifecycle stage. Although there are often dependencies between plugins (or more accurately, between goals in different plugins), Maven provides no way for the plugin author to express those dependencies. And yes many plugins are of alpha or beta quality as well (which is also a pita), but clearly that isn't an issue with Maven itself.
    Reply to this Reply to original

  13. Re: why use maven 1.x[ Go to top ]

    What do you mean?

    The two problems with version handling / dependency resolution that I repeatedly run into are:

    1. no standard version number format, resulting in unexpected behaviour in the presence of unusual version numbers (such w.x.y-RCz or yyyymmdd). Why Maven imposes a standard directory structure then neglects to impose a standard version numbering scheme (to make dependency resolution deterministic) is beyond me...

    2. Maven doesn't provide different "strengths" of dependency, which is critical in the presence of a large dependency graph with lots of shared dependencies. See MNG-2480 for more details.
    I often have dependency problems when the same API is available under different group and artifact ID. cglib being a prime example. It is a royal pain to try to identify all the different ways a particular API is included, then ensure only one version is used.
    Reply to this Reply to original

  14. Re: Release of a new Maven plugin : the Maven Author Plugin[ Go to top ]

    We initially started with maven 1.x then moved to maven 2, but we didn't find the transition to be difficult, maybe is because we didn't have that many plugin configurations. Most if not all of the maven 1.x plugins are available in maven 2, and maven 1.x doesn't even support transitive dependencies, people should really move to maven 2 if they are going to be using maven.
    Reply to this Reply to original

  15. Re: Release of a new Maven plugin : the Maven Author Plugin[ Go to top ]

    Hi Eric, Congrats! It is very interesting project and certainly would be the holy grail of any project manager... Exactly that: the holy grail. Unless you implement an SCM based author assignment, you should not be able to rely on JavaDoc, nor assume that all changes to this file will be done by the same author. It is a very very ambitious task, you would have to do a build for every version of each file in order to collect valid statistics. Basically, you should not allow 2 revisions of the same file by 2 different authors to be included in the same build... The amount of stats will be very very high. Theoretically possible, I'd love to see it coming through! All the best Benoit QALab (simpler aggregation for trends only) http://qalab.sourceforge.net
    Reply to this Reply to original