Re: OFBiz Delegator that uses JPA
Hi Markus, thank you for your interest in Apache OFBiz and welcome to the community! This is definetely an interesting contribution and we would be happy to review your work. I suggest to create a Jira issue explaining your thoughts and solution. You can apply code via patch files against trunk to enable the community to review and test. Thanks again and have fun, Michael Am 01.12.16 um 12:58 schrieb of...@mk-multimedia.de: Hi all, my name is Markus Küspert and I am a software developer from Germany that writes mainly J2EE applications. I found the OFBiz project some months ago on the Internet and really like it. I also followed your discussion about defining an OFBiz project strategy. For me one of the main disadvantages of the project is the lack of using modern standards. OFBiz is a complex software that is to be used in a complex environment. In my opinion there is no "user" that downloads the software and starts using it because a "user" knows how to do its work and not setting up a complex software. I think there always has to be a software solutions company that wants to use OFBiz for their customers. But such a company focuses on using standards and well known design patterns to get things done in a reasonable time (see http://stackoverflow.com/q/5862995/5223047). And without such companies there are no users. The classloader mechanism that was used in previous releases was a bad example for reinventing the wheel and making things unneccessary complex. The current "trunk" version of the project is much cleaner, less complicated and a huge improvement! But there is still a lot of code that is used to write a framework (e.g. caching, transaction handling, web service interfaces) that already exists or could be realised much easier with a (full) J2EE application server. By using existing standards all developers could focus on the business logic for the ERP system. I am interested in contributing code and I think I can write a drop in replacement for the current delegator that uses the Java Persistence API (JPA) instead. The reasons for doing this are: - Mature and standard library that does the cache and entity persistence handling - By using JPA entities the code becomes much more typesafe because there are either named queries that are automatically checked for correct field names or the criteria API that automatically generates a metamodel that can be used for queries. Existing modules can still use the current query style (and can be rewritten step by step) but new modules can use the power and type safety of JPA named queries or the criteria API. - Creating RESTful webservice without writing code (see https://docs.oracle.com/middleware/1212/toplink/TLADG/restful_jpa.htm) - Another step to move the project to a modern J2EE application. Are you interested? Greetings Markus Küspert smime.p7s Description: S/MIME Cryptographic Signature
Re: OFBiz Delegator that uses JPA
Hi Markus, Welcome to this thread. Your suggestion seems to make sense somewhere. I, and I guess other contributors also, need more information to absorb before the impact of refactoring towards inclusion of JPA can be fully assessed. In your posting you reference a thread on StackOverflow. I venture to state that a lot has changed since 2011, and companies like my own (ORRTIZ.COM), Ilscipio GmbH and others (see [1]) as OFBiz Implementation and Integration partners can achieve a running OFBix production setup in considerable less time required than stated in the replies to that StackOverflow posting. Should you feel requiring more info in that area, feel free to contact me here of via a DM. [1] https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Service+Providers Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Thu, Dec 1, 2016 at 2:05 PM, Taher Alkhateeb <slidingfilame...@gmail.com> wrote: > Hi Paul, > > Please stop hijacking threads and discussions about OFBiz to promote your > fork. This is not the first time someone asks a question or makes a comment > about OFBiz in which you switch the thread towards your fork. > > Regards, > > Taher Alkhateeb > > On Dec 1, 2016 4:02 PM, "Paul Piper" <p...@ilscipio.com> wrote: > > > Hi Markus, > > > > perhaps you should take a look at www.scipioerp.com - it is a modern > fork > > of > > the Apache OFBiz framework. > > > > I am sure it is what you are looking for. > > > > Regards, > > Paul > > > > P.S.: Am from Wiesbaden myself - if you want, you can send me a private > > mail > > and we can get in touch. > > > > > > > > -- > > View this message in context: http://ofbiz.135035.n4.nabble. > > com/OFBiz-Delegator-that-uses-JPA-tp4699936p4699937.html > > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > > >
Re: OFBiz Delegator that uses JPA
As an afterthought, Taher: please refrain from hijacking the discussion. If you happen to have a problem with individuals giving input, feel free to start a different thread. -- View this message in context: http://ofbiz.135035.n4.nabble.com/OFBiz-Delegator-that-uses-JPA-tp4699936p4699940.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBiz Delegator that uses JPA
Taher, we have had this discussion multiple times on the ml - and the outcome in the past has been that any input is appreciated. So, I am not sure what you are referring to. (For reference, look at the discussion I started on the very same topic here: http://ofbiz.135035.n4.nabble.com/BigFish-Promotions-td4643157.html) As for the discussion - I think that Markus has the right to see all aspects of Apache OFBiz. Forks included. Take it as a good sign that this community is not dead. Regards, Paul -- View this message in context: http://ofbiz.135035.n4.nabble.com/OFBiz-Delegator-that-uses-JPA-tp4699936p4699939.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: OFBiz Delegator that uses JPA
Hi Paul, Please stop hijacking threads and discussions about OFBiz to promote your fork. This is not the first time someone asks a question or makes a comment about OFBiz in which you switch the thread towards your fork. Regards, Taher Alkhateeb On Dec 1, 2016 4:02 PM, "Paul Piper" <p...@ilscipio.com> wrote: > Hi Markus, > > perhaps you should take a look at www.scipioerp.com - it is a modern fork > of > the Apache OFBiz framework. > > I am sure it is what you are looking for. > > Regards, > Paul > > P.S.: Am from Wiesbaden myself - if you want, you can send me a private > mail > and we can get in touch. > > > > -- > View this message in context: http://ofbiz.135035.n4.nabble. > com/OFBiz-Delegator-that-uses-JPA-tp4699936p4699937.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. >
Re: OFBiz Delegator that uses JPA
Hi Markus, perhaps you should take a look at www.scipioerp.com - it is a modern fork of the Apache OFBiz framework. I am sure it is what you are looking for. Regards, Paul P.S.: Am from Wiesbaden myself - if you want, you can send me a private mail and we can get in touch. -- View this message in context: http://ofbiz.135035.n4.nabble.com/OFBiz-Delegator-that-uses-JPA-tp4699936p4699937.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
OFBiz Delegator that uses JPA
Hi all, my name is Markus Küspert and I am a software developer from Germany that writes mainly J2EE applications. I found the OFBiz project some months ago on the Internet and really like it. I also followed your discussion about defining an OFBiz project strategy. For me one of the main disadvantages of the project is the lack of using modern standards. OFBiz is a complex software that is to be used in a complex environment. In my opinion there is no "user" that downloads the software and starts using it because a "user" knows how to do its work and not setting up a complex software. I think there always has to be a software solutions company that wants to use OFBiz for their customers. But such a company focuses on using standards and well known design patterns to get things done in a reasonable time (see http://stackoverflow.com/q/5862995/5223047). And without such companies there are no users. The classloader mechanism that was used in previous releases was a bad example for reinventing the wheel and making things unneccessary complex. The current "trunk" version of the project is much cleaner, less complicated and a huge improvement! But there is still a lot of code that is used to write a framework (e.g. caching, transaction handling, web service interfaces) that already exists or could be realised much easier with a (full) J2EE application server. By using existing standards all developers could focus on the business logic for the ERP system. I am interested in contributing code and I think I can write a drop in replacement for the current delegator that uses the Java Persistence API (JPA) instead. The reasons for doing this are: - Mature and standard library that does the cache and entity persistence handling - By using JPA entities the code becomes much more typesafe because there are either named queries that are automatically checked for correct field names or the criteria API that automatically generates a metamodel that can be used for queries. Existing modules can still use the current query style (and can be rewritten step by step) but new modules can use the power and type safety of JPA named queries or the criteria API. - Creating RESTful webservice without writing code (see https://docs.oracle.com/middleware/1212/toplink/TLADG/restful_jpa.htm) - Another step to move the project to a modern J2EE application. Are you interested? Greetings Markus Küspert
