OFBiz Delegator that uses JPA

[ofbiz-3]

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

[Paul Piper]

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.

[taher]

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" <[hidden email]> 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.
>

[Paul Piper]

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

[Paul Piper]

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.

[Pierre Smits]

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 <[hidden email]>
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" <[hidden email]> 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.
> >
>

[Michael Brohl-3]

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 [hidden email]:

> 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