Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/new cli library #154

Merged
merged 33 commits into from
Jun 26, 2019
Merged

Feature/new cli library #154

merged 33 commits into from
Jun 26, 2019

Conversation

pesse
Copy link
Member

@pesse pesse commented Jun 11, 2019

Introduces Picocli as new command-line library

Structures the options and organizes them into immutable configuration objects which can better be computed and shared.

Fixes #143

pesse added 25 commits June 5, 2019 00:13
Introduced new Config-Objects to abstract away cli-arguments to config
transformation.
Will also be needed for YAML/JSON configuration in the future
Also fixed a bug - the Object types are the actual key which should be
translated into Key-Values later
No need for RunActionTest anymore
@pesse pesse marked this pull request as ready for review June 13, 2019 21:51
@pesse pesse requested a review from Pazus June 13, 2019 21:51
@pesse pesse changed the title [WIP] Feature/new cli library Feature/new cli library Jun 13, 2019
Copy link
Member

@Pazus Pazus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we have some small behaviour changes, should we document them in the readme?

src/main/java/org/utplsql/cli/ICommand.java Outdated Show resolved Hide resolved
src/main/java/org/utplsql/cli/ConnectionInfo.java Outdated Show resolved Hide resolved
src/main/java/org/utplsql/cli/RunAction.java Outdated Show resolved Hide resolved

class ReporterManager {

private List<ReporterOptions> reporterOptionsList;
private List<Throwable> reporterGatherErrors;
private ExecutorService executorService;

ReporterManager(List<String> reporterParams ) {
initReporterOptionsList(reporterParams);
ReporterManager(ReporterConfig[] reporterConfigs ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me share with you my point. I prefere to use simple constructors and use factory methods for all necessary operation neede to call the constructor. I don't like calling functions from a constructor as it doesn't allow making fields final and I personnaly like final fields. Do you mind making a small refactoring of this place?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean like

public static ReporterManager create( ReporterConfig[] reporterConfigs ) { ...

?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes with all necessary stuff populating arrays done there and then call a simple private constructor.

src/main/java/org/utplsql/cli/ReporterManager.java Outdated Show resolved Hide resolved
@@ -108,38 +112,58 @@ void startReporterGatherers(ExecutorService executorService, final DataSource da

this.executorService = executorService;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move it to the constructor? don't we know the executor service at construction time? That way we could make it also final.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ExecutorService is added later, but maybe this can be refactored, too.
I'd like to postpone this to the restructuring of ReporterManager

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok!

src/main/java/org/utplsql/cli/ReporterManager.java Outdated Show resolved Hide resolved
}

option.getReporterObj().getOutputBuffer().printAvailable(conn, printStreams);
} catch (SQLException | FileNotFoundException e) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we fall on any exception but only on these two?

@@ -14,15 +14,15 @@

private Reporter reporterObj = null;

public ReporterOptions(String reporterName, String outputFileName, boolean outputToScreen) {
public ReporterOptions(String reporterName, String outputFileName ) {
setReporterName(reporterName);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two fields should be final and set directly, not through the setters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And check what fields can also be final, seems like first three.

int returnCode = 0;
try {

final List<Reporter> reporterList;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please move it to initialization.

@Pazus
Copy link
Member

Pazus commented Jun 18, 2019

dbout for example

@pesse
Copy link
Member Author

pesse commented Jun 18, 2019

I don't like the current state of ReporterManager and ReporterOptions at all. Much fuzz, many unnecessary things, not immutable etc.
@Pazus would you be okay with me refactoring these two in a separate PR? I want to move more towards the new ReporterConfig class (which you should like far better) but did not have time to do it properly yet.

@Pazus
Copy link
Member

Pazus commented Jun 18, 2019

I don't like the current state of ReporterManager and ReporterOptions at all. Much fuzz, many unnecessary things, not immutable etc.
@Pazus would you be okay with me refactoring these two in a separate PR? I want to move more towards the new ReporterConfig class (which you should like far better) but did not have time to do it properly yet.

ok!

private ReporterOptions getDefaultReporterOption() {
return new ReporterOptions(CoreReporters.UT_DOCUMENTATION_REPORTER.name());
}

private void abortGathering(Throwable e) {
addGatherError(e);
executorService.shutdownNow();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized this might be an issue. We get the executorService from the outside but we shut it down here. I'm concerned if the caller is ok with its executorService been shut down.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's actually the purpose: If one Reporter Consumption fails, it should abort all the other Reporter threads.
But that's one of the things I want to do differently/more clear

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets abort tasks then, not the excutor

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, will make that more clear in a restructured version

@pesse
Copy link
Member Author

pesse commented Jun 26, 2019

Requested changes will come in a later iteration

@pesse pesse merged commit 7725326 into develop Jun 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"-type_mapping" not recognized in 3.1.6
2 participants