I suppose this project is dead, yes?

[paxbit]

Hi dschulten,

I'm relating to #18 .

I'm also very doubtful it was a good decision to entirely rely on Spring HATEOAS for the backing model which is then mapped to Hydra in a hardcoded way. For Links that mapping is done in a seemingly never ending if-else chain in LinkListSerializer. This class alone I consider highly problematic with regards to judging the readiness of this framework to support the adoption of Hydra in the Java ecosystem. Unfortunately hydra-java is the only listed Java implementation on hydra-cg.com, making it look a bit like THE Hydra reference implementation, which it clearly isn't. At least not as long as the actual Hydra model lives in a bunch of highly nested if/else branches with TODOs galore on them. Yes I understand it's all in testing but that's still no excuse to leave it like this.

That's all well and good if hydra-java is just some random Hydra implementation on GitHub serving mostly the creators own needs.
At the same time I'm not sure how many visitors looking for a Java Hydra backend implementation came here, noticed that...

1. The Hydra vocabulary is not actually modelled, let alone properly exposed.
2. The project has multiple hard dependencies to Spring. Where I work Spring in general is considered enterprise legacy cruft.
3. Is seems conceptually opaque and written in a less than expressive code style in its most vital parts.

... and then left immediately.

With that in mind and the observation this project smells all but dead - this seems like a wasted opportunity. I cannot even fork this because it would basically be an 80% rewrite.

Also, what have Siren and Uber to do in a project named hydra-java?

Yes, this is a rant! If you create something, leave it in a prominent place, making it look like a solution to a problem and then just never come back - it will cost other peoples time.

Paxbit

[dschulten]

Please rewrite as suggested.