GithubHelp home page GithubHelp logo

grunt-maven-tasks's Introduction

grunt-maven-tasks

Grunt maven tasks - install artifacts locally or deploy and release articats to maven repository.

Getting Started

This plugin requires Grunt ~0.4.1

If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:

npm install grunt-maven-tasks --save-dev

Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:

grunt.loadNpmTasks('grunt-maven-tasks');

Supported Maven Goals

no goal

If no goal is specified, the goal will be set to the target name. This means that the target name must be one of install, deploy or release. For more flexibility with the naming of your targets, and/or having multiple targets with the same goal, specify the goal explicitly.

package

Run the grunt package task with the goal option set to package.

This tasks packages an artifact.

install

Run the grunt maven task with the goal option set to install.

This tasks packages and installs an artifact to your local maven repository.

deploy

Run the grunt maven task with the goal option set to deploy.

This tasks packages and deploys an artifact to a maven repository.

release task

Run the grunt maven task with the goal option set to release.

This task packages and releases an artifact to a maven repository. It will update the version number in the package.json file to the next development version, and, if this is a git project, it will commit and tag the release.

By default, it will increment the version number using the minor version. This can be overridden in the config section using the mode option.

Run this task with the grunt maven:[your-task-target]:major command to bump the next development version using the major version mode.

Run this task with the grunt maven:[your-task-target]:1.2.0 command to release version 1.2.0.

Run this task with the grunt maven:[your-task-target]:1.2.0:major command to release version 1.2.0 and bump the next development version using the major version mode.

Overview

In your project's Gruntfile, add a section named maven to the data object passed into grunt.initConfig().

grunt.initConfig({
  maven: {
    options: {
      goal: 'deploy',
      groupId: 'com.example',
      url: '<repository-url>',
    },
    src: [ '**', '!node_modules/**' ]
  }
})

Options

options.versionFile

Type String Default: package.json

Identifies the file that contains the version file to read. (E.G. bower.json)

options.goal

Type String Default: target name

The maven goal for the target artifact. Valid values are 'deploy' and 'release'. Defaults to the target name

options.groupId

Type: String Required

The maven group id to use when deploying and artifact

options.artifactId

Type: String Default: name found in package.json

The maven artifact id to use when deploying and artifact

options.version

Type: String Default: version found in package.json or the file specified by options.versionFile

The version to use when deploying to the maven repository

options.classifier

Type: String Optional

The classifier to use when deploying to the maven repository

options.uniqueVersion

Type: String Optional

Allow to generate timestamped artifacts.

options.mode

Type: String Default: minor

The mode passed to semver.inc to determine next development version.

options.packaging

Type: String Default: zip

The packaging to use when deploying to the maven repository. Will also determine the archiving type. As internally the grunt-contrib-compress plugin is used to package the artifact, only archiving types supported by this module is supported.

options.url

Type: String Required

The url for the maven repository to deploy to.

options.repositoryId

Type: String Optional

The repository id of the repository to deploy to. Used for looking up authentication in settings.xml.

options.type

Type: String Optional

Enables you to choose a different file extension for your artifact besides .zip which is useful when using the Maven WAR-plugin

options.injectDestFolder

Type: String Optional

Enables you to turn off the injection of destination folder inside your artifact allowing you to choose the structure you want by configuring the compress task.

options.destFolder

Type: String Optional

Specifies the name of the folder to be injected inside the artifact. If not specified, this will be auto-generated.

options.commitPrefix

Type: String Optional

Prefix for the commit message when releasing.

options.gitpush

Type: Boolean Optional Default: false

If true, runs git push after updating the package.json with the next version.

options.gitpushtag

Type: Boolean Optional Default: false

If true, runs git push for the tag after updating the package.json with the next version.

options.unsecure

Type: Boolean Optional

If true, runs maven with -Dmaven.wagon.http.ssl.insecure=true and -Dmaven.wagon.http.ssl.allowall=true

options.settingsXml

Type: String Optional

Specifies the settings.xml file for -s argument.

options.optionalParams

Type: Array Optional

Appends more optional parameters for mvn deploy. optional parameters list

Files

Files may be specified using any of the supported Grunt file mapping formats.

Usage Examples

Default Options

In this example, only required options have been specified and the 'goal' is defaulted to the target name.

Running grunt maven:deploy will deploy the artifact to the snapshot-repos folder using the groupId com.example, the artifactId set to the name in package.json and the version set to the version in package.json.

Running grunt maven:release will deploy the artifact to the release-repo folder using the groupId com.example, the artifactId set to the name in package.json and the version set to the version in package.json, but with the -SNAPSHOT suffix removed. The version in package.json will be incremented to the next minor SNAPSHOT version, ie. if it was 1.0.0-SNAPSHOT it will end up at 1.1.0-SNAPSHOT. If this is a git repository, it will also commit and tag the release version, as well as commiting the updated package.json version.

grunt.initConfig({
  maven: {
    options: { groupId: 'com.example' },
    'package': {
      options: {
        goal: 'package'
      },
      src: [ '**', '!node_modules/**' ]
    },
    deploy: {
      options: {
        goal: 'deploy',
        url: 'file://snapshot-repo'
      },
      src: [ '**', '!node_modules/**' ]
    },
    release: {
      options: {
        goal: 'release',
        url: 'file://release-repo'
      },
      src: [ '**', '!node_modules/**' ]
    }
  }
})

grunt.registerTask('package', [ 'clean', 'test', 'maven:package' ]);
grunt.registerTask('deploy', [ 'clean', 'test', 'maven:deploy' ]);
grunt.registerTask('release', [ 'clean', 'test', 'maven:release' ]);

The maven task can be configured to support deployment or release of multiple artifacts:

grunt.initConfig({
  maven: {
    deployA: {
      options: {
        goal: 'deploy',
        groupId: 'com.example',
        artifactId: 'myNodeArtifact',
        url: '<repository-url>',
      },
      src: [ '**', '!node_modules/**' ]
    },
    deployB: {
      options: {
        goal: 'deploy',
        groupId: 'com.example',
        artifactId: 'myBrowserArtifact',
        url: '<repository-url>',
      },
      src: [ 'target/browser/**', '!target/browser/node_modules/**' ]
    }
  }
})

Custom Options

In this example, the artifactId has been explicitly set, and the version bumping used when releasing is set to 'patch' level rather than the default 'minor'.

grunt.initConfig({
  maven: {
    options: { groupId: 'com.example', artifactId: 'example-project' },
    deploy: {
      options: { url: 'file://snapshot-repo' },
      src: [ '**', '!node_modules/**' ]
    },
    release: {
      options: { url: 'file://release-repo', mode: 'patch' },
      src: [ '**', '!node_modules/**' ]
    }
  }
})

In order to customize the output archive, please look at the documenations for the grunt-contrib-compress task.

Contributing

In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt.

grunt-maven-tasks's People

Contributors

andrelion avatar daniel-franz avatar drewzboto avatar garethhunt avatar jbcpollak avatar jonhaug avatar leftiefriele avatar mlarcher avatar scottydawg avatar smh avatar soygul avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

grunt-maven-tasks's Issues

Add possibility to provide username

Add option to provide a username corresponding to maven 'username' option. This to provide possibility to push code if checked out as another user.

Make the src part of global options

Hello,

Right now the src property has to be set on goals individually:

options: {
    src: ['dist/**']
}

The result is an empty zip. Which means I have to do this:

options: {
    ...
},
install: {
    src: ['dist/**']
},
deploy: {
    src: ['dist/**']
},
release: {
    src: ['dist/**']
}  

It would be nice if the goals picked the src from the global options (specifying a src in the goal would obviously override the global setting).

Release target fails trying to delete tag.

When performing a "grunt release" everything goes smoothly until the task tries to delete a tag with the SNAPSHOT version. I don't see where this tag is getting set either.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 12 minutes 11 seconds
[INFO] Finished at: Sun Mar 23 22:13:15 PDT 2014
[INFO] Final Memory: 7M/374M
[INFO] ------------------------------------------------------------------------
Deployed ui-web-0.4.0.zip to https://nexus.myhouse.com/nexus/content/repositories/MYHOUSE

Running "maven:version:0.5.0-SNAPSHOT:deleteTag" (maven:version) task
Version bumped to 0.5.0-SNAPSHOT
Deleting tag v0.5.0-SNAPSHOT...ERROR
>> Failed to delete tag v0.5.0-SNAPSHOT
Warning: error: tag 'v0.5.0-SNAPSHOT' not found. Use --force to continue.

Aborted due to warnings.

Is there a step I'm missing?

Artifact isn't built from the released version

The artifact used is based off the starting commit, not the released commit.
For instance if you are releasing 1.1.0 and have a file that uses the "replace" grunt plugin to copy in the version, it will copy the '1.1.0-SNAPSHOT' from the package.json. The build is run before the version is bumped.

The following (line 124 of maven_tasks.js at time of writing) shows the relevant part of the code.

 grunt.task.run(
      'maven:version:' + options.version,
      'mvn:package',
      'maven:deploy-file',
      'maven:version:' + options.nextVersion + ':deleteTag'
    );

What I think needs to happen is an option, say buildTask, for a grunt task to be run after the first maven:version, but before the mvn:package. Then I could set buildTask to 'build' (which is currently run before the grunt-maven-tasks maven:release task) and have the build actually be against the correct version.

Upgrade grunt-contrib-compress

I am trying to use this plugin to create a webjars. The use of webjars (from Java) typically involves scanning the Java classpath for webjars structure (META-INF/resources/webjars).

Currently webjars created by this plugin are unusable because of this grunt-contrib-compress issue. Since folders are not included in the zip/jar created by the task maven:package, the Java classloader is unable to find META-INF/resources/webjars in classpath.

Fix: Upgrade the dependency to grunt-contrib-compress from 0.7.0 (current dependency version) to 0.9.1 (or newer). I can submit a pull request to fix (just) this, but I do not know if such a change will require additional changes in the plugin....

Maven tasks and svn tags

Very nice plugin, is it possible to have svn version tags during the release phase as SCM provides?

Thanks a lot 😉

Maven release works sucessfully, failure on delete-tag

On executing the task, the upload to Nexus works perfectly, as does the version change in package.json.

However the task then fails when trying to delete the tag with the new version from Git - it doesn't exist, and I'm not sure why it should. Am I doing something wrong? Or is there a way to prevent the tag deletion step? I could force it through, although I'd prefer not to.

My (sanitised) config from Gruntfile.js:

maven: {
            options: {
                groupId: 'com.jim.fred',
                repositoryId: 'nexus',
                gitpush: false,
                gitpushtag: false
            },
            deploy: {
                options: {
                    goal: 'release',
                    url: 'http://user:[email protected]/content/repositories/releases',
                    mode: 'patch',
                    destFolder: 'jimbo',
                },
                files: [
                    {
                        expand: true,
                        cwd: 'build/',
                        src: ['**']
                    }
                ]
            }
        }

Goal release is not pushing the new tag and version changes to remote for git

Hi there,

We are using bamboo, nexus and git for release. I have configure bamboo to checkout the code from remote git, then do the build/release which should including step upload artifacts to nexus, create new tag in git, update new version with snapshot keyword. It is all working good, however the last step which is push the changes(new version tag and new snapshot keyword changes) are not push back to git remote.

Am I missing something or this is not a function currently available?

Thanks

Async race condition when compressing and renaming

On the continue integration server I have a problem. I sometime get an error that it can't rename the zip artifact before deploying it to artifactory. I have isolated the problem to mvn:package task. The problem is that it starts packaging the folder but does not wait to finish before going to rename the function, so it is possible that the archive is not yet created. The rename should be called in the callback of the compress.tar and after that the async should be finished.

Or am I missing something?

Need 'cwd' in addition to 'injectDestFolder'?

I'm struggling a bit here.

My grunt config puts its generated files in /target

One example file is /target/css.style.css

I've configured the compress plugin like this to produce the artifact I need.

compress: {
            main: {
                options: {
                    mode: 'zip',
                    archive: 'ajar.jar'
                },
                expand: true,
                cwd: 'target/',
                src: ['**/*'],
                dest: 'META_INF/resources/webjars/'
            }
        }

The ajar.jar file contains this file:
META_INF/resources/webjars/css/style.css

Now, I'm trying to get the same result with the maven plugin. This is the closest I get

maven: {
            options: {
                goal: 'install',
                groupId: 'agroupid',
                artifactId: 'anartifactid',
                version: '1.0-SNAPSHOT',
                packaging: 'zip',
                type: 'jar',
                injectDestFolder: 'META_INF/resources/webjars/',
                url: 'file://snapshot-repo'
            },
            src: 'target/**/*'
        }

Now, the jar contains the same file in this location (not what I want):
src/target/webjars/css/style.css

Any suggestions? Is this possible with the current options?

Thanks!

Packaging .zip includes artifact name as a folder

if I have this:

dist/
    something.js
images/
    myImage.png

I can use cwd: 'dist' to get the 'dist' out of my archive.

sadly, say my deployment artifact is called myArtifact-0.1.0

the zip files structure is:

myArtifact-0.1.0/
    something.js
    images/ 
        myImage.png

so the damn artifact name becomes a folder INSIDE THE ZIP

how the hell can I turn that off?

version isn't being appended with -SNAPSHOT on deploy goal

Maybe i'm doing something wrong hah.. my config:

module.exports = {
    install: {
        options: {
            goal: 'install',
            groupId: 'com.company'
        },
        src: [ 'dist/**', '!node_modules/**' ]
    },
    deploy: {
        options: {
            goal: 'deploy',
            groupId: 'com.company',
            repositoryId: 'company-nexus',
            url: 'http://myrepoUrl/company-snapshots'
        },
        src: [ 'dist/**', '!node_modules/**' ]
    },
    release: {
        options: {
            goal: 'release',
            groupId: 'com.company',
            respositoryId: 'company-nexus',
            url: 'http://myrepoUrl/company'        
        },
        src: [ 'dist/**', '!node_modules/**' ]
    }
}

I have to manually put version: 0.1.0-SNAPSHOT in my package.json, or it will try to deplly 0.1.0 to the snapshots repo which fails.

Provide a way to sign target jar file

I'm using grunt-mavn-tasks to deploy my JS to Nexus. However my Nexus release repository server accepts only signed artifacts: grunt-maven-tasks should support signing jar files

Bumping version not working

Hi,
I am using grunt-maven-tasks version 1.3.2 and getting following error when doing maven:release. Although maven deploy works fine since it doesn't do bumping the version. My package.json has version : "version": "1.2.0-SNAPSHOT".
Also is there any option to stop bumping of version and commit on git automatically?

Bumping version to 1.2.0...ERROR

Failed to bump version to 1.2.0
Warning: 'C:\Program' is not recognized as an internal or external command,
operable program or batch file. Use --force to continue.

Aborted due to warnings.

My grunt settings are :
maven: {
options: {
groupId: mavenGroupId,
artifactId: mavenArtifactId,
commitPrefix: ' ',
repositoryId: ''
},
deploy: {
options: { url: mavenSanpshotUrl },
src: [ disuiPath + '//*' ]
},
release: {
options: { url: mavenReleaseUrl, mode:'patch'},
src: [ disuiPath + '/
/*' ]
}
}

packaging includes the root folder where the files reside

I am having issues getting the compressed archive to have the desired file structure. When I have this configuration in my Gruntfile:
maven:{
deploy: {
files: [ { src: [ 'target/**' ] } ]
}
The resulting archive contains the 'target' folder, which is a problem as it can not be used in a Maven project without doing some sort of filtering. What I expected was for the archive to contain everything from 'target', not the target folder itself.
Is this a bug or is there some configuration to around this?

Add possibility to disable version bumping

Nice plugin.

Adding the possibity to disable version bumping would provide more flexibilty of versioning (e.g. in creating a svn tag before bumping next pre-release version)

How to run 'mvn clean install' from gruntfile?

I have a Javascript project that uses Grunt to build. As part of the grunt tasks, I need to build and package a Java project which uses Maven. Here's the folder structure of my project

_javascript-project
*_js-src(contains js files)
**external
**agents(contains java mvn project)
*
**src
***_pom.xml(this needs to be built)
*_Gruntfile.js
*_package.json
*_pom.xml(dummy placeholder for javascript project)

To build this javascript project we use grunt install. Now as part of this grunt install, I need to build the mvn project under external folder. I do not need to deploy or release it to any remote repository. I just need to build it locally. Here's the sample of Gruntfile.js

// Project configuration.
grunt.initConfig({
...(normal tasks to build js files)
maven: {
options: {
debug: 'true',
goal: 'install',
groupId: 'org.example',
url: ''
},
src: [ 'external/agents/**', '' ]
}
});

grunt.loadNpmTasks('grunt-maven-tasks');

grunt.registerTask('install', ['maven']);

Can you help me to run 'mvn clean install' on the external agent folder when 'grunt install' is run on the Javascript project?

Make url options not mandatory

Hi,

Very nice plugin, although in this (very corporate) environment some small changes would make my life much easier.

Basically only the integration server has user rights to deploy to Maven.
This means normal users can only do a maven install and not a maven deploy.
All the necessary information (URLs and user info) are available in said settings.xml, which is picked by Maven by default.

Would it be possible to just ignore missing url information?

On a related note, I can't seem to be able to specify the local repository (tried file:///~/.m2/repository), but that would also be solved by just using defaults...

Add possibility to specify pom

I'm working on a multi-module project, in which only one module is using Grunt. I want to invoke maven goals in sibling modules. It would have been great if I could specify the target pom in this plugin.

Great plugin though!

Update to use grunt 1.0.0

Grunt has released 1.0.0, since this has a peer dependency on 0.4.5 then this cannot be used in conjunction with other up to date grunt plugins.

Note, this will also require you to bump the grunt-contrib-compress version as well as the version you are using is also out of date. This would fix #36.

Allow to pass commit message when bumping version

It would be good to supply some special commit message when 'npm version' command bumps the project version, like the maven release plugin does. Or, perhaps, just make the message customizable. That would allow to configure continuous integration servers to ignore commits from 'grunt maven:release' execution.

allow for prerelease versions

Hi,

I noticed that grunt-maven-tasks currently doesn't handle prereleases version (e.g. 1.0.1-3) because the version of semver it depends on currently doesn't allow it.

Upgrading the semver depency to the current one (~2.3.1) would fix the problem and let us handle more precise release versions numbers.

Clean up zip/war files after deploy

Currently the zip/war file seems to be left over after the deploy. Can produce the binary in a /maven folder, so that we can add that folder to the grunt clean task? Would help clean up after ourselves, and have a folder to also exclude from source control

Option to Skip Packaging Step for Deploy

Is it possible to add an option to skip the packaging step for the deploy task? The artifacts I want to deploy are already packaged by my build, I just want to push them to maven.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.