build.gradle #24 

apply plugin: 'findbugs'
apply plugin: 'checkstyle'

dependencies {
	compile project(':p4base')
    compile project(':git_fusion')
	compile fileTree(dir: 'vendor', include: '*.jar', exclude: '*-sources.jar')

    runtime files('../doc/build/libs/helix-web-services-2016.1.0-doc.jar')
    runtime files('../swagger/build/libs/helix-web-services-swagger-2016.1.0.jar')
}

// Note: Vendor dependencies are downloaded locally
dependencies {
    vendor 'com.esotericsoftware.yamlbeans:yamlbeans:1.09'
    vendor 'com.esotericsoftware.yamlbeans:yamlbeans:1.09:sources'
    vendor 'com.google.http-client:google-http-client:1.21.0'
    vendor 'com.google.http-client:google-http-client:1.21.0:sources'
    vendor 'com.google.http-client:google-http-client-gson:1.21.0'
    vendor 'com.google.http-client:google-http-client-gson:1.21.0:sources'
    vendor 'com.google.http-client:google-http-client-jackson2:1.21.0'
    vendor 'com.google.http-client:google-http-client-jackson2:1.21.0:sources'
    vendor 'com.sparkjava:spark-core:2.5'
    vendor 'com.sparkjava:spark-core:2.5:sources'
    vendor 'io.jsonwebtoken:jjwt:0.6.0'
    vendor 'io.jsonwebtoken:jjwt:0.6.0:sources'
    vendor 'net.java.dev.jna:jna:4.2.1'
    vendor 'net.java.dev.jna:jna:4.2.1:sources'
    vendor 'org.apache.logging.log4j:log4j-core:2.5'
    vendor 'org.apache.logging.log4j:log4j-core:2.5:sources'
    vendor 'org.apache.logging.log4j:log4j-slf4j-impl:2.5'
    vendor 'org.apache.logging.log4j:log4j-slf4j-impl:2.5:sources'
    vendor 'org.apache.commons:commons-lang3:3.4'
    testCompile 'org.testng:testng:6.9.9'
    testCompile 'org.testng:testng:6.9.9:sources'
    testCompile 'org.testng:testng:6.9.9'
    testCompile 'org.easymock:easymock:3.4'
    testCompile 'org.easymock:easymock:3.4:sources'
    
}

configurations {
    // Pulled in via p4base
    vendor.exclude group: 'org.slf4j', module: 'slf4j-api'
    vendor.exclude group: 'org.slf4j', module: 'slf4j-simple'
}

findbugs {
	ignoreFailures = true
}

tasks.withType(FindBugs) {
	reports {
		xml.enabled false
		html.enabled true
	}
}

tasks.withType(Checkstyle) {
	reports {
		xml.enabled false
		html.enabled true
	}
}

// This will create a "fat jar"
jar {
    archiveName "hws.jar"
    dependsOn ':doc:docJar', configurations.runtime, ":swagger:swaggerJar"
    from {
        configurations.runtime.collect {
            it.isDirectory() ? it : zipTree(it)
        }
    }
    manifest {
        attributes("Main-Class": "com.perforce.hws.server.HelixWebServices" )
    }
}
# Change User Description Committed
#24 19718 dbirch Add checkstyle and findbugs to the builds and publish the reports to a known location.

Initial checkin sets up these for the server project. Will go through and add to other projects and collate the various outputs once I've confirmed this works.
#23 19650 swellard Review fixes
#22 19575 swellard Refactor REST paths
First round
* Remove use of hardcoded repeated strings
* Fix checkstyle issues
#21 19535 drobins Refactor package names to hws
#20 19408 tjuricek Revise system to allow HWS to be "embedded" in another spark 2.5 Service application.

- "WebApp" is now HelixWebServices.
- The initialization process is now broken into several public methods, to work with your own Server instance.

See the HelixWebServices.main method implementation for an example on how to initialize the object, etc.
#19 19399 tjuricek Upgrade to spark 2.5 which requires a different path for the version information.

Spark 2.5's static file matching seems to conflict with just using the "/api" path since a "/publicsite/api" directory actually exists. You end up with a 500 error (NPE exception) if you attempt to map that path.

Also, disable the failing RPM test for now.
#18 19338 tjuricek Create custom reporting mechanism to allow for clear "multiple suite" reports...
with logging!

This standardizes on log4j 2 as the backend (was just used on the server side). We have an "in memory appender" that we use to capture results during testing, which we associate with each method run.

The whole system spits out yaml files for each suite run, which are then read in via a final task and a single html report is spit out with ... everything... in it.
#17 19174 tjuricek JaCoCo code coverage setup and test cleanup revisions.

During test cleanup we remove the directory the code coverage data is written to, so we need refined control on where the output file goes (which is copied to a build directory, currently).
#16 19008 tjuricek Remove reference to built jarfile used during runtime.
#15 19007 tjuricek Remove javadoc and yard "jar" distribution formats.

The documentation for all client SDKs are a part of the user guide.
#14 19002 tjuricek Improve API to interact with multiple p4ds.

The configuration now requires an explicit setting of what P4Ds HWS can talk to via the 'P4D config dir', where there's a file indicating connection settings per p4d, and importantly, an ID. This is the "server ID" referenced everywhere.

Most methods now require a server ID to indicate which p4d to manipulate. In the future, it's likely we will interact with *multiple* p4d instances on some services.

This completely removes the ability to run HWS as a kind of an "open proxy" to whatever p4d you want.

Given the nature of the change and the lack of priority, we've removed Helix Cloud testing and disabled several methods from their "Helix Cloud" implementation. These will be relatively easy to bring back, we'll just need a new method from Raymond that lists the "allowed server IDs" that map to the HWS configured server IDs for a particular user.

Another notable aspect of this change is the use of JSON Web Token to create our authentication key. We associate this key with an in-memory "session" that contains the P4D tickets we use to authenticate users. The JWT token, by default, is assigned a timeout, which allows HWS to block further access to underlying servers without having to interact with multiple auth backends. If any backend fails with that session, the user will get a 403. If you disable the timeout, you'll need to ensure your clients clear out sessions.
#13 18810 tjuricek First-pass at JavaScript client SDK.

JavaScript requires Node with Gulp to "browserfy" the library. It's the easiest way I found to use the swagger-js project; bundle up a wrapping method.

There is no JavaScript reference guide. The swagger-js doesn't really document what they do very well, actually.

Overall I'm not particularly impressed by swagger-js, it was hard to even figure out what the right method syntax was. We may want to invest time in doing it better.

This required setting CORS response headers, which are currently defaulted to a fairly insecure setting.
#12 18710 tjuricek Convert change-related command models to our client API models, also, complete the "alpha" tagging of methods.

This consolidates models related to creating changelists to come from the Java client SDK version.

We are now tagging various methods as "alpha" to signify they may break in upcoming versions. This allows new features to have a period where they can be available, but not necessarily need to be supported in upcoming releases.
#11 18679 tjuricek Revising HWS paths to work primarily at product version 2016.1.

The swagger definitions will primarily work at a major platform release number. We will generate new clients for each major release, and ensure backwards compatibility as time goes on by keeping the older clients around in the tree.

Note: These are JUST URLs, and do not include other revisions we plan on making shortly.
#10 18605 tjuricek Document a simplified method for obtaining the Java client SDK handle.

The client SDK is included as a part of the distribution. Javadoc is included in a subdirectory and hosted directly.

A stupid simple HTML page was added by default to give people something to access right after installation.
#9 18572 tjuricek Add dependency to "docJar" task now that we include it in the running web app.
#8 18569 tjuricek Include the publicsite at the '/doc' path in HWS.

Note: The doc pages may require running from hws.jar, your debug mode may not have the new documentation jar in the classpath by default.
#7 18515 tjuricek Replacing java_client with Swagger-based clients/java project.

- Switched implementations of the Swagger client to use okhttp with gson.
- Added the version to the "status" method, and hey, added that method to the spec
- Added templates to the java code generator to add some default methods, fixing some import issues in Gradle

NOTE: We may want to break down the API a bit and restructure it.
#6 18035 tjuricek Preliminary distribution formats with first-pass post-install configuration script for Linux only.

This is *manually verified* at the moment. The testing framework is TBD.

This contains *preliminary* hooks for .deb and .rpm packages. Those are *completely untested* and not configured.
#5 18025 tjuricek Converted logging framework to use log4j 2.

This will default the current level to "everything" if no configuration file is specified (which is typically what we want since that's almost always used for debugging).
#4 17351 tjuricek Allow system properties to adjust config, and use log4j as the logging system by default (from Simple).

We may switch to log4j 2, I am still ironing out deployment.
#3 17220 tjuricek Basic web hooks for custom project implementations.

Also, a simple web service app to do some basic manual testing.
#2 17177 tjuricek Implement Git Fusion repository methods: /git-fusion/v1/repo

Note: I've changed the JSON format (which is currently unused) because the older system did not allow for global overrides in the per-repository config section.
#1 17140 tjuricek Integrating porting work from development branch.

This work is now ready for testing/CD integration.