println it

Software blog about tools, builds and making it all work

New Maven plugins released!

Note, an update is available.

After a lot of work I released version "0.1" of the following Maven plugins:

  • "maven-copy-plugin" is an alternative to Maven plugins like assembly, resources, dependency, and truezip. Its purpose is to make working with archives and dependencies very easy.

    It is a Swiss Army knife if you need to copy, pack and unpack files, archives and Maven dependencies. Content replacement, network support, Groovy extension points, attaching archives created as Maven artifacts – it is possible to perform all operations in a single Maven plugin! Oh boy, just give it a try.

  • "jenkins-maven-plugin" allows to generate Jenkins jobs, keeping any amount of them in a single POM. Jobs can be organized hierarchically with inheritance and can invoke each other, Artifactory deployment is supported as well. Managing tens or hundreds of Jenkins jobs becomes possible when they are kept in one place and inherit each other with a sensible defaults.
  • "maven-spring-batch-plugin" allows to invoke Spring Batch jobs as part of Maven build.
  • "maven-mail-plugin" allows to send mails with attachment from Maven.
  • "maven-sshexec-plugin" allows to execute commands on a remote server over ssh.
  • "maven-properties-plugin" allows to create Maven properties dynamically with Groovy snippets.
  • "maven-timestamp-plugin" allows to create a timestamp Maven property.
  • "maven-assert-plugin" allows to verify various build assertions: properties are defined, files exist and files/directories content is identical.
  • "maven-find-plugin" allows to set a Maven property to location of folder dynamically found for each module built. It helps in situations where build needs to access files in other locations than the current module.

, , , , , , , , , ,

33 Responses to “New Maven plugins released!”

  • JBaruch says:

    You *really* should switch to Gradle. All this mingling around Maven plugins is so EJB2!

    • I agree, Baruch. But believe it or not, there are people out there that still use Maven and will be using it tomorrow. So Maven plugins, Ant Contrib and lots of other “EJB2-like” tools are still required and used.

  • joe says:

    Great that you add more plugins.
    I don’t want to switch to gradle, I like standardised builds, made up from configured components.

    If only the m2eclipse would not be such a crap and the xml a little less (will be soon though):
    currently I do timestamps with the buildnumber plugin.





    • I believe every technology has its place. Maven 2, Maven 3, Gradle or anything else – there are reasons why people choose them and most of them are valid.

      I always said that XML-based declarative POMs work better for larger companies where lots of people with varying expertise have a need to modify them. But they’re pain in the a** when your POM logic starts getting complex and you have some kind of modifiable state and different flows of execution – in those cases Groovy and Gradle are really needed.

      “maven-properties-plugin” allows to create any kind of Maven property with a Groovy expression, including timestamps. So it makes “maven-timestamp-plugin” obsolete, but I decided to keep it for its name and slightly easier use.

  • A, Mitev says:

    What do you mean by “so EJB2″?

  • Thanks for your contribution,
    I still use maven, I’ll keep using it tomorrow since my entire work basis is based on Maven.

    I believe our folks of SpringRoo will keep using maven too.

    So, again, thanks for your work.

  • Francois Ritaly says:

    Your maven-hudson-plugin looks really very interesting. I have to administer a maven multi-module project with more than 90 modules. The build is very long (between 1-2 hours) when all modules have to be compiled. The incremental build feature of hudson can save a lot of time but I’d like to test another solution where each module would have its own hudson job. Obviously, this can hardly be manually administered let alone when there are parallel development branches. So thank you ! I’ll give your plugin a try.

  • Stephen says:

    Evgeny – great plugin! We have over 100 jobs, but only about three types of jobs. This plugin allows me to update only the project id and repository path. Much appreciated.

    I would like a better approach to reporters/publishers/buildWrappers though. CDATA of xml is kinda rough. :D

    I see that 0.2-beta2 is out. Where can I find a changelog from 0.1?

    Thanks again!

    • Hi Stephen,

      Thanks, I’m very glad to hear you’ll be able to put them into real use. That was the whole idea – to let other people use what helped me once.

      As for you questions:

      * I didn’t post detailed changelog for beta versions that followed “0.1″ because I’ll do it when “0.2″ is released. But they are available in YouTrack:

      * Better supporting of reporters, publishers etc is not simple due to great number of options possible. I can provide support for special Hudson options asked by people, but to cover all possible options that Hudson can use those tags would be too much work, so I decided to leave a raw XML “extension points” for all that was left out. Is there anything special that may help you?

      • Mohan says:

        Great work on the plugins, Unfortunately does not work with 2.0.x series of Maven. Is it possible to release this with Maven 2.0.x?


        • Hi Mohan, Thank you! Maven version “2.0.x” is so old that you’re the first person that ever mentions it. What stops you from upgrading to “2.2.1″ or “3.0.x”? Those two versions are used for regular tests.

  • sans17 says:

    I am getting:
    [ERROR] Failed to execute goal com.goldin.plugins:maven-properties-plugin:0.2:set-properties (set-properties) on project maven-test: Execution set-properties of goal com.goldin.plugins:maven-properties-plugin:0.2:set-properties failed: Plugin com.goldin.plugins:maven-properties-plugin:0.2 or one of its dependencies could not be resolved: Failure to find com.goldin:gcommons:jar:0.4 in was cached in the local repository, resolution will not be reattempted until the update interval of plugins-releases has elapsed or updates are forced -> [Help 1]
    Do I do something wrong?

  • Ydelo says:

    Hi !

    Thanks for your work, it could suit my needs very well !

    However, i’m trying to use maven copy plugin to copy some files by scp under windows, and it does not work.

    I get an error : the syntax of filename, directory or volume is incorrect):

    [ERROR] La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte La syntaxe du nom de fichier, de répertoire ou de volume est incorrecte
    at Method)
    at com.goldin.plugins.copy.CopyMojo.copy(CopyMojo.groovy:484)

    and so on.


    Windows native method is unable to read scp path like :


    Am I doing something wrong, or more probably, scp under windows is not supported yet ?

  • [...] "0.1" release of Maven plugins back in November brought a lot of attention to the project which showed me Maven [...]

  • Phani says:

    How to do incremental build via Maven with Hudson ?

  • Cagri says:

    Thank you for the plugins.

  • Bob says:


    great plugins you have written!

    I am trying to use the upload scp functionality from the maven-copy-plugin. I want to copy a generated war to a remote jetty server.

    Is it possible to execute the copy command on demand with some mvn command or one have to use the executions maven feature? I do not want to tie uploading my war to remote server to be redeployed in the jetty container to some existing maven phase.

    Thanks for the answer!

    • Hi Bob,

      Tying scp plugin execution to a certain phase is what I did, I think it was “deploy”. You can try executing the plugin from the command line but I never did so. What is the reason you don’t want to bind it to existing phase?

      • Bob says:

        Tying to deploy phase means putting artefact (war) into our company nexus and I do not want to do that for every snapshot I make – over time nexus would containt hundreds of heavy artefacts.

        Currently I have tied the scp to a package phase, but this obviously is not a solution.






        Can you give me an example of how to copy the war to a remote server? Also, a solution which uses username and password from my settings file or even better – authenticate via my ssh generated key.

        Thanks for any input.

        • In this case you can still tie the invocation to any phase like “deploy” and then put the plugin configuration in profile so that it’s not run by default. The file will be copied only when "mvn deploy -PmyProfile" is invoked.

          SSH key authentication isn’t supported yet, you can follow this issue.

          One thing you can do is to use a “maven-properties-plugin” to read authentication data (user and password) from a file and define ${user} and ${pass} properties which can then be used to configure the copy plugin scp copy operation.

          “maven-properties-plugin” has a “verbose” flag just for that purpose – setting it to “false” doesn’t echo the properties defined. I use it to set FTP/SCP paths for my tests this way.

  • Adam says:

    Was hoping you could help I’m trying to use your copy-plugin with mvn 304 but get:

    Execution default of goal com.goldin.plugins:maven-copy-plugin: failed: A required class was missing while executing com.goldin.plugins:maven-copy-plugin: org/springframework/beans/factory/InitializingBean

    my pom extract is:





    any ideas?



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>