Personal Opinion about GraniteDs.

[Oliver Günther]

First I want to say, what great project (idea) you people have. We were considering using it in a company internal application as a fist prototype and for future evaluation. So it saddens me to to say: Not happening right now.

But because I see great potential here and hope to try it again in the future, I want to give some feedback. I'm also aware, that this is an OpenSource project and probably most of the work is done in free time. So please don't take this as a flaming against the project or the team behind it, but as constructive criticism.

For us the JavaFX/Android Data part was the main focus of interest. So I primary played around with the granite data tutorial. To show what I did and there I hit bumps I'll give a aggregated overview:

I started to play around with the “Hello World” Tutorial and everything worked fine. Than I looked into the data-tutorial and the problems started. First there were some dependencies wrong in the middle. I got suspicious for the first time about everything as I look into the (IMHO) slightly over engineered tutorial structure. At least the spring/tomcat part started to work, but no EJB Server variant. Found a dependency error of the Tomee Plugin (a outdated snapshot version was defined), but still got very confusing errors. (I focused on tomee cause this is the EJB Server I'm most familiar with). To be sure the errors are not due to the project structure, I rebuild it in a simplified form. After a long search and digging through the documentation more than once, to be sure I didn't overlook something, I got suspicious about the openjpa implementation.(Well, later William validated my findings https://github.com/graniteds-tutorials/graniteds-tutorial-data/issues/1) So I switched to hibernate on tomee. At least now the server seamed ok but the client started to throw NPEs. From here on I integrated the helloworld tutorial, made changes based good old tryNerror and at some point got it alive. At this point I was starting to hope that I could see GraniteDs in action. So I generated 1000 Entities and started to scroll in the UI. Scrolling got extremely slow and sluggish and at the console I cound see that the same messages were send between sever and client over and over again. Still thought, this could be overcome, I looked into the RemoteLazyLoading. So I enhanced the Model with a 1-n lazy association and got NPEs back. Now finally I was stuck and without an Idea, so I used the forum. https://groups.google.com/forum/#!topic/graniteds/6OjtkcYadLs. The Result: EntityManager only over jndi name supply-able, probaly only one EntityManager allowed. AFAIK Jboss is the last server which supplies an EnitiyManager per jndi name per default. In Tomee and Glassfish workarounds would be needed. So I used the force and read the source in the hope of creating a new solution for EM discovery. Well I tried. A build out of the box brook. Looking into the project structure I got a little bit shocked. One gradle config for all projects, IntelliJ IDEA and Eclipse configs in all subprojects. This got me scared enough to finally stop.

So here are some suggestions for the future:

Documentation:

Make sure all features are documented. Consider optimization of the documentation based on cases. If I'm into building a EJB/JavaFX stack, I have to read though most of the other parts. Switch form simple to detailed. e.g. The part about EJB3 integration starts with telling me all the configuration options and ends with, that for the default case I don't need anything. I also recommend a open roadmap and a feature/tested on matrix. So that some can see, Version X is tested on tomcat 7.023 and jboss 6.x on os e.t.c. An what is now working right now.(As described before, by looking into your homepage and the tutorial docs, I got the opinion, that everything works everywhere) Finally the source is also missing javadoc at all places.

More and smaller Tutorials/Examples:

Make the tutorials/examples in a way to show the most simplest implementation. So a newcomer sees, what is needed for that specific case. I personally like the examples in the tomee project tree, just to get the idea.

Clean up the Project Structure:

I've seen that this has been started, as the gradle config got split up in the last days. I recommend the to push beyond the IDE configuration files, these should be generated on demand after checkout. And even that I'm a maven fan, I would recommend to update the tutorials to use gradle if its your tool of choice. Moreover split the projects by type. So that development of a server part does not essentially need the others to build. (The upstream seams most of the time broken, this would help)

Make Errors more selfexplainig:

Errors in the Serialization/Deserialisation Process are not very conclusive. Especially if something is not yet implemented. Again see. https://github.com/graniteds-tutorials/graniteds-tutorial-data/issues/1. And running into NPE's is most of the time not helpful (Messages and Deserialisation on the Client side). Especially than the server just warns, that he didn't find the EntityManager how about an empty collection on the client side.

Higher Reaction in the Community Forum:

If you look into the Granite Data Service Forum you see questions unanswered. Or only answered after many days and a poke (Like: Anyone a Idea?). I don't expect that every question can be answered satisfying in under a day. But at least somethings like: “Much to do, might look into this next week or next month”. Or “Please supply a out oft the box example code” or “Mr.X do you have an idea”. As far as I can see, the developers are not so may, that this would boil up the communication.

Too sum up, I will still look into the project sometimes and like to see it continue successfully. And again, please don't take this as flaming or anything bad. Just some ideas what this project may need.

Regards and keep up the spirit,

Olli

[wdrai]

Hi Oliver,

Thanks for this detailed feedback.

I completely understand your frustration after such a number of issues, find my answers below

First I want to say, what great project (idea) you people have. We were considering using it in a company internal application as a fist prototype and for future evaluation. So it saddens me to to say: Not happening right now.

But because I see great potential here and hope to try it again in the future, I want to give some feedback. I'm also aware, that this is an OpenSource project and probably most of the work is done in free time. So please don't take this as a flaming against the project or the team behind it, but as constructive criticism.

For us the JavaFX/Android Data part was the main focus of interest. So I primary played around with the granite data tutorial. To show what I did and there I hit bumps I'll give a aggregated overview:

I started to play around with the “Hello World” Tutorial and everything worked fine. Than I looked into the data-tutorial and the problems started. First there were some dependencies wrong in the middle. I got suspicious for the first time about everything as I look into the (IMHO) slightly over engineered tutorial structure. At least the spring/tomcat part started to work, but no EJB Server variant. Found a dependency error of the Tomee Plugin (a outdated snapshot version was defined), but still got very confusing errors. (I focused on tomee cause this is the EJB Server I'm most familiar with). To be sure the errors are not due to the project structure, I rebuild it in a simplified form. After a long search and digging through the documentation more than once, to be sure I didn't overlook something, I got suspicious about the openjpa implementation.(Well, later William validated my findings https://github.com/graniteds-tutorials/graniteds-tutorial-data/issues/1) So I switched to hibernate on tomee.

EclipseLink and OpenJPA are definitely not yet supported for now with the JMF protocol we use for JavaFX/Android, we have added this mention clearly in the last versions of the tutorial. 

The TomEE maven plugin was not final when we first built the tutorial, so the version was maybe outdated and was indeed a snapshot at this time. Latest tutorial use a more recent version.

As for the overengineered tutorial structure, you're probably right as it is a pain to maintain (but still better than what we had before). 

Yet we have not found a reasonable and simple way to provide examples that can work with the various technologies we are integrating with on the client and the server. For the data tutorial, there are already 9 possible client/server combinations, not even counting the various appserver options.

One option would be to choose only one target technology (say Tomcat/Spring/Hibernate for example), and let people try to adapt it to their case.

 

At least now the server seamed ok but the client started to throw NPEs. From here on I integrated the helloworld tutorial, made changes based good old tryNerror and at some point got it alive. At this point I was starting to hope that I could see GraniteDs in action. So I generated 1000 Entities and started to scroll in the UI. Scrolling got extremely slow and sluggish and at the console I cound see that the same messages were send between sever and client over and over again.

Very strange, I did not see any NPE with the tutorial with 3.0.4.GA. Could you send me you non working project ?

 

Still thought, this could be overcome, I looked into the RemoteLazyLoading. So I enhanced the Model with a 1-n lazy association and got NPEs back. Now finally I was stuck and without an Idea, so I used the forum. https://groups.google.com/forum/#!topic/graniteds/6OjtkcYadLs. The Result: EntityManager only over jndi name supply-able, probaly only one EntityManager allowed. AFAIK Jboss is the last server which supplies an EnitiyManager per jndi name per default. In Tomee and Glassfish workarounds would be needed. So I used the force and read the source in the hope of creating a new solution for EM discovery. Well I tried. A build out of the box brook. Looking into the project structure I got a little bit shocked. One gradle config for all projects, IntelliJ IDEA and Eclipse configs in all subprojects. This got me scared enough to finally stop.

Sure, one gradle build file for all projects was more convenient during the migration from our old ant build file as we were constantly changing and modifying it. For 3.1 the structure is more stable and the gradle build is now split in each subproject.

I'm curious to see what broke in your build, we use it all day and don't have much problems with it.

So here are some suggestions for the future:

Documentation:

Make sure all features are documented. Consider optimization of the documentation based on cases. If I'm into building a EJB/JavaFX stack, I have to read though most of the other parts. Switch form simple to detailed. e.g. The part about EJB3 integration starts with telling me all the configuration options and ends with, that for the default case I don't need anything. I also recommend a open roadmap and a feature/tested on matrix. So that some can see, Version X is tested on tomcat 7.023 and jboss 6.x on os e.t.c. An what is now working right now.(As described before, by looking into your homepage and the tutorial docs, I got the opinion, that everything works everywhere) Finally the source is also missing javadoc at all places.

Right, we try to improve it at each iteration. Note that the old documentation was much much worse ;)  

More and smaller Tutorials/Examples:

Make the tutorials/examples in a way to show the most simplest implementation. So a newcomer sees, what is needed for that specific case. I personally like the examples in the tomee project tree, just to get the idea.

Helloworld/Chat/Feed are done this way. Probably there is some missing link between these ones and the Data example which is a bit more complex.

Clean up the Project Structure:

I've seen that this has been started, as the gradle config got split up in the last days. I recommend the to push beyond the IDE configuration files, these should be generated on demand after checkout.

For some reason the IDE files generated from the gradle build file are totally unusable without a lot of tweaking (be it for IDEA or Eclipse). Some integration tests are too complex and go beyond what the gradle to IDE plugin is able to handle, maybe they should be in a separate project.

And even that I'm a maven fan, I would recommend to update the tutorials to use gradle if its your tool of choice.

We started with gradle, but unfortunately there are far less appserver plugins than maven (last time I checked there were only tomcat and an obsolete jetty plugin). Same for the archetypes, there is currently no equivalent with gradle, so anyway we have to maintain some parts with maven.

 

Moreover split the projects by type. So that development of a server part does not essentially need the others to build. (The upstream seams most of the time broken, this would help)

 

Make Errors more selfexplainig:

Errors in the Serialization/Deserialisation Process are not very conclusive. Especially if something is not yet implemented. Again see. https://github.com/graniteds-tutorials/graniteds-tutorial-data/issues/1. And running into NPE's is most of the time not helpful (Messages and Deserialisation on the Client side). Especially than the server just warns, that he didn't find the EntityManager how about an empty collection on the client side.

Right, this is definitely something that has to be improved.

Higher Reaction in the Community Forum:

If you look into the Granite Data Service Forum you see questions unanswered. Or only answered after many days and a poke (Like: Anyone a Idea?). I don't expect that every question can be answered satisfying in under a day. But at least somethings like: “Much to do, might look into this next week or next month”. Or “Please supply a out oft the box example code” or “Mr.X do you have an idea”. As far as I can see, the developers are not so may, that this would boil up the communication.

Usually we answer on the forums at least once a week, or more quickly when people report obvious bugs. It's a bit random to be honest and we can't provide any guaranteed response time on this kind of forum.

 

Too sum up, I will still look into the project sometimes and like to see it continue successfully. And again, please don't take this as flaming or anything bad. Just some ideas what this project may need.

No problem, this is exacly the kind of feedback we like, even if obviously we would prefer messages like 'Your project is great, I love everything and I don't have any problem'.

 

Regards and keep up the spirit,

Olli

Thanks

William

 

[Oliver Günther]

Hi,

even if this is a little bit old. Thanx for the replay.

I added the changed tutorial in git: https://github.com/og0815/granditeds.javafx.sample
I will updated it from time to time to see if something gets better :-)

And I probably will look it your code in the future, still think this is a great and one and only project.

Regards.