Pierre Smits wrote:
Dear Paul, and all others providing feedback before me,
Contradicting architecture
I agree that current architecture is hindering growth. Having apps in the
‘applications’, ‘specialpurpose’ and ‘hot-deploy’ is a matter of taste. I
guess it was decided upon in the early days of the project and since then
been regarded as cast in stone.
Not at all, it's all about layers: specialpurpose rely on applications which rely on framework. In a perfect world there should be
no dependencies of the upper layers upon lower. Unfortunately framework dependencies upon applications has been introduced and this
is the main root all these discussions. Please don't make assumptions and keep focused (stand for both Paul and you Pierre ;o)
But what is more important is the fact that a number of screens and forms
in applications.are dependant on screens and form in other applications
wherever they are found. Reuse of services I agree to, because for that is
the intention of the solutions in the framework (and found in the framework
folder). But each application should be as much self providing (self
contained?) as possible, because each application is following a different
business purpose and should therefore be able to be run as contained as
possible.
On that I have mixed thoughts. I like to be able to do it and it saved my day many time. Also we could consider Jacopo's proposition
to have only one big ERP application (only one erp component?). But, like some others, I prefer to keep the current structure and
have separated components. I don't see the possibiliy of being able to use cross component features like something hindering me to
work properly, actually quite the contrary: it keeps OFBiz DRY. This said there are some flaws like
http://markmail.org/message/g2lp3n4vovgelqyf and http://markmail.org/message/37k4bg7ajlkaje3n (not sure I opened the Jiras I
promised...) but those as not specifically inter apps
Having applications in either sub projects in current OFBiz community setup
or outside and under no guidance/control of the community is again a matter
of taste. But I believe that having any application as dedicated sub
project will enhance the community aspects more (despite the increase in
paperwork) than having them as separate projects on another platform.
+1
Any application needs to serve a business purpose/need, no one will deny
this. Any enhancement in functionality, change of setup and/or bug fix
should serve a community purpose as well. I believe in the past some
misjudgements have been made in the community. When contributors provide
feedback, enhancements, improvement and bug fixes their products have to go
through a vetting process by their peers and the committers.
But I have seen committers dumping code into the product without consulting
the community (contributors and committers) on the need (business and
community) and technical adherence to the framework for it. This is more of
an adoption hindrance than lacking technical maturity (which I think it
has). Both by peers and customers, because if we (the community) not act as
one, there is no community that supports the product
Make it accessible
It's more the lack of manpower wiht enough knowledge and committment (ie really active committers). But yes there have been even
almost fight in some cases. Also a reason why the current action is taking place IMO. We need to cure some things...
Like for my answer to Paul, this is only my POV and not the PMC or
committers....
HTH
Jacques
This is more a marketing issue than a technical one. OotB, OFBiz enables
any of us to showcase eco-system functionality tailored to specific target
audiences, whether they be marketing and eCommerce, warehousing/logistics
oriented, FICO or Project Mgt/Workflow oriented. It is just a matter using
the right demo account for the need required.
When you show all while demoing with the admin account you’ll get
information overload and a difficulty in acceptance of any specific
solution.
My 2cts
With my utmost regards,
Pierre Smits
