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...
The Hydra vocabulary is not actually modelled, let alone properly exposed.
The project has multiple hard dependencies to Spring. Where I work Spring in general is considered enterprise legacy cruft.
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.
dschulten
commented
6 years ago
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...
... 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