00README

Mon Dec  9 14:20:11 CST 2019
----------------------------

The java-api is now built into the java-cli as it's own copy of the
API.  Any changes made to the API need to be duplicated here because
of that.   The "build first and put into the cache" no longer applies.

Also, this 'swamp' java-api is in a different java namespace
than the old 'continuousassurance' java-api.   I believe this
change was made because we did not have access to the keys
to upload our artifacts to maven central under our own aegis.

To make a new version

	edit pom.xml -> increment version number

	mvn clean
	mvn package -DskipTests

The binaries are generates in the target directory, and have
the current version embedded in their names.   

	java_cli_ver=1.5.8
	java_cli_vname=java-cli-${java_cli_ver}

The file w/out dependencies is:
	target/${java_cli_vname}.jar

The file w/ dependencies addes is:
	java-cli-1.5.8-jar-with-dependencies.jar
	target/${java_cli_vname}-jar-with-dependencies.jar


To make a github release including these binary components, you
can upload the binaries manually, using the "binary box"
in the github GUI to craft release notes

To make a release you need to update ...

	RELEASE_NOTES.txt

Warning: there are embedded out-of-date version numbers in
the file which should not be updated.


Tue Nov  7 13:53:57 CST 2017
-----------------------------

To build the swamp-cli, you will first need to download and compile
the swamp-api.  The "API" must be "installed" into your local maven
repository to be linked against.

	What the issue here is, is that the java-api in
	maven central is an older version, which we can't
	update at this time.  The SWAMP is the process of
	obtaining the keys to be be able to distribute a
	newer version to maven central.

	For the same reason, if you push a new CLI back to the github
	repo, the travis-ci build will fail; just ignore that failure
	until the maven repository issue is resolved.

Until that happens, please follow this procedure to get an
up-to-date version of the java-api, which can be used
to compile the java-cli:

	https://github.com/mirswamp/java-api.git

	git clone https://github.com/mirswamp/java-api.git

	cd java-api
	mvn install


Once that is done, you can now download and compile the java-cli

	https://github.com/mirswamp/java-cli.git

	git clone https://github.com/mirswamp/java-cli.git

	cd java-cli
	mvn -DskipTests -Dmaven.test.skip=true package

If you are using the cli, you can find the bundled version; which
can be run as a standalone jar in:
	
	 target/swamp-cli-jar-with-dependencies.jar

A version-stamped file of the same can also be found in the .m2
repository:

	Where 1.3.1 is the version of the cli you are working with

	ver=1.3.1
	ls -l ~/.m2/repository/org/continuousassurance/swamp/java-cli/${ver}/java-cli-${ver}-jar-with-dependencies.jar


To run the self-tests, you will need to create a config file that
selects what SWAMP, USER, and PROJECT to use.

	scripts/resources/userinfo.properties
		
		See README.adoc for details on the file formats.

Start out by filling out the username field and SWAMP fields, and then login
to the SWAMP to

	1) Generate A SWAMP application-specific password for testing.
		This must be done from the SWAMP GUI.
		Add that password to the config file.

	2) Generate a unique project for CLI testing -- highly recommended!
		At this time, the CLI can not create projects;
		you will need to login to the SWAMP to do that.

		However, you will have to use the CLI to extract
		the UUID of the project after it is created.


To lookup the project in the CLI, add the login info to the config file,
then have the CLI login to the SWAMP with it.

	ver=1.3.3
	jar=target/java-cli-${ver}-jar-with-dependencies.jar 
	java -jar $jar login -F scripts/resources/userinfo.properties 
	java -jar $jar project -N 'Your Project Name'

THe last will return a UUID to put in the 'project=' line in the config file.


Once that is all done, you can run the tests with automatic fetching
of dependencies:

	./run-cli-tests

You will see the output on stdout, and also a log of the
same in the log file 'cli-test-log'


Bolo