I still don’t see why the discussion about Apache release policy needs to be connected with discussion about file formats. It’s simpler to resolve the issue about release policy first, make the release, and come back and discuss file format later.
Regarding release policy. When a user contributes a test case to Hop, that is a creative work according to copyright law. Like any contribution, we don’t “claim copyright”; they retain copyright, but contribute under Apache license. And we require that text files have a header. No one is proposing adding headers to pipeline and workflow files that are not contributed to Hop. I find it hard to believe that adding a header to a test case will make it behave differently, in the vast majority of cases. Exceptions can be made for the few case where it matters. Julian > On Jun 12, 2021, at 3:25 PM, Matt Casters <[email protected]> > wrote: > > That's really my point: it's really not as straightforward at all like you > claimed Julian. The files are produced by the Hop GUI and that's what we > want. We want to test what is actually used by our end-users, not some > theoretical use-case which is typically handled by JUnit/Mockito/Powermock > and their ilk. It's this old-school vision that an XML file has to be > written by hand or something like that which messes up this debate. > The .hpl/.hwf file format does not and should not include the ASF header > either. For our users it would be inappropriate as we can't claim > copyright on works produced by others. In other words, when some person or > company uses our software and creates a pipeline, we can't just claim > copyright for that file. At least that's how I see things. > > As for YAML: my dislike for it is enormous but since it wouldn't solve the > header issue I wouldn't pick it for that reason alone since it allows > comments. Perhaps we should serialize in some binary format to get past > this issue. Since we'll need to continue XML serialization anyway it's > just a question of storing the integration tests and samples in a way that > can be approved by the ASF. > > > On Sat, Jun 12, 2021 at 10:54 PM Julian Hyde <[email protected]> wrote: > >> I don’t think the discussion about headers really forces this issue. It’s >> a technical decision and shouldn’t be rushed. >> >> Regarding the headers. It is straightforward to add headers to existing >> files. It is also straightforward to use a tool such as checkstyle to >> enforce them (so, any PR that adds a .hpl file without a header will get a >> build error, which the contributor will duly fix). >> >> In my opinion, Hop should allow multiple formats. XML is rather old, and >> people find it difficult to read without practice. JSON is a bit more >> modern, but has terrible support for multi-line strings and (in its >> official form) doesn’t allow comments and is strict about quoting of >> identifiers. YAML (or similar) is worth considering; its model is >> compatible with JSON, it allows comments, it has much better support for >> multi-line strings, and it tends to diff/merge easier than XML and JSON. >> >> Julian >> >> >>> On Jun 12, 2021, at 1:38 PM, Matt Casters <[email protected]> >> wrote: >>> >>> Folks, >>> >>> It's been up in the air for quite some time now but it looks like we're >>> being forced by certain discussions in the release voting of 0.99-rc1. >> How >>> would you feel about moving to JSON for the standard file format of >>> pipelines and workflows? >>> I propose .hpj and .hwj as extensions. >>> This would push back our releases for a month or so while we convert the >>> remaining serialization code to the new @HopMetadataProperty API >>> >>> Cheers, >>> Matt >> >> > > -- > Neo4j Chief Solutions Architect > *✉ *[email protected] > ☎ +32486972937
