Discussions

News: Generic Repository 1.0.0 is released

  1. Generic Repository 1.0.0 is released (13 messages)

    The Generic Repository (grepo) is an open source (ASLv2) framework for Java which allows to access (database) repositories in a generic and consistent manner. Using grepo it is generally no longer required to provide all the boilerplate code which is necessary in order to access (database) repositories from Java. All you have to do is write appropriate database code (queries, procedures, functions etc...), an appropriately annotated Java interface and very little Spring configuration. The main features of version 1.0.0 are: * generic support for Hibernate based DAOs * generic support for Jpa based DAOs * generic support for executing database stored-procedures and -functions * highly customizable Check http://grepo.codehaus.org for further information.

    Threaded Messages (13)

  2. JDO (Google App Engine) Support[ Go to top ]

    Is there a list of repositories that are currently (or planned to be) supported? Specifically is Google App Engine supported?
  3. Re: JDO (Google App Engine) Support[ Go to top ]

    Grepo currently supports generic database access (gquery component) using the following APIs: * Native Hibernate API * Java Persistence API Furthermore generic support for executing database stored-procedures and -functions is provided (gprocedure component). Support for the following APIs is planned in the future: * JDO * Native JDBC (based on Spring JDBC) Regarding Google App Engine: I'm not a "Google App Engine" expert, but the "App Engine datastore" should be accessible via JPA and so it should be possible to use Grepo and access the "App Engine datastore" via JPA.
  4. Spring?[ Go to top ]

    Do you provide a generic Spring wrapper?
  5. Re: Spring?[ Go to top ]

    nevermind, I actually had to read
  6. Spring is required?[ Go to top ]

    I'm a little confused. Is the Spring Framework required for this to be used? Would it be enough to just include the Spring Jars? Or can this be used entirely separately from Spring? (Raw JSF, Seam, etc.)
  7. I am looking forward for someone to provide Generic Wrapper around Generic Repository, which would further simplify usage of Generic Repository (I am in dilemma to start such a project myself). Especially exception handling would be simplified as Generic Repository exceptions would be wrapped with Generic Wrapper exceptions, which would themselves wrap underlying Repository exceptions, which of course, wrap JDBC exceptions at the end. Stack traces will be very simple to read and to 'trouble-shoot in-the-foot'. Of course, there should be Generic Repository Query Language, which would wrap and unify various repository Query Languages, which of course wrap SQL at the end. Generic Wrapper would, no kidding, provide a generalization of Generic Repository Query Language. There would be nice GUI tools to translate Generic Repository Query Language into Generic Wrapper's generalization of Generic Repository Query Language. Furthermore, it would be interesting to have support for Generic Wrapper in Generic Repository, so that we can wrap Generic Wrapper with Generic Repository and then simplify things further. The flexible possibility of this recursive wrapping will be the masterpiece of generic design. All this will be of great help to more quickly solve concrete mission critical business problems that customers have in the very concise and efficient manner.
  8. I am looking forward for someone to provide Generic Wrapper around Generic Repository, which would further simplify usage of Generic Repository (I am in dilemma to start such a project myself).
    That sounds like an excellent idea mate! I mean, if it could work for logging, then I see no reason at all that it can't work for (database) repository access. Good ideas guys! This is what pushes Java as a platform forward! :)
  9. I am wandering when will some IT loud-speaker loudly say that frameworks are by nature very useless and that they have very limited area of usage? Frameworks try to promote reuse and correct usage of patterns by forcing the user to use them 'correctly' and by abstracting and wrapping things and by putting the framework user's work 'in-a-frame'. But abstracting and wrapping leads to greater complexity, while enforcing 'correct' usage of patterns and 'framing' the user leads to limited flexibility. Instead we should embrace ubiquitous design and patterns (their pros and cons and area of applicability). Frameworks are dead-end.
  10. Frameworks are dead-end.
    I think you need to consider getting out of development if this is really how you feel. Tom
  11. Frameworks are dead-end.
    So, uhmm.. you mean that... we should all resort to writing in assembly language?
  12. I agree[ Go to top ]

    I don't like frameworks much myself either because they enforce a certain design and seem unnecessary, which I translate to as making applications needlessly complex. I think if third party vendors concentrated on creating compact and specifically designed tools, it would make modern programming more efficient and simpler to maintain: just pick and choose the classes you need without creating intricate dependencies. I blame EJB for starting this whole mess.
  13. Re: I agree[ Go to top ]

    I don't like frameworks much myself either because they enforce a certain design and seem unnecessary, which I translate to as making applications needlessly complex. I think if third party vendors concentrated on creating compact and specifically designed tools, it would make modern programming more efficient and simpler to maintain: just pick and choose the classes you need without creating intricate dependencies. I blame EJB for starting this whole mess.
    Yeah, and I still blame all Germans for that little stunt they pulled on us in 1940! :( C'mon, seriously. EJB2 was years and years ago. The current version, EJB3 is a lightweight, elegant and a beautifully designed framework. It helps to remove all the needless complexity in our code base, big time! Have you ever worked an a project of any size where no framework was being used? I have and it wasn't pretty! Hundreds of JSP pages with embedded business logic, where everybody did everything differently. Code re-use and code interoperability was nearly impossible and the whole thing was basically just a big lump of spaghetti. p.s. For the one's don't getting it, *of course* the remark about the Germans above was sarcastic and naturally I don't mean that literally at all. It just to show how idiot it is to keep making references to EJB2, which happened long ago in the past.
  14. Bad analogy[ Go to top ]

    Your analogy breaks down because the Nazis were defeated but we are still in the midst an era of complex frameworks dominating our profession, which didn't exist before EJB. I have not looked at EJB3 becuase I don't need it, which is my point. Most of these frameworks and a whole host of other tools in my experience have done the opposite of what they promise - make programming easier. Instead, they have made it more difficult because now you have to learn how to use and work with the framework, which has nothing to do with the application. It's all just additional "accidental" complexity introduced into the system. As evidence, simply look at all the books, forums, and tutorials out there that are dedicated to help us understand these frameworks and tools. I've just completed my .NET certification training and it wasn't easy. It's an unholy complicated mess of a framework with intricate dependencies and behind the scenes voodoo. These didn't exist ten years ago, but we were building web pages that are just as complex back then as they were today. It's still all just HTML, SQL, and javascript with Java to tie them all together. Everything you need to build a website has been there for years. The only problem is that design has fallen to the wayside resulting in the development mess that you may have experienced, but design cannot be replaced by a tool.