OFBiz Plugin Management, status and propositions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

OFBiz Plugin Management, status and propositions

Olivier.heintz
waiting for comments, corrections and propositions

I will use :
- component as a web-application, like it's currently in ofbiz
- feature as an enhancement of an existing web-application

Question is : How to add in OFBiz a new "Feature" ?
===========
Sub-Question is : How a developer extract and package it's work after
developing a new feature ? to send it to Jira, or to commit to a new
Extra or ...
---------------


What exist in OFBiz by adding file:
==================================
1) adding a component,
2) adding type data (ex: roleType, orderType, workEffortType, ...)
3) adding entity or field in entitymodel with extend,
4) extend existing form
5) extend a portal page by adding portlet
6) extend existing service with seca

Disadvantage of these methods (1 for adding component, 2 for adding
data, ...)
-----------------------------
1) nothing
2) very little disadvantage when creating a new feature, it's more
intuitive to add in the file there are already similar data
3) when adding field in an existing entity for using it in a new
component : nothing
when adding a field for a feature or to use it in the existing
application : little disadvantage, retrieving the full entity definition
is more difficult, but webtools has good tools to answer.
4) no disadvantage for new screen or component, not usable to extend
existing screen
5) very little disadvantage, not possible to remove a portlet
6) same as 3 and not a solution to add extra test or extra update using
data available in the service

Important Remark about extending an existing service :
Most of the time, the first step is to organize the ofbiz service to be
able to extend it, otherwise the only solution will be to patch the
service code.


What is needed to define a OFBiz plugin :
===========================
1) Name and description
2) release number
3) OFBiz release (or svn release for trunk) for which it's installable
4) License Usage
5) Owner
5 bis) repository where it's available
6) Maintainers and contributors list (responsible for all piece of the
plugin ;-)
7) plugin dependency list

and so optional
8) Technical help for install process and/or important technical point
about it

End User help, Junit test, End User test are not in the list because
they are in the "OFBiz feature normal definition". All new features
accepted in the  OFBiz project should coming with these 3 points. ;-)


What installing a OFBiz plugin can do :
===============================
1) adding file
2) updating xml file (removing and/or adding in the dom tree)
3) adding import and method in java or replacing empty method (not
updating see <<Remark about extending an existing service>> )

Generation, Compilation, create entity or field in database, loading
data, ... will be done by the standards OFBiz starting process


What exist in Neogia Addon Management,  which is with a Apache 2.0
license from the beginning (3 years ago) to be able to be proposed to
OFBiz community :-)
=====================================
In a addon
---------
  1) add-on.xml file contain point 1 to 6 of What is needed
  2) ivy.xml file contain plugin dependency list
  3) helpdata directory contain "optional" helpfile to integrate in
OFBiz endUser help organization as addon help in Help tree on the
installed process

When installing, it's to possible
--------------------------------
  1) adding file (on linux environment, there are still some pb on windows)
  2) updating widget, form, menu, entity, servicedef, controller,
ofbiz-component  file by using dom tree organization
example :
<?xml version="1.0" encoding="UTF-8"?>
<patch>
<x:add path="/" previous="/form[addCalEventRole]/">
<form name="FilterCalendarEventsPortlet" extends="FilterCalendarEvents">
...
...
</x:add>
</patch>

<x:remove xxxxx >   exist too

  3) adding in begging or ending in data or script xml file
  4) using standard patch format in all other case (java, groovy, update
xml script, ...)

Packaging and dependency management
----------------------------------
- packaging is a zip file with release number in name
- dependency is done by ivy http://ant.apache.org/ivy/
   so it's easy to manage multiple repository for the end user in the
install process
- admRepository is a server tools which manage a addon repository :
create zip file after commit, create new release for all addons that
depend on it.


Summary
=======
For the current <<Lose Weight Program for OFBiz>> I think current ofbiz
tools and Neogia addon manager can manage properly extras OFBiz
repository,  to be able for extras with commiters, to evolve in parallel
with OFBiz.

BUT there are still some works to make acceptable the Neagia Addon
Manager by the OFBiz community and OFBiz PMC, as a framework component
or as the first OFBiz-Extra :-)  I'm sure there are some contributors
ready to do what is necessary.

I'm not a technical maintainer of the addon manager, I'm only one of the
business Analysts which define since 3 years what it should do, and a
daily user of it ;-)
I don't know if the current technical addon management choice are the
better or the perfect one, I only know that it exists, it works in some
case and there are several month of experience month of its use,
therefore its advantage and disadvantage.



Ready to complete or answer, and hoping contributing in the <<Lose
Weight Program for OFBiz>>

Olivier

Ps : about modification extracting sub-question, I will develop in
another email when needed