Conversation
Refactoring needed. Tonight is a tough night for concentration. Turning on programming/concentration music didn't help either. Guess what they played? Command&Conquer Soundtrack. Who could concentrate with so many nice and positive memories triggered?
It should really be only an Info-Object, not a DataSource wannabe
I wanted to have more separation between Main-Class and actual commands. There might still be work left to do, but it's a first throw.
|
|
||
| `utplsql run <ConnectionURL> [-p=(ut_path|ut_paths)] [-f=format [-o=output_file] [-s] ...]` | ||
|
|
||
| Currently, utPLSQL-cli knows the following commands: |
|
|
||
| #### Enabling Color Outputs on Windows | ||
| ### info | ||
| `utplsql info [<ConnectionURL>]` |
There was a problem hiding this comment.
Maybe make a separate section for the connection URL and link to it in each command. That way it is defined only once.
There was a problem hiding this comment.
Yes, came to my mind but wasn't able to come up with a good way and therefore decided to refactor later ;)
| ``` | ||
| > utplsql reporters app/app@localhost:1521/ORCLPDB1 | ||
|
|
||
| UT_COVERAGE_COBERTURA_REPORTER (SQL): Generates a Cobertura coverage report providing information on code coverage with line numbers. |
There was a problem hiding this comment.
What does (SQL) / (SQL_with_Java) mean?
I find it confusing.
Do we need some extra actions for one or another?
There was a problem hiding this comment.
I guess the concept needs more explanation, still struggling of how to do so.
With 3.1.0 ReporterFactory in cli/java-api you can have
- Reporters solely implemented on the database (most core reporters) -> SQL
- Reporters solely implemented on the client. You could for example write a Reporter which uses ut_documentation_reporter internally but modifies the output excessively and is registered via a different name (so not overwriting ut_documentation_reporter but just using it internally). -> JAVA
- Reporters who are implemented on the database but also have some kind of addition on the client. Best example is the ut_coverage_html_reporter: It's basically the database implemented reporter but has this client-side addition that the assets are written to a specific folder. -> SQL_WITH_JAVA
There was a problem hiding this comment.
I don't think users can implement reporters in cli.
We (as dev team) would have to do that.
I would refrain from implementing reporters (based on existing PLSQL reporters) in java.
Can you remove that info?
I'd like to avoid questions/confusinon from users.
If needed, we can add this info to documentation.
The comment seems a good explanation.
| ``` | ||
|
|
||
| ### reporters | ||
| `utplsql info <ConnectionURL>` |
There was a problem hiding this comment.
Is it info or reporters ?
The examples show different command.
There was a problem hiding this comment.
It was definitely too late :) Thanks for finding - it's reporters
Also much nicer formatting
| Designed for Jenkins and TFS to report coverage. | ||
| Cobertura Document Type Definition can be found: http://cobertura.sourceforge.net/xml/coverage-04.dtd. | ||
| Sample file: https://github.com/leobalter/testing-examples/blob/master/solutions/3/report/cobertura-coverage.xml. | ||
| UT_COVERAGE_COBERTURA_REPORTER Generates a Cobertura coverage report providing information on code coverage with line numbers. |
There was a problem hiding this comment.
With my pedantic hat on - wouldn't it be better to have it formatted with indentation of 4 spaces?
UT_COVERAGE_COBERTURA_REPORTER:
Generates a Cobertura coverage report providing information on code coverage with line numbers.
Designed for Jenkins and TFS to report coverage.
Indenting by up to 31 chars seems excessive
Fixes #77
Adds a new command "info" with an optional positional parameter to provide a connection.
Will print out information about the version of the used components:
Not yet done. Still needs heavy refactoring.
Fixes #31