- Release-team - mailman3.cels.anl.gov

Re: [Release-team] [Kbase-devel] [FEB] what is required for all command line scripts before feb demo
by Shiran Pasternak 28 Jan '13

28 Jan '13

On Jan 28, 2013, at 3:05 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: > I added brief text and a link to https://trac.kbase.us/projects/kbase/wiki/UserManuals explaining that if you follow the standard for your help message, then your help text will be harvested as part of the release process and made into a man page for your script. Right now, that's at the bottom of the User Manuals page--should it be made more prominent? Are we going to discourage people from hand-writing user manuals and encourage them to write good help messages instead? I still think that a user manual should be developed manually. Command help messages are just that. They don't necessarily give a good overview or an indication of where to start. User manuals can be a lot more interactive, primarily through hypertext, and can also be used to give uninitiated users or those uncomfortable with running Unix commands in the first place a better place to start. > Yes, we need that. Maybe you could put up an initial straw-man page for that, Shiran? I'll draft that up tomorrow as time allows. Bob, it would be great if you can review it to make sure I don't misspeak. > Agreed. Thanks for being proactive about this. Are there other discussions that we should put on the wiki? Good question. The discussion on standardizing RPC exceptions comes to mind. Maybe we should have a wiki page for that. I'll do that to when I get the chance. Shiran > > Nomi > >> >> Shiran >> >> [1] (cf. emails from last week I can't link to because this is not a wiki) >> >> On Jan 25, 2013, at 12:56 PM, Thomas Brettin <brettin(a)mcs.anl.gov> wrote: >> >>> Hi everyone. >>> >>> In the note from Adam on Wednesday, this statement is made: >>> >>>> Command line scripts. All command line scripts need to be accessible from IRIS. If you are not creating command line scripts for your module, we need to know this and why. Tom will talk on the devel con call today what is required for integration into IRIS. >>> >>> In order for us to accomplish this, module owners will need to ensure the following: >>> >>> Script Documentation >>> 1) that all commands return zero when invoked with the -h and the --help options. >>> 2) that all commands print to standard out a help message when invoked with the -h and --help options. >>> 3) that the output contains the following information (see template below) >>> a description of what the script does >>> a description of the parameters >>> a description of the inputs and outputs >>> >>> We'll harvest this text as part of the release process (see below) >>> >>> Naming Convention >>> We will be cleaning up the namespace soon as a single, comprehensive effort in the near future. To help, you can start now by following this simple guidance: >>> >>> 1) commands are named lowercase with a consistent use of underscores (or dashes). >>> 2) the kb prefix will be dropped in future releases >>> 3) prefix with a module identifier >>> >>> examples are : >>> >>> Auxiliary Store: >>> as_create_index as_list_nodes as_resources >>> as_create_node as_list_users as_view_node >>> as_create_user as_modify_node as_view_user >>> >>> Workspace Service (drop the kb): >>> kbws-createws kbws-load kbws-types.pl >>> kbws-delete kbws-login kbws-url >>> kbws-deletews kbws-logout kbws-whoami >>> kbws-exists kbws-meta kbws-workspace >>> >>> Testing >>> The use of the test-scripts target will become a mandatory requirement for scripts that will be executed within IRIS. Because we will have hundreds of commands, we need an automated way to at a minimum verify that the script will run (this verifies the deployment was done correctly and all runtime dependancies are in place). As a minimal start, you should write a shell script that. >>> >>> 1) invokes the script using pre-staged test data >>> 2) verifies correct output. >>> 3) verifies the correct exit code >>> 4) one directory per test >>> 5) this directory contains the input data and output to be compared against by way of a diff or something of your choice. >>> 6) these test directories are located under the top level script-tests directory as per the standard laid out in the module.Makefile template. >>> >>> Complex Commands >>> Commands with complex interfaces, such as jnomics and the assembly service needs to be wrapped into simpler scripts for the user that set preset parameter values and turn the command/subcommand style interface into just a command interface. >>> >>> Commands running on the IRIS host >>> Those commands that themselves are not clients in a client-server architecture, that is commands that will execute on the IRIS host (matR comes to mind), need to have communicated to the release engineering team cpu, memory and storage requirements. >>> >>> Release Process >>> What I will do is modify the release process so that all commands are checked for the -h and --help options. The process will go something like first check to see if the -h and --help options exist and the command returns 0, for those that pass this check we'll have someone take a look at the output to see if it addresses the items in #3. The output will be saved as plain text, moved to the webroot directory under the deployment target, and from there be brought into the kbase.us/developer_zone site as html docs. >>> >>> >>> >>> Here is the template: >>> >>> NAME >>> commandname -- one line summary of what it does >>> >>> SYNOPSIS >>> commandname [list of options] >>> >>> DESCRIPTION >>> Few sentences to paragraphs describing what the command does >>> >>> A detailed description of the inputs >>> >>> A detailed description of the outputs >>> >>> name of parameter 1 - description of parameter (one parameter per line) >>> >>> name of parameter 2 - description of parameter 2 (etc.) >>> >>> EXAMPLES >>> An example or two of how to call the command and what it would do >>> >>> SEE ALSO >>> List any related commands >>> >>> AUTHORS >>> Make yourself (and your coauthors) famous >>> >>> >>> >>> NAME >>> kbws-meta -- displays the metadata for the currently selected workspace >>> >>> SYNOPSIS >>> kbws-meta [-we] >>> >>> DESCRIPTION >>> Workspaces are used in KBase to provide an online location for all data, models, and analysis results. kbws-meta displays the metadata (for example, the date last modified and the permission settings) of the currently selected workspace (or the workspace specified on the command line with the "-w/--workspace" option). >>> >>> Inputs: none >>> >>> Outputs: metadata fields and values printed to stdout, one per line >>> >>> Options: >>> -w,--workspace ID of workspace you want to look at >>> -e,--showerror Set to 1 to show any errors in execution >>> >>> EXAMPLES >>> $ kbws-meta >>> Workspace ID: test >>> Owner: chenry >>> Moddate: 2012-12-26T06:11:50 >>> Objects: 4 >>> User permission: r >>> Global permission:r >>> >>> SEE ALSO >>> kbws-list >>> kbws-workspace >>> kbws-listobj >>> >>> AUTHORS >>> Chris Henry >>> >>> Thomas Brettin >>> 865-603-7760 (cell) >>> brettin(a)mcs.anl.gov >

1 0

Deployed into Production
by Shane Canon 28 Jan '13

28 Jan '13

Cary and I have deployed the following modules into production. All of these used the tag 01222013-test. communities_qc erdb_service kb_seed workspace idserver cluster_service I think several of these didn't need redeploying (i.e. kb_seed and idserver) since they were only tested because they were dependencies. I tried running make test on a few and ran into some issues. I will contact the maintainers and ask them to test the production deployment. --Shane

1 0

Re: [Release-team] [Kbase-devel] [FEB] what is required for all command line scripts before feb demo
by Nomi Harris 28 Jan '13

28 Jan '13

I also added a link to the CLI Standards page on https://trac.kbase.us/projects/kbase/wiki/DocStandards Nomi On Jan 28, 2013, at 12:05 PM, Nomi Harris <nlharris(a)lbl.gov> wrote: > On Jan 28, 2013, at 7:13 AM, Shiran Pasternak <shiranpasternak(a)gmail.com> wrote: > >> Hi guys, >> >> I've incorporated Tom's email into the Trac Wiki page on command-line standards, started a few months ago by Paramvir. This should ensure that such important documentation on SOP and decisions don't get lost in our brimming inboxes. > > Thanks, Shiran. > I added brief text and a link to https://trac.kbase.us/projects/kbase/wiki/UserManuals explaining that if you follow the standard for your help message, then your help text will be harvested as part of the release process and made into a man page for your script. Right now, that's at the bottom of the User Manuals page--should it be made more prominent? Are we going to discourage people from hand-writing user manuals and encourage them to write good help messages instead? > >> Still missing from the Trac Wiki: SOP on exposing commands in IRIS.[1] > > Yes, we need that. Maybe you could put up an initial straw-man page for that, Shiran? > >> Documentation on the Trac Wiki has been improving dramatically in the past few months, but it's still very sparse relative to all the discussions happening on this list. > > Agreed. Thanks for being proactive about this. Are there other discussions that we should put on the wiki? > > Nomi > >> >> Shiran >> >> [1] (cf. emails from last week I can't link to because this is not a wiki) >> >> On Jan 25, 2013, at 12:56 PM, Thomas Brettin <brettin(a)mcs.anl.gov> wrote: >> >>> Hi everyone. >>> >>> In the note from Adam on Wednesday, this statement is made: >>> >>>> Command line scripts. All command line scripts need to be accessible from IRIS. If you are not creating command line scripts for your module, we need to know this and why. Tom will talk on the devel con call today what is required for integration into IRIS. >>> >>> In order for us to accomplish this, module owners will need to ensure the following: >>> >>> Script Documentation >>> 1) that all commands return zero when invoked with the -h and the --help options. >>> 2) that all commands print to standard out a help message when invoked with the -h and --help options. >>> 3) that the output contains the following information (see template below) >>> a description of what the script does >>> a description of the parameters >>> a description of the inputs and outputs >>> >>> We'll harvest this text as part of the release process (see below) >>> >>> Naming Convention >>> We will be cleaning up the namespace soon as a single, comprehensive effort in the near future. To help, you can start now by following this simple guidance: >>> >>> 1) commands are named lowercase with a consistent use of underscores (or dashes). >>> 2) the kb prefix will be dropped in future releases >>> 3) prefix with a module identifier >>> >>> examples are : >>> >>> Auxiliary Store: >>> as_create_index as_list_nodes as_resources >>> as_create_node as_list_users as_view_node >>> as_create_user as_modify_node as_view_user >>> >>> Workspace Service (drop the kb): >>> kbws-createws kbws-load kbws-types.pl >>> kbws-delete kbws-login kbws-url >>> kbws-deletews kbws-logout kbws-whoami >>> kbws-exists kbws-meta kbws-workspace >>> >>> Testing >>> The use of the test-scripts target will become a mandatory requirement for scripts that will be executed within IRIS. Because we will have hundreds of commands, we need an automated way to at a minimum verify that the script will run (this verifies the deployment was done correctly and all runtime dependancies are in place). As a minimal start, you should write a shell script that. >>> >>> 1) invokes the script using pre-staged test data >>> 2) verifies correct output. >>> 3) verifies the correct exit code >>> 4) one directory per test >>> 5) this directory contains the input data and output to be compared against by way of a diff or something of your choice. >>> 6) these test directories are located under the top level script-tests directory as per the standard laid out in the module.Makefile template. >>> >>> Complex Commands >>> Commands with complex interfaces, such as jnomics and the assembly service needs to be wrapped into simpler scripts for the user that set preset parameter values and turn the command/subcommand style interface into just a command interface. >>> >>> Commands running on the IRIS host >>> Those commands that themselves are not clients in a client-server architecture, that is commands that will execute on the IRIS host (matR comes to mind), need to have communicated to the release engineering team cpu, memory and storage requirements. >>> >>> Release Process >>> What I will do is modify the release process so that all commands are checked for the -h and --help options. The process will go something like first check to see if the -h and --help options exist and the command returns 0, for those that pass this check we'll have someone take a look at the output to see if it addresses the items in #3. The output will be saved as plain text, moved to the webroot directory under the deployment target, and from there be brought into the kbase.us/developer_zone site as html docs. >>> >>> >>> >>> Here is the template: >>> >>> NAME >>> commandname -- one line summary of what it does >>> >>> SYNOPSIS >>> commandname [list of options] >>> >>> DESCRIPTION >>> Few sentences to paragraphs describing what the command does >>> >>> A detailed description of the inputs >>> >>> A detailed description of the outputs >>> >>> name of parameter 1 - description of parameter (one parameter per line) >>> >>> name of parameter 2 - description of parameter 2 (etc.) >>> >>> EXAMPLES >>> An example or two of how to call the command and what it would do >>> >>> SEE ALSO >>> List any related commands >>> >>> AUTHORS >>> Make yourself (and your coauthors) famous >>> >>> >>> >>> NAME >>> kbws-meta -- displays the metadata for the currently selected workspace >>> >>> SYNOPSIS >>> kbws-meta [-we] >>> >>> DESCRIPTION >>> Workspaces are used in KBase to provide an online location for all data, models, and analysis results. kbws-meta displays the metadata (for example, the date last modified and the permission settings) of the currently selected workspace (or the workspace specified on the command line with the "-w/--workspace" option). >>> >>> Inputs: none >>> >>> Outputs: metadata fields and values printed to stdout, one per line >>> >>> Options: >>> -w,--workspace ID of workspace you want to look at >>> -e,--showerror Set to 1 to show any errors in execution >>> >>> EXAMPLES >>> $ kbws-meta >>> Workspace ID: test >>> Owner: chenry >>> Moddate: 2012-12-26T06:11:50 >>> Objects: 4 >>> User permission: r >>> Global permission:r >>> >>> SEE ALSO >>> kbws-list >>> kbws-workspace >>> kbws-listobj >>> >>> AUTHORS >>> Chris Henry >>> >>> Thomas Brettin >>> 865-603-7760 (cell) >>> brettin(a)mcs.anl.gov >

1 0

Re: [Release-team] [Kbase-devel] [FEB] what is required for all command line scripts before feb demo
by Nomi Harris 28 Jan '13

28 Jan '13

On Jan 28, 2013, at 7:13 AM, Shiran Pasternak <shiranpasternak(a)gmail.com> wrote: > Hi guys, > > I've incorporated Tom's email into the Trac Wiki page on command-line standards, started a few months ago by Paramvir. This should ensure that such important documentation on SOP and decisions don't get lost in our brimming inboxes. Thanks, Shiran. I added brief text and a link to https://trac.kbase.us/projects/kbase/wiki/UserManuals explaining that if you follow the standard for your help message, then your help text will be harvested as part of the release process and made into a man page for your script. Right now, that's at the bottom of the User Manuals page--should it be made more prominent? Are we going to discourage people from hand-writing user manuals and encourage them to write good help messages instead? > Still missing from the Trac Wiki: SOP on exposing commands in IRIS.[1] Yes, we need that. Maybe you could put up an initial straw-man page for that, Shiran? > Documentation on the Trac Wiki has been improving dramatically in the past few months, but it's still very sparse relative to all the discussions happening on this list. Agreed. Thanks for being proactive about this. Are there other discussions that we should put on the wiki? Nomi > > Shiran > > [1] (cf. emails from last week I can't link to because this is not a wiki) > > On Jan 25, 2013, at 12:56 PM, Thomas Brettin <brettin(a)mcs.anl.gov> wrote: > >> Hi everyone. >> >> In the note from Adam on Wednesday, this statement is made: >> >>> Command line scripts. All command line scripts need to be accessible from IRIS. If you are not creating command line scripts for your module, we need to know this and why. Tom will talk on the devel con call today what is required for integration into IRIS. >> >> In order for us to accomplish this, module owners will need to ensure the following: >> >> Script Documentation >> 1) that all commands return zero when invoked with the -h and the --help options. >> 2) that all commands print to standard out a help message when invoked with the -h and --help options. >> 3) that the output contains the following information (see template below) >> a description of what the script does >> a description of the parameters >> a description of the inputs and outputs >> >> We'll harvest this text as part of the release process (see below) >> >> Naming Convention >> We will be cleaning up the namespace soon as a single, comprehensive effort in the near future. To help, you can start now by following this simple guidance: >> >> 1) commands are named lowercase with a consistent use of underscores (or dashes). >> 2) the kb prefix will be dropped in future releases >> 3) prefix with a module identifier >> >> examples are : >> >> Auxiliary Store: >> as_create_index as_list_nodes as_resources >> as_create_node as_list_users as_view_node >> as_create_user as_modify_node as_view_user >> >> Workspace Service (drop the kb): >> kbws-createws kbws-load kbws-types.pl >> kbws-delete kbws-login kbws-url >> kbws-deletews kbws-logout kbws-whoami >> kbws-exists kbws-meta kbws-workspace >> >> Testing >> The use of the test-scripts target will become a mandatory requirement for scripts that will be executed within IRIS. Because we will have hundreds of commands, we need an automated way to at a minimum verify that the script will run (this verifies the deployment was done correctly and all runtime dependancies are in place). As a minimal start, you should write a shell script that. >> >> 1) invokes the script using pre-staged test data >> 2) verifies correct output. >> 3) verifies the correct exit code >> 4) one directory per test >> 5) this directory contains the input data and output to be compared against by way of a diff or something of your choice. >> 6) these test directories are located under the top level script-tests directory as per the standard laid out in the module.Makefile template. >> >> Complex Commands >> Commands with complex interfaces, such as jnomics and the assembly service needs to be wrapped into simpler scripts for the user that set preset parameter values and turn the command/subcommand style interface into just a command interface. >> >> Commands running on the IRIS host >> Those commands that themselves are not clients in a client-server architecture, that is commands that will execute on the IRIS host (matR comes to mind), need to have communicated to the release engineering team cpu, memory and storage requirements. >> >> Release Process >> What I will do is modify the release process so that all commands are checked for the -h and --help options. The process will go something like first check to see if the -h and --help options exist and the command returns 0, for those that pass this check we'll have someone take a look at the output to see if it addresses the items in #3. The output will be saved as plain text, moved to the webroot directory under the deployment target, and from there be brought into the kbase.us/developer_zone site as html docs. >> >> >> >> Here is the template: >> >> NAME >> commandname -- one line summary of what it does >> >> SYNOPSIS >> commandname [list of options] >> >> DESCRIPTION >> Few sentences to paragraphs describing what the command does >> >> A detailed description of the inputs >> >> A detailed description of the outputs >> >> name of parameter 1 - description of parameter (one parameter per line) >> >> name of parameter 2 - description of parameter 2 (etc.) >> >> EXAMPLES >> An example or two of how to call the command and what it would do >> >> SEE ALSO >> List any related commands >> >> AUTHORS >> Make yourself (and your coauthors) famous >> >> >> >> NAME >> kbws-meta -- displays the metadata for the currently selected workspace >> >> SYNOPSIS >> kbws-meta [-we] >> >> DESCRIPTION >> Workspaces are used in KBase to provide an online location for all data, models, and analysis results. kbws-meta displays the metadata (for example, the date last modified and the permission settings) of the currently selected workspace (or the workspace specified on the command line with the "-w/--workspace" option). >> >> Inputs: none >> >> Outputs: metadata fields and values printed to stdout, one per line >> >> Options: >> -w,--workspace ID of workspace you want to look at >> -e,--showerror Set to 1 to show any errors in execution >> >> EXAMPLES >> $ kbws-meta >> Workspace ID: test >> Owner: chenry >> Moddate: 2012-12-26T06:11:50 >> Objects: 4 >> User permission: r >> Global permission:r >> >> SEE ALSO >> kbws-list >> kbws-workspace >> kbws-listobj >> >> AUTHORS >> Chris Henry >> >> Thomas Brettin >> 865-603-7760 (cell) >> brettin(a)mcs.anl.gov

1 0

Re: [Release-team] Need downloadable KBase product for Windows
by Nomi Harris 28 Jan '13

28 Jan '13

We shouldn't sink a huge amount of time into getting IRIS working on Windows but I think we should at least look into it. Fortunately, Jason uses Windows (he currently has Windows 7) and has agreed to do some testing of IRIS on Windows--thanks, Jason! (Jason said IRIS seems to work in Firefox but not in IE9, and I think DOE people will be allowed to have IE8 but not Firefox.) If we can't get it working under IE, we can at least document that we tried. Miriam, it's probably less important to test on XP, since DOE will be switching to Windows 7 soon, but if Jason manages to get IRIS working on 7, it would be interesting to see if it then also works on XP. Nomi Harris Project Manager, KBase On Jan 28, 2013, at 6:01 AM, "Land, Miriam L." <landml(a)ornl.gov> wrote: >> From: Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> >> Date: Sunday, January 27, 2013 6:47 PM >> To: "release-team(a)lists.kbase.us<mailto:[email protected]>" <release-team(a)lists.kbase.us<mailto:[email protected]>> >> Cc: Adam Arkin <aparkin(a)lbl.gov<mailto:[email protected]>>, Michael Leuze <leuzemr(a)ornl.gov<mailto:[email protected]>>, Nomi Harris <nlharris(a)lbl.gov<mailto:[email protected]>> >> Subject: [Release-team] Need downloadable KBase product for Windows >> >> So it is politically important to get something out in Feb that works on Windows. We told them that IRIS works on any platform, and doesn't require you to download any software, but now we need to check that IRIS actually does run in some ancient version of IE on Windows XP or Windows 7. Do any of you have access to an old PC? (Miriam, I know you switched to Mac fairly recently--you don't happen to have an old PC lying around, do you?) Susan said she can try out IRIS on her Windows machine, but we also need to be able to test it, particularly if she has problems. (I'm a little worried about some of the javascript stuff that we're talking about adding.) Maybe someone can run old Windows VMs to test this stuff? >> >> Nomi Harris >> Project Manager, KBase > > I have an old XP box at home with an old IE. I had install Chrome to test the GLAMM lab. Haven't tried the other labs. My old work Windows box is off the ORNL network but I can take it home and do more testing. > > Miriam

1 0

Re: [Release-team] test deployment failure
by Dan Olson 28 Jan '13

28 Jan '13

Well it got further, but still failed everywhere -- see below, this is the kbapi_common module causing trouble. ant -Djar_file=/kb/dev_container/modules/kbapi_common/dist/lib/kbapi_common.jar -Dkb_top=/kb/dev_container dist Buildfile: /kb/dev_container/modules/kbapi_common/build.xml init: compile: [javac] Compiling 1 source file to /kb/dev_container/modules/kbapi_common/build [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:5: package org.codehaus.jackson.annotate.JsonAutoDetect does not exist [javac] import org.codehaus.jackson.annotate.JsonAutoDetect.Visibility; [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:10: package org.codehaus.jackson does not exist [javac] import org.codehaus.jackson.*; [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:11: package org.codehaus.jackson.type does not exist [javac] import org.codehaus.jackson.type.*; [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:12: package org.codehaus.jackson.map does not exist [javac] import org.codehaus.jackson.map.ObjectMapper; [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:18: cannot find symbol [javac] symbol : class ObjectMapper [javac] location: class us.kbase.rpc.Caller [javac] ObjectMapper mapper; [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:24: cannot find symbol [javac] symbol : class ObjectMapper [javac] location: class us.kbase.rpc.Caller [javac] mapper =new ObjectMapper(); [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:102: cannot find symbol [javac] symbol : class JsonGenerator [javac] location: class us.kbase.rpc.Caller [javac] JsonGenerator g = mapper.getJsonFactory().createJsonGenerator(conn.getOutputStream(), JsonEncoding.UTF8); [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:102: cannot find symbol [javac] symbol : variable JsonEncoding [javac] location: class us.kbase.rpc.Caller [javac] JsonGenerator g = mapper.getJsonFactory().createJsonGenerator(conn.getOutputStream(), JsonEncoding.UTF8); [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:126: cannot find symbol [javac] symbol : class JsonParser [javac] location: class us.kbase.rpc.Caller [javac] JsonParser parser = mapper.getJsonFactory().createJsonParser(istream); [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:127: cannot find symbol [javac] symbol : class JsonToken [javac] location: class us.kbase.rpc.Caller [javac] JsonToken t= parser.nextToken(); [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:128: cannot find symbol [javac] symbol : variable JsonToken [javac] location: class us.kbase.rpc.Caller [javac] if (t != JsonToken.START_OBJECT) { throw new Exception("bad parse t=" + t); } [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:136: cannot find symbol [javac] symbol : variable JsonToken [javac] location: class us.kbase.rpc.Caller [javac] if (t == JsonToken.END_OBJECT || t == null) [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:141: cannot find symbol [javac] symbol : variable JsonToken [javac] location: class us.kbase.rpc.Caller [javac] if (t != JsonToken.FIELD_NAME){ throw new Exception("bad parse t=" + t); } [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:153: cannot find symbol [javac] symbol : variable JsonToken [javac] location: class us.kbase.rpc.Caller [javac] if (t != JsonToken.VALUE_STRING) { throw new Exception("bad parse t=" + t); } [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:160: cannot find symbol [javac] symbol : variable JsonToken [javac] location: class us.kbase.rpc.Caller [javac] if (t != JsonToken.START_OBJECT) { throw new Exception("bad parse t=" + t); } [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:162: cannot find symbol [javac] symbol : class TypeReference [javac] location: class us.kbase.rpc.Caller [javac] ret_error = parser.readValueAs(new TypeReference<Map<String, String>>(){}); [javac] ^ [javac] /kb/dev_container/modules/kbapi_common/src/us/kbase/rpc/Caller.java:168: cannot find symbol [javac] symbol : variable JsonToken [javac] location: class us.kbase.rpc.Caller [javac] if (t != JsonToken.VALUE_STRING) { throw new Exception("bad parse t=" + t); } [javac] ^ [javac] 17 errors BUILD FAILED /kb/dev_container/modules/kbapi_common/build.xml:32: Compile failed; see the compiler error output for details. Total time: 0 seconds make[1]: Leaving directory `/kb/dev_container/modules/kbapi_common' make[1]: *** [jar] Error 1 ----- Original Message ----- > From: "Dan Olson" <dolson(a)mcs.anl.gov> > To: release-team(a)kbase.us > Sent: Monday, January 28, 2013 12:19:27 PM > Subject: Re: [Release-team] test deployment failure > > Figured out what this was.. a little dependency of a dependency > problem. > > I searched manually for dependancies in the dependancies files. > kb_seed was a dependancies so it was marked for inclusion. > However, I didn't resolve its dependancies. It was dependent on > kbapi_common. > > Now that kbapi_common is marked for inclusion things are going > better. > > ----- Original Message ----- > > From: "Dan Olson" <dolson(a)mcs.anl.gov> > > To: release-team(a)kbase.us > > Sent: Monday, January 28, 2013 12:11:59 PM > > Subject: [Release-team] test deployment failure > > > > The test deployment failed completely this morning. /kb/deployment > > doesn't even get created. > > > > I'm not sure what is causing this. > > > > ---- > > Daniel Murphy-Olson > > Systems Administrator > > Mathematics & Computer Science Division > > Argonne National Laboratory > > 630-252-0055 > > > > _______________________________________________ > > Release-team mailing list > > Release-team(a)lists.kbase.us > > https://lists.kbase.us/mailman/listinfo/release-team > > > _______________________________________________ > Release-team mailing list > Release-team(a)lists.kbase.us > https://lists.kbase.us/mailman/listinfo/release-team >

1 0

Re: [Release-team] test deployment failure
by Dan Olson 28 Jan '13

28 Jan '13

Figured out what this was.. a little dependency of a dependency problem. I searched manually for dependancies in the dependancies files. kb_seed was a dependancies so it was marked for inclusion. However, I didn't resolve its dependancies. It was dependent on kbapi_common. Now that kbapi_common is marked for inclusion things are going better. ----- Original Message ----- > From: "Dan Olson" <dolson(a)mcs.anl.gov> > To: release-team(a)kbase.us > Sent: Monday, January 28, 2013 12:11:59 PM > Subject: [Release-team] test deployment failure > > The test deployment failed completely this morning. /kb/deployment > doesn't even get created. > > I'm not sure what is causing this. > > ---- > Daniel Murphy-Olson > Systems Administrator > Mathematics & Computer Science Division > Argonne National Laboratory > 630-252-0055 > > _______________________________________________ > Release-team mailing list > Release-team(a)lists.kbase.us > https://lists.kbase.us/mailman/listinfo/release-team >

1 0

test deployment failure
by Dan Olson 28 Jan '13

28 Jan '13

The test deployment failed completely this morning. /kb/deployment doesn't even get created. I'm not sure what is causing this. ---- Daniel Murphy-Olson Systems Administrator Mathematics & Computer Science Division Argonne National Laboratory 630-252-0055

1 0

phispy module failed deploy
by Dan Olson 28 Jan '13

28 Jan '13

The phispy module failed deployment because there is no registered port for the service at https://trac.kbase.us/projects/kbase/wiki/IntegrationTargets. ---- Daniel Murphy-Olson Systems Administrator Mathematics & Computer Science Division Argonne National Laboratory 630-252-0055

1 0

release has been tagged
by Dan Olson 28 Jan '13

28 Jan '13

The 01282013-test release has been tagged. ---- Daniel Murphy-Olson Systems Administrator Mathematics & Computer Science Division Argonne National Laboratory 630-252-0055

1 0