在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称(OpenSource Name):allegro/grunt-maven-plugin开源软件地址(OpenSource Url):https://github.com/allegro/grunt-maven-plugin开源编程语言(OpenSource Language):Java 100.0%开源软件介绍(OpenSource Introduction):grunt-maven-pluginDeprecation note
grunt-maven-plugin plugin allows you to integrate Grunt tasks into the Maven build process. Grunt is the JavaScript task runner utility. grunt-maven-plugin works on both Windows and *nix systems. grunt-maven-plugin comes with unique Maven+Grunt Integrated Workflow which removes all impediments present when trying to build project using two different build tools. Version 1.5.0 requires grunt-maven NPM plugin 1.2.0 version for Integrated Workflow to work. PrerequisitesThe only required dependency is nodejs with npm. Globally installed grunt-cli is optional and preferred, but not necessary, as installing custom node modules can be problematic in some environments (ex. CI servers). Additional configuration is needed when using local grunt-cli. grunt-maven-plugin can also run grunt-maven-plugin is compatible with JDK 6+ and Maven 2.1+. Motivationgrunt-maven-plugin came to life because I needed a good tool to integrate Maven and Grunt. By good i mean not just firing off a grunt process, but a tool that would respect rules from both backend (Maven) and frontend (Grunt) worlds. No node_modules in Maven sources, no Maven src/main/webapp/.. paths in Gruntfile.js. grunt-maven-plugin allows you to create a usual NPM/Grunt project that could be built and understood by any Node developer, and put it somewhere inside Maven project. It can be extracted at any time and nothing should break. On the other side backend developers don't need to worry about pesky node_modules wandering around src/ - all dependencies, generated sources and deliverables live in dedicated target-grunt directory, doing this part of build the Maven way. UsageAdd grunt-maven-plugin to application build process in your pom.xml: <plugin>
<groupId>pl.allegro</groupId>
<artifactId>grunt-maven-plugin</artifactId>
<version>1.5.0</version>
<configuration>
<!-- relative to src/main/webapp/, default: static -->
<jsSourceDirectory>path_to_js_project</jsSourceDirectory>
<!-- example options usage to get verbose output in logs -->
<gruntOptions>
<gruntOption>--verbose</gruntOption>
</gruntOptions>
<!-- example npm install env variable -->
<npmEnvironmentVar>
<PHANTOMJS_CDNURL>http://cnpmjs.org/downloads</PHANTOMJS_CDNURL>
</npmEnvironmentVar>
<!-- example options usage to filter variables in given resource -->
<filteredResources>
<filteredResource>maven-properties.json</filteredResource>
</filteredResources>
</configuration>
<executions>
<execution>
<goals>
<goal>create-resources</goal>
<goal>npm</goal>
<!-- or npm-offline if npm failure is not an option -->
<goal>bower</goal>
<goal>grunt</goal>
</goals>
</execution>
</executions>
</plugin> Usage with local grunt-cliIn order to use local grunt-cli, add <gruntExecutable>node_modules/grunt-cli/bin/grunt</gruntExecutable>
<runGruntWithNode>true</runGruntWithNode> options to plugin configuration and add grunt-cli to JS project package.json: {
"devDependencies": {
"grunt-cli": "~0.1.6",
"grunt": "~0.4.2"
/*...*/
}
} Using NPM in offline modeNPM downtimes can be painful for (some) development and (all) release builds. grunt-maven-plugin contains
npm-offline goal that uses tar-ed node_modules instead of running npm-offline flow:
If node_modules dir already exists in target-grunt, it is not overriden. Offline flow is based on this blogpost. Why only tar, not gz?
If there are some compelling arguments for compressing this archive, please post an issue and we might add support in future releases. Preparing node_modules.tarIn
Using linked node_modulesRemoved in 1.3.0 release, use npm-offline instead. Working exampleSandbox project contains simple usage example. It is used to PoC/develop/test new features, so it always stays up to date with SNAPSHOT version. How it works?
Because the plugin creates its own target dir, it should be added to ignored resources in SCM configuration (like .gitignore). grunt-maven-plugin optionsPlugin options available in misc
environment
node
npm
offline
bower
grunt
Execution goals
Maven+Grunt Integrated workflowUsing grunt-maven-plugin is convenient, but there is still a huge gap between frontend and backend development workflow. Various IDEs (Netbeans, IntelliJ Idea, Eclipse) try to ease webapp development by synchronizing changes made in src/webapp/ to exploded WAR directory in target/. This naive approach works as long as there is no need to minify JavaScript sources, compile less files or project does not follow "single WAR" rule and can afford using Maven profiles. Rebuilding project each time a change was made in *.js is a horrible thing. Fortunately grunt-maven-plugin is a great tool to solve this problem. Idea is to ignore IDE mechanisms and run Grunt build each time a change in static files was made. Traditional workflow looks like:
This gives little room to integrate other processes in between. Workflow utilizing grunt-maven-plugin:
Now what happens inside target-grunt is for us to decide, it can be virtually anything - minification, less compilation, running JS tests, JS linting. Anything Grunt can do, just like during heavy build process. Configuring MavenSince we want grunt-maven-plugin to take control of what ends up in WAR, we need to tell Maven WAR plugin to ignore our statics dir when creating WAR: <build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.3</version>
<configuration>
<warSourceExcludes>jsSourceDirectory/**</warSourceExcludes>
</configuration>
</plugin>
</plugins>
</build> Configuring Gruntgrunt-maven-plugin has a dedicated NPM Grunt multitasks that make integrated workflow work. grunt.initConfig({
mavenPrepare: {
options: {
resources: ['**']
},
prepare: {}
},
mavenDist: {
options: {
warName: '<%= gruntMavenProperties.warName %>',
deliverables: ['**', '!non-deliverable.js'],
gruntDistDir: 'dist'
},
dist: {}
},
gruntMavenProperties: grunt.file.readJSON('grunt-maven.json'),
watch: {
maven: {
files: ['<%= gruntMavenProperties.filesToWatch %>'],
tasks: 'default'
}
}
});
grunt.loadNpmTasks('grunt-maven');
grunt.registerTask('default', ['mavenPrepare', 'jshint', 'karma', 'less', 'uglify', 'mavenDist']); For more information please consult documentation of grunt-maven-npm project. Deep customization of workflowIt is possible to override inner workflow configuration during runtime. Inner properties are extracted from pom.xml and used internally inside workflow Grunt tasks. They reside in target-grunt/grunt-maven.json. After reading inner properties JSON file, workflow task seeks for grunt-maven-custom.json file in target-grunt and overrides original properties with custom ones. Configuring IDEDepending on IDE, synchronization processes behave differently. Having JSP files synchronized is a nice feature, so it is up to you to decide what should be turned off. In Netbeans and IntelliJ no configuration is needed, they play nicely with new workflow. You still have to remember to run Grunt watch process in background so it can monitor changes. It can be run from IDE via grunt-maven-plugin. Define custom runner that will run:
You should see process output each time static sources change. Configuring EclipseEclipse is a special case. Unfortunately it does not read WAR from Maven target, instead it keeps own file hierarchy. Eclipse developers on the team should use deep workflow customization to override properties used by others. Proposed way is to create grunt-maven-custom.json in Maven sources and add it to .gitignore, so it will not pollute source repository. Since i have little experience with Eclipse, i would welcome a contribution of sample configuration, but most probably it is enough to override targetPath property. Changelog
Licensegrunt-maven-plugin is published under Apache License 2.0. |
2022-08-15
2022-08-17
2022-09-23
2023-10-27
2022-08-18
请发表评论