disambiguate the test resources into packages

[jnorthrup]

continues #2432 to disambiguate the test resources into packages toward "improved" practices which allow better merged assemblies, shading, and uberjar for deployments and commandline runners.

[jnorthrup]

i think 30/70 include line-ending changes, there were more java files using CRLF and more JSON using LF before. no module was safe. on github" ?w=1" hides ws but they have never made any UI hints for it

[timmolter]

I just tried using google code formatter templates in IntelliJ and Eclipse and they both fail when trying to import them with invalid format errors. I also tried the google-formatter plugin in IntelliJ, and while it works, there were formatting differences between that and what the fmt-maven-plugin plugin produces. So in practice, this is unfortunately a failed concept. Too bad, really.

[timmolter]

OK, the formatter files actually work. I was downloading them incorrectly: google/styleguide#338 (comment)

However, all 3 formatting methods produce different results.

[jnorthrup]

the hope is that if the formatter runs prior to checkin, say in "package", then the deltas will be smaller and clearer to changes despite devs who are compulsive or reckless (guilty here) with reformat/reordering.

the nascent benefits are

• code generation and scripts are more predictable with sed, grep, etc.
• vim users are hard headed and dgaf about your standards...
• choice of IDE goes way down on the list of entry barriers
• line-endings stop hiding meaningful changes and rewriting whole files

sorry for the configs failure, i don't think i have invested time in editor configs for an age given the number of linux installs and laptops i go through in a given year -- that said, when that JDE formatter plugin works, i do take a few minutes to give it the config xml file

[jnorthrup]

https://github.com/HPI-Information-Systems/Metanome/wiki/Installing-the-google-styleguide-settings-in-intellij-and-eclipse this one?

[timmolter]

After some experimentation, this maven plugin is compatible with IntelliJ and Eclipse if you setup both IDEs with the correct plugins as opposed to the formatter files.

Here's my preferred plan in merging your changes.

1. Close this PR
2. Open a new issue regarding the new formatter proposal, seek consensus
3. format the code myself and push the changes
4. @jnorthrup shows me the method to fix the line endings and I push those changes myself after playing around with it
5. @jnorthrup creates a PR with the package name refactor in the test package (Do you have a script for that?)
6. @jnorthrup creates a PR with the integration test package

[jnorthrup]

I'll follow your lead and fill in the blanks.

[jnorthrup]

2 releases later, I'm still asking to disambiguate the test sources

[timmolter]

What's the reformat.skip in pom.ml for again?

[timmolter]

Regarding moving of the integration tests, can you list out the reasons this is necessary/advantageous? I don't think being ignored by an IDE is an advantage actually, and would cause more effort to run them from an IDE. Right now, I'm not convinced moving the integration tests brings any advantage.

[jnorthrup]

when i do "run all tests" in intellij, the integration tests fail.

in my private branch, i merge all 650+ tests and run continuous compile+test as I make changes -- i have a script to seperate out these integration tests which will spoil the party.

i wasn't aware of a seperate maven phase for integration-test but it seems there is one, so if the test sources are in a different directory you just call the failsafe "add" operation when integration tests run. that is someone else's handywork, but it does make "run all tests" from the gui work nicely without integration tests which tend to fail

[jnorthrup]

there is still a posted bounty on refactoring the metadata. this will involve some drastically propogated changes into the source tree. as is typical, refactoring isn't incremental, but tends to make things collapse, and disappear, and remove assumptions and dogmatic practices.

my personal opinion is that the XChange style guide promotes a unified build practice for all modules and therefore these are just packages and not differentiated tools -- this is more or less proven in my private branch, they behave like packages not modules, until you start to bring in code generation and other things. as it stands now the sum of changes to all poms is maybe 3 or 4 total java deps above and beyond what xchange-core and rescu provide.

for swagger API code generation and kotlin stuff, the maven provides adequate tool differentiation per module and the plugins are appropriate to break out into seperate modules.

the challenges or "special treatment" when bringing legit legal jaxrs bindings into the XChange/Rescu convention is currently made harder than it needs to be by the use of final classes and a lack of interface based software contracts all the way up the line. if a binding throws Exception, rescu refuses to generate the proxy. "features" like this are hard to work around and change the requirements of a supported API binding from a simple job of writing adapters and wrapper classes to a more brittle solution including generated code that is hand maintained.

I'd propose the use of okhttp and gson code that swagger uses if only because it looks equally reliable and well maintained on all fronts -- the swagger generator is ancient, okhttp is from square, and ancient, and gson is from google, and ancient. for these tools stackoverflow has comprehensive solutions, swagger.io has closed down its wiki and referred all support reqs to SO and github at this point.

i have personally had no regrets choosing gson over jackson whenever there is a fork in the road because of ease of prototyping, gson tends to accept the json object model as mostly maps, where jackson tends to enforce the java object model and may reject missing or added elements and halt working software if upstream changes. swagger generates pure jaxrs with jackson json or generates full implementations with okhttp, or rx-java. so far there is no eaasy path from generated bindings into XChange due to all the final classes and safeguards against whatever the safeguards are there for.

[jnorthrup]

What's the reformat.skip in pom.ml for again?
this turns off the formatter when true. i copied the documented goals which include verbose and i didnt like the way it obscured the build output, but it looks good as is right now. there is another cnofig to allow the formatter to change the lines. the .gittatributes will catch anything it misses either way

[timmolter]

I don't support the integration tests package refactor as it deviates from the "normal" way. People just run mvn clean verify -DskipIntegrationTests=false which is stated in the README. Making a tests-integration folder is unexpected to the normal user, and I prefer to keep thing unsurprising.

I don't support a refactor using Swagger, gson, okhttp, etc. either because it's too major of a change and we like things how they are. Everything works fine as is.

Please don't submit a PR, which won't get accepted and then feel disappointed that you wasted so much time. I'm telling you now, I won't accept it. I say this just as a courtesy because I don't like to see you waste your time and get upset. I would suggest bringing up major change proposals in a separate "issue" that people can comment on and discuss first.

[jnorthrup]

constant, neverending "not on my watch" responses.

https://github.com/timmolter/XChange/wiki/Bulk-POJO-Generation shows something very similar to swagger, but swagger also generates the jaxrs, or the well maintained rest services proxy code outright, in almost a dozen flavors.

i have a swagger spec which embeds json-schema, and then the generator assigns pojos to request and response specifications. in my case, i had about 5 working generated swagger modules in 2 weeks.

I don't support a refactor using Swagger, gson, okhttp, etc. either because it's too major of a change and we like things how they are. Everything works fine as is.

however, as I try to find a middle ground from we like things how they are and " i had about 5 working generated swagger modules in 2 weeks.", I have gone two routes to solve for forward progress:

a) (the defensive option) built a project fork that allows me freedom from we like things how they are
shared as the polglot brnach in my fork, and

b) (contributing back to the community, altruism) opening pr's and issues to have discussions about technical debt, and methods of achieving additions to XChange in ways that we can sign off and move on to more interesting labors.

@mmazi has done a good job of cultivating the exchange modules at a certain point in time to a refactored module

so maybe im tooting the horn of API's you are not familiar with and don't have energy to vet, but if the tests pass, and more importantly, the community can use the modules and fix them as they need to, why would you impose your personal viewpoint on what should and should not be allowed in the tree? you seem to argue for footprint, and minimize gap from what exists, but these methods are baroque, manually cvultivating each dto? even if there's an IDL defining them all in one place?

perhaps you can perform reviews and request documentation expansion instead of boolean edicts.

I'm porting legal JAXRS to the rescu JAXRS provider and the jaxrs provider factory breaks on "throws Exception". why should 60+ modules all depend on a single, aging, one-off module that has outlived anyone who cares about the rationales present? that probably worked well for a handful of modules and developers, years ago, but well, I'm wasting my time to argue for the metrics of productivity here. This is your commercialized product, and the github presence seems incidental to garner free additions, but in no way to foster a community.

cheers.