evaluating move from adempiere to idempiere

[Silvano Trinchero]

Hi all,
we are currently evaluating the migration of our code base/customers from adempiere 360 to iDempiere (vs migrating to adempiere 380).
For the technical side of thing, i have a first round of questions related to implementing customization. Many questions may come later, but for this one i dont know how to check it by myself (zero competente on osgi).

Now we use 3 layers of code: one ends up in patches.jar, the other two in packages/NAMEOFPACKAGE. The second one is split in two levels: common modules, and a module for the customer specific customizations (not all customers have one), the precedence of custom modules over standard is managed by naming convention (based on how adempiere server "build" works).
So i need to replicate something similar in iDempiere:
1. i have seen  in redhuan documents that its possibile to replace a core class (the example was a process) with a custom one: but what happens if i need to replicate the function again for a specific customer ? module A replace the core one, module C replace module A class with even more specific behaviour.
Is there some concept of 'precedence', so if module C depends on module A, module C declarations takes precedence over A ?
2. the same method may be used for all classes ? (we did modifican to model, form, processes and to ui related one, like tab/windows management, mail send functions and so on)
3. How are patches managed by idempiere ? sometime is needed to produce a fast fix to a bug, and not always is possible to wait for a stable release.

The questions are made coming from adempiere way, so maybe there is a totally different approach to this in osgi, if so, i'll appreciate any pointer :)

Thanks in advance,
Regards,
Silvano

[Carlos Antonio Ruiz Gomez]

Hi Silvano, welcome to iDempiere.

The patches/packages approach was replaced in iDempiere. That approach
in the end will confront you with the classpath hell that OSGi is
precisely intended to solve. i.e when two packages require different
versions of the same library.

In iDempiere almost everything you need can be done via plugins.
Although the old approach to extend is maintained for backward
compatibility reasons - it is recommended to move your plugins and
implement the new ones following the OSGi approach - i.e. instead of
registering a callout in the dictionary (which can collide with other
extensions easily) you define a factory and provide the callout
depending on table+field.

For the rare cases you find the need to update core we advise to raise
that need in forums to be considered as an "extensibility bug" - if the
core can be modified in order to allow pluggable modifications on your
need usually we welcome that kind of modifications. For the design part
of those extensibility solutions we use the forums and sometimes they
are discussed in the wednesday meetings.

If definitely you need to modify core by whatever reason - what we
recommend is to fork idempiere in bitbucket and apply your modifications
(still is always best if you let us know about this extensibility
issue). Bitbucket is great about showing you the differences between
your version and "official".
Your own fork is the best way to apply quickly those fast bugs you
mentioned in numeral 3. Just remember to contribute those bug fixes
back to idempiere.

Regards,

Carlos Ruiz

> --

[redhuan d. oon]

You hit the nail on the head with the question about 'replicate the function again for a specific customer ?' Indeed OSGi is created particularly for such complex ERP software engineering. In the first place, when your changes are not in the core but in loose plugins that are easier to decouple, then it is easier to manage mixing with other variants of plugins. Of course you have to be good in your componentisation and OSGi has given Java its real potential. Otherwise its four principles of inheritance, encapsulation, polymorphism and abstraction is a myth as the  jar classpath hell example given by Carlos happened in Adempiere, not to mention political hell when code breaks each other.

Thus i am supportive of not touching the core at all. I will recommend more abstraction of the core by breaking into further plugins so that in future iDempiere becomes a true messaging kernel surrounded by suites and plugins. Since i am not that detailed as Carlos technically i leave it at that and just say welcome, you can count on my support too.

[Silvano Trinchero]

Hi Carlos and Redhuan
thanks both for the welcome and the prompt answer !
I am aware we will have to re-structure our code base to make it compliant to the idempiere way, as of now i need to provide an answer to the question: can we still maintain patching, standard modules, and customer-specific behaviour( that can and will collide, due to specialization, with patches and modules).

From your answer, patching can be replaced with a fork, with the added benefit of being easier to import fixes from iDempiere, and contribute them.

> i.e. instead of registering a callout in the dictionary (which can collide with other extensions easily) you define a factory and provide the callout depending on table+field.

The factory approach works if i need to add a callout, but what if i need to replace one (remove the existing, add a new similar one) ? I remember we need to do it for a couple of customers, to tailor some behavior to their specific needs.
I have checked the idempiere demo, and (as an examples) process are still defined with a class name: which is the preferred approach to replace them in a "pluggable way" ? (without changing the database definition).

Its still unclear to me how some thing may work in practice: for example, for the italian localization we needed to replace process, forms and other non-dictionary functionality. Then the same functionality gets replaced again due to a customer need... If i can only "plug" (add), how can i manage that ?

> For the rare cases you find the need to update core we advise to raise that need in forums to be considered as an "extensibility bug" - if the core can be modified in order to allow pluggable modifications on your need usually we welcome that kind of modifications

The fact modifications are welcome is a good news :)

From Redhuan asnwer:

>You hit the nail on the head with the question about 'replicate the function again for a specific customer ?' Indeed OSGi is
> created particularly for such complex ERP software engineering. In the first place, when your changes are not in the core
> but in loose plugins that are easier to decouple, then it is easier to manage mixing with other variants of plugins. Of
> course you have to be good in your componentisation and OSGi has given Java its real potential. Otherwise its four
> principles of inheritance, encapsulation, polymorphism and abstraction is a myth as the  jar classpath hell example given
> by Carlos happened in Adempiere, not to mention political hell when code breaks each other.

In Adempiere inheritance, polymorphism and abstraction ceases to be relevant when (as an example) the dictionary is explicit about what class implements a process. iDempiere changed that ?

I am sorry if those are obvoius questions, or if i missed some wiki/doc with the answers.

Thanks for your time and answers,
Regards

[redhuan d. oon]

Regarding that specific reference to ADempiere vs iDempiere in OO approach, yes, indeed OSGi framework is more advanced towards that. For example vis the use of DS (declarative services) the plugin or Callout or even process makes the call (Hollywood principle of 'don't call me i call you'. This means a lot as it is decoupled from the core and the so called AD need not be aware of too many things thus reducing maintenance.
In a case to case basis, i have not seen any ADempiere new task that iDempiere has no workaround in. If you can gather more community members in your region i am willing to go spend time coaching them with a good proof of concept case.

[Carlos Antonio Ruiz Gomez]

> The factory approach works if i need to add a callout, but what if i
need to replace one (remove the existing, add a new similar one) ?

The old approach still works - you can edit the callout in dictionary
AD_Column.

Regards,

Carlos Ruiz

[Silvano Trinchero]

Hi Carlos and Redhuan,
thanks both for the answers and pointers.

Regards,
Silvano