[
https://issues.apache.org/jira/browse/OOZIE-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16514879#comment-16514879
]
Andras Piros commented on OOZIE-2339:
-------------------------------------
[~pbacsko] thanks for the review rounds!
Here is what I've addressed:
bq. Eliminate unnecessary instanceof checks
Found a few that are truly unnecessary, those are eliminated. Most places we
need these.
bq. Use the standard Java interfaces for return & variable types instead of
ImmutableMap, ImmutableSet
Fixed.
bq. Do we need SecureRandom ?
Fixed.
bq. Order of methods: public, protected, private
This is actually one I'd argue with. Due to clean code best is to keep
{{private}} methods just under the {{public}} or {{protected}} one where these
are first called, for better readability.
bq. Workflow object could have a method like getAsXml() for convenience
Good idea, fixed.
bq. Eliminate unnecessary casts if possible. Eg. WORKFLOWAPP stores JAXB nodes
in a List<Object> which doesn't look good at first sight. A lot of casts
necessary in the test methods because of this.
Sorry for that, cannot fix. {{WORKFLOWAPP}} and everything in {{generated}}
packages are JAXB generated code, not much influence how it looks like.
bq. The method getParent() seems to belong to NodeBase as an abstract method
As {{ExplicitNode#getParent()}} returns a {{NodeBase}}, and
{{JoiningNodeBase#getParents()}} return a {{List<NodeBase>>}}, we have
different semantics for different {{NodeBase}} subclasses whether these are
allowed to have only one or multiple parent {{NodeBase}} instances. In that
sense, leaving as it is.
bq. Weird looking comment: /* package private */ void close(final Join join)
Fixed.
bq. getNodesInTopologicalOrder() looks a bit misleading. Not sure what it does
exactly, but this doesn't seem to care about ordering.
Fixed.
> [fluent-job] Minimum Viable Fluent Job API
> ------------------------------------------
>
> Key: OOZIE-2339
> URL: https://issues.apache.org/jira/browse/OOZIE-2339
> Project: Oozie
> Issue Type: New Feature
> Components: client, core, examples, fluent-job, tests
> Affects Versions: 4.3.0
> Reporter: Robert Kanter
> Assignee: Andras Piros
> Priority: Major
> Fix For: 5.1.0
>
> Attachments: OOZIE-2339.001.patch, OOZIE-2339.002.patch,
> OOZIE-2339.003.patch, OOZIE-2339.004.patch, OOZIE-2339.005.patch,
> OOZIE-2339.006.patch, OOZIE-2339.008.patch, OOZIE-2339.010.patch,
> OOZIE-2339.011.patch, OOZIE-2339.012.patch, OOZIE-2339.013.patch,
> OOZIE-2339.014.patch, OOZIE-2339.015.patch, OOZIE-2339.016.patch,
> OOZIE-2339.017.patch, OOZIE-2339.018.patch, OOZIE-2339.019.patch
>
>
> Users often complain about the XML they have to write for Oozie jobs. It
> would be nice if they could write them in something like Java, but we don't
> want to have to maintain a separate Java API for this. I was looking around
> and saw that JAXB might be the right thing here. From what I can tell, it
> lets you create Java classes from XSD schemas. So, we should be able to
> auto-generate a Java API for writing Oozie jobs, without having to really
> maintain it.
> We should investigate if this is feasible and, if so, implement it.
> Some useful looking links:
> * [JAXB
> overview|https://en.wikipedia.org/wiki/Java_Architecture_for_XML_Binding]
> * [JAXB description|https://jaxb.java.net/2.2.11/docs/ch03.html]
> * [Maven JAXB plugin|https://java.net/projects/maven-jaxb2-plugin/pages/Home]
> * [Apache Falcon|https://falcon.apache.org]
> Key features:
> * must have:
> ** inside a {{fluent-job-api}} artifact
> ** able to create workflow / coordinator / bundle definitions programmatically
> ** synchronizing each and every XSD change on rebuild
> ** can write {{workflow.xml}}, {{coordinator.xml}}, {{bundle.xml}}, and
> {{jobs.properties}} artifacts of every XSD version
> ** cloneability of workflow etc. {{Object}} s
> ** perform cross checks, e.g. that the workflow graph is a DAG
> ** only latest XSD versions should be supported as must have
> * nice to have:
> ** XSD version(s) can be provided. When not provided, latest ones are
> considered as valid
> ** implement a [*fluent API*|https://en.wikipedia.org/wiki/Fluent_interface]
> ** have a Python / Jython / Py4J REPL to make it easy to experiment with also
> for data engineers / data scientists
> ** create documentation about usage
> ** can read {{workflow.xml}}, {{coordinator.xml}}, {{bundle.xml}}, and
> {{jobs.properties}} artifacts of every XSD version
> ** can convert between XSD versions
> ** support XSD change on the fly (within REPL)
> ** support HDFS reads / writes
> ** support dry run on an Oozie server to perform checks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
