Web xml is always created

[sobrle]

If you invoke gulp war to compress target folder to war file existing web.xml file if overriden by new web.xml.

I'm suggesting that in options there should be a option to skip creating web.xml. Something like options.skipWebXml which default would be false.

[Typhlosaurus]

@sobrle: gulp-war only does two things - it adds a web.xml file and an empty META-INF to its input stream. The compression is implemented separately, by gulp-zip. If you don't need gulp-war to provide a web.xml file is there much point using it?

Would adding an option to specify additional content to the web.xml be of use to you? E.g. options.webXmlContents = '<...>'

[sobrle]

I came across this situation: I'm using your plugin with maven-gulp plugin. Maven creates everything (target directory where jars, classes and everything else is) and then I invoke gulp to combine/minify all scripts, CSS files and everything else and that works fine. Then I invoke gulp war to compress target folder to war file.

In this situation I don't need gulp war to create web.xml file, just to compress folder into war file. And that works ok, except web.xml file is overriden.

[Typhlosaurus]

@sobrle In your position I would suggest using gulp to generate my assets before using maven to generate the war file, as maven has much deeper understanding of war files than this project will ever have.

On the other hand, I'm tempted to reverse your suggestion: if the stream contains a web.xml file, I'd be tempted not to replace it unless explicitly told to do so in options. How does that sound to you?

[sobrle]

I tried that way, but I wan't successful. So I tried other way around (maven war to clean/compile/copy all things to target) and then invoke gulp to perform tasks only on frontend files. Maven is great for creating war, but it doesn't support operations like gulp.

Your suggestion is great!

[andrewfinnell]

I'd argue that WAR in and of itself IS the compression of webapp files following a specific pattern. Having the ZIP operation outside of the pipe seems like it makes sense within the context of gulp, however, I would argue that it doesn't make sense within the context of creating a WAR.

There are two concepts:

• WAR: A zipped collection of files following a specific folder structure which also includes a web.xml file. The resulting singular file can be deployed to JEE/WAR compatible servers.
• Exploded-WAR: A WAR file which has then been unzipped.

Unfortunately, the process here becomes reversed all too often. An exploded-war is technically a WAR file which has already been built (i.e. zipped) and then is unzipped into a specific location.

I'll argue that the gulp-war module is a misnomer seeing as it doesn't zip the contents into a file ending in .war. The gulp task has the potential of being this:

var war         = require('gulp-war'),
    warwebxml   = require('gulp-war/web-xml'),
    warexcludes = require('gulp-war/excludes'),
    warmanifest = require('gulp-war/manifest');

gulp.task('war', function () {
    gulp.src(["src/main/webapp/**"], { base: "src/main/webapp" })
        // Keeping with the Gulp stream mechanics, we pipe all the source
        // material to the war task. The module can create then add sources
        // such as the web.xml, MANIFEST.MF or any other such WAR specific
        // material. It could even rearrange a folder struture if the incoming
        // glob doesn't fit the 'WAR structure', but that's for a later release. 

        // Add the web.xml to the stream. This won't be needed if
        // the web.xml is already in the glob stream.
        .pipe(warwebxml({
           // options           
           welcome: 'src/main/webapp/WEB-INF/index.html',
         }))
        // Add the MANIFEST.MF to the stream. This won't be needed if
        // the MANIFEST.MF is already in the glob stream.  
        .pipe(warmanifest({
           // options
         }))
        // Prune certain files from the final WAR file. This seems to
        // be difficult to do without creating complicated globs. Perhaps
        // an excludes task would make it easier and more akin to Maven WAR type. 
        .pipe(warexcludes({

         })) 
        .pipe(war({
            displayName: 'Grunt WAR',
            // We can use the original contents before being ZIP'ed to create an
            // exploded WAR. While I just talked about it above, it's still an easy shortcut.
            type: "war|exploded|both",
            target: 'MyWebApp' // 'MyWebApp' without extension, it can be auto-added.
            // targetDir: 'MyWebApp-exploded' 
        }))
        // Creates a WAR file just like Maven
        .pipe(gulp.dest("./target"));
});

This follows the 'Gulp war' in my opinion. The web.xml file can come from anywhere within the stream, even auto-created by a webxml creator. And perhaps someone creates a more robust web.xml creator later; this allows us to change it to use theirs but keep the same flow intact.

The war task SHOULD zip the contents. It shouldn't create any files except the final webapp file ending in a .war. If this module were to become more like what I've posted above it could completely replace the need for Maven's own WAR plugin. I'm finding that I am able to do more with less with Gulp and wish to migrate all that I can into it. At least what makes sense. Creating a ZIPPED WAR is the perfect job for Gulp.

Ideas?

If this post gets enough attention I can add all of these features and/or take over the project if you'd like. I appreciate the time and attention to this.