looking at the data model book, I don't see how to do that at the data
level.
then you have ones perception of what should go where.
good example is Agreements.
I believe it should be in party but it is currently in Accounting.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Sam Hamilton sent the following on 1/27/2011 5:14 AM:
I think that we should separate everything so nothing depends on each other and
then provide release bundles so that new users to the system are presented with
a package that includes the everything and the kitchen sink but also
instructions on how to turn it off if they don't want it, while everyone else
can pick and choose what they want. Like warehouse only application or POS only
application - suppose those could also be released too???
Sam
On 27 Jan 2011, at 20:23, Pierre Smits wrote:
Crudely put, but nonetheless true.
And all can have their place in the OFBiz ecosystem. Even HumanRes could be
considered a SpecialApp. Which of the current set of core apps should stay
in? And which not? Your opinions please.
Regards,
Pierre
2011/1/27 Scott Gray<[email protected]>
If they have a user base then what does it matter? If people care then
they'll look after them and if not then they'll die, either way it's one
less thing to worry about.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 28/01/2011, at 1:03 AM, Jacques Le Roux wrote:
Project Manager, POS? Even maybe My Portal and AssetMaint?
Jacques
Scott Gray wrote:
I agree that ecommerce is significantly important enough that it should
be kept under project control but I don't believe for a
second that the other special purpose components benefit from being in
the main code base except that it increases their
visibility. On 28/01/2011, at 12:34 AM, Jacques Le Roux wrote:
Another interesting idea, competing with Erwan's. I'd also prefer to
keep things in ASF repo if possible...
We could have a distinction between components, important one
(eCommerce, ...) still in ASF repo, others more peripheric, (ebay,
Google, Oagis, etc.) out of it? Jacques
From: "Pierre Smits"<[email protected]>
That sounds like a workable solution to me as well.
But why move parts of the current code of the product (as is it is
now)
outside of the ASF' repo?
Looking at Commons in JIRA I see several related projects. We could do
this
for OFBiz too. Split up in to several sub projects, have for each sub
project a committed sub community of users, contributors and
committers. And
still having interaction between all.
Regards,
Pierre
2011/1/27 Jacopo Cappellato<[email protected]>
On Jan 27, 2011, at 11:50 AM, Scott Gray wrote:
(With so many messages I don't have a good spot to say my short
piece so
here will do)
IMO our problems will only increase with the size of the code base.
Every time a new feature is committed you have an additional
potential
audience that must be kept happy and our ability to please everybody
continues to decrease. Unhappy people don't work well together so
things
just keep getting worse.
Solution? Decrease the size of the code base and included features
and
increase the ability for the community to share contributions outside
of the
ASF's repo. Decrease the load on the committers and let the rest of
the
community put their money where their mouth is.
Some ideas (feasible or not):
- Pull out all of the themes except one and move each one to google
code
or wherever if there is someone interested in looking after each one.
- Then do the same for the bulk of the special purpose apps.
- Separate the framework from the applications.
- Remove any framework features that aren't used by the applications
or
are of relatively low value and allow them to be dropped in by users
when
they need them.
- Perhaps even take another look at the possibility of reducing the
dependencies among the core apps and splitting them (I'd gladly
welcome 100
new committers to the humanres app because I have no interest in it).
- Turn the payment and shipping gateway implementations into drop in
components along with any other pieces of code that are suitable for
extraction
- Investigate ways to allow plug-in modification of apps and
implement
something (anything) that allows it.
+1 on all points; the next step in the life of the project will be
the
setup of an healthy ecosystem and these are concrete steps in that
direction.
Jacopo
Right now we have a gigantic project with a gateway of ~13 active
committers (23 total) who have day jobs to worry about along with
reviewing
(and fighting about) commits (or just giving up on this
responsibility),
attempting to improve the project and taking part in these (mostly
pointless
discussions) and then keeping the rest of the community happy.
Increasing
the number of committers just increases the potential for
disagreement and
then stagnation so the only other option to reduce the code.
Give control of features and components to people who care about
them and
then help users find them externally as they need them. Don't like
the
direction a feature/component is taking? Fork it and compete.
Regards
Scott
On 27/01/2011, at 9:54 PM, Jacopo Cappellato wrote:
I have noticed some negative trends happening to us in the last
(1-2)
years:
* a dramatic decrease of design discussions and an increase in
commits
* committers are often working for themselves and not for the
greater
good of the project ("if a customer pays me to do something then it
will be
also good for the project")
* less peer reviews and mostly focused on formal aspects rather
then
fundamental aspects of the contributions
* a decrease in the minimum quality level needed to make a commit
"acceptable"
* a proliferation of "best practices" and "rules" in an attempt to
improve the quality of the commits
* a decay in the attitude and quality of discussions: attacks,
critics
and fights instead of healthy discussions to learn from others and
improve
design decisions
Of course I am focusing on bad things, to the good ones (yes, there
are
also good ones) it is easier to adjust: however when the final result
of our
efforts is that a person like David doesn't feel comfortable in
contributing
more then I feel bad.
The primary goal of the PMC, and the community in general, should
be
that of creating the perfect environment to facilitate contributions
from
people like David, and limit/review/improve the contributions from
other
less blessed contributors: it seems like all our efforts are
obtaining the
exact opposite result.
Jacopo
On Jan 27, 2011, at 7:46 AM, David E Jones wrote:
I'll respond here to Adrian's comments below, and to what Raj and
others have written as well.
Backwards compatibility is a huge issue, but I suppose that is as
much
a symptom as it is a disease in and of itself. The underlying issue
is
bureaucracy.
If I wanted to spend all my time chatting with others and writing
endlessly about when to do things and what to do, and trying to
recruit
others to do it... then OFBiz would be the perfect place for that. I
did
that for years, and I'm happy with what has been done with OFBiz, but
there
came a point in time where the whole bureaucratic trend became
stronger than
any single person's ability to push for new or different things. That
point
in time was at least a yeah and a half ago, and perhaps long earlier
than
that depending on how you look at it.
Personally, I'd rather spend my time on more productive efforts,
and do
so in a way that avoids this same bureaucratic mess in the future
(like
different management style and keeping framework, data model, themes,
and
applications as separate projects). This way not only I, but many
people are
free to work on what they want to and not have to argue about every
little
thing they want to do, or deal with constant complaints about every
little
thing they actually do.
Isn't separate and competing projects better than that everyone
arguing
and having to agree on what to do? Well, I have good news! No matter
how you
(the reader) answer that question, you have an option to fit your
preferences.
-David
On Jan 25, 2011, at 8:45 PM, Adrian Crum wrote:
Many of the things listed here have been discussed, and as far as
I
can tell, there is no objection to making those changes - we just
need the
manpower to do it.
Item #7 has been discussed and there hasn't been any argument
against
that change - except that it touches on the backwards-compatibility
issue.
And I'm going to use this opportunity to address that issue.
Some of the changes mentioned here wouldn't affect any of my
projects
- because I don't attempt to patch or modify the framework - I only
build
applications on it. Other changes mentioned here would make
application
development easier.
The other day Ryan Foster described the backwards-compatibility
talk
as a mantra. I view it as more of a straw man. Five days ago I posed
this
question to the user mailing list:
"Would you, as an end user of OFBiz, knowing that the OFBiz
project
could be improved greatly - but at the cost of some backward
incompatibility
- accept the changes? If yes, how often would backwards-incompatible
changes
be acceptable?"
It is interesting to note that in a list of over 400 subscribers,
no
one has replied.
The most vocal proponents of backwards-compatibility (in the
framework) are a few players who have modified the framework locally.
As a
community, do we really want to allow those few members to stifle
innovation?
Some users claimed the updated Flat Grey visual theme wasn't
"backwards compatible." What does that even mean? Some colors and
background images were changed - how is that backwards incompatible?
To be fair, I have been an advocate for backwards-compatibility.
But
that has been for things that break application functionality.
At the least, there needs to be a compromise. At best, there
needs to
be acceptance of the possibility of future versions that are not
backwards
compatible with previous versions. That concept is not new or
revolutionary
- it goes on in every software project, both open source and
commercial.
David has some great ideas, but he feels compelled to start over
from
scratch to implement them. From my perspective, that's a tragedy. One
of the
project's founders feels the need to start another project as a last
resort
to make the project he originally started better. Does that make
sense?
I don't want to use Moqui. It's an unfinished framework
controlled by
one person and it has no applications built around it. Bottom line -
it's
not an option. What I want is Moqui's innovations in OFBiz.
I believe it's time we have a serious discussion about this.
Users
have commented that there is no plan for OFBiz - what is planned for
its
future? They're right. Maybe we should come up with some plans, or
some kind
of path to the future.
I propose we put all the cards on the table. Where do we go from
here?
Continue on our present path and have competing projects that improve
on
OFBiz technology? Try to keep innovation in the project at the
expense of
some backwards incompatibility? Maintain backwards compatibility by
forking
the project to something new? Or have milestone versions that are
clearly
marketed as backwards incompatible with previous milestone versions?
Lately, it seems many of the big players in the OFBiz developer
community have been absent on the mailing list. I understand that
this is a
volunteer community, but at the same time, we all have a say, and
that "say"
depends on us saying *something.*
So, please say something.
-Adrian
On 1/25/2011 1:53 PM, David E Jones wrote:
On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote:
On 1/25/11 2:06 AM, David E Jones wrote:
All of that said, now that Moqui is starting to take shape I
find
the OFBiz Framework to be cumbersome and inconsistent in many ways
(things
that are hard to fix, but that are not surprising given the
pioneering
history of the OFBiz Framework). Those funny quirky things are likely
a
turn-off to prospective developers and I'm hoping to remove that
impediment
to adopting the approach.
David - you keep saying this..Please provide some examples of
"cumbersome and inconsistent" within the framework. And why not try
and fix
these? Instead of reinventing the wheel. What "funny quirky" things
have
turned of prospective developers? Do you have an specific examples?
Yes, I have mentioned these many times especially in the last
2-3
years. Some of them I have tried to fix in OFBiz itself and ran into
rather
large problems. These are not easy changes to make in a large and
mature
project like OFBiz, and after trying a few times I decided that a new
framework was the only way forward (another thing I've written before
and
made very clear).
These are the things that led to many aspects of the design of
Moqui,
and the best summary of them is the document I wrote about the
differences
between the Moqui and OFBiz frameworks:
http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296
To sum up here are some of the major inconsistencies and
annoyances
in the current OFBiz framework that bug me frequently while I'm
developing:
1. XML actions are different in each widget and in the
simple-methods; they share some underlying code but there are so many
differences
2. scriptlets and expressions are a messy combination of
BeanShell,
UEL, and Groovy and keeping track of which is a pain, plus the Groovy
syntax
and capabilities are SO much better than the others so I find myself
almost
always using ${groovy:...} instead of the default, and in annoying
places
like the form.field.@use-when attribute since it is always BeanShell
I
just use a set action to prepare a boolean and then check it in the
use-when
(BeanShell is HORRIBLE compared to groovy, especially when squeezed
into XML
attributes)
3. the controller.xml file gets HUGE for larger applications,
and if
split it becomes harder to find requests and views; *Screen.xml files
also
tend to get HUGE with large numbers of screens in them; both are not
organized in the same way as the application, also generally making
things
harder to find; views/screens and requests don't define incoming
parameters
so when doing request-redirect you have to specify the parameters to
use in
a larger number of places
4. another on the topic of why so many files: service groups and
simple-methods are just XML, why not include them inline in the
service
definition (especially for smaller services), and encourage fewer
services
per file
5. loading of artifacts is not very lazy, meaning lots of unused
screens, forms, services, entities and so on that are not used are
loaded
anyway; also many artifacts are difficult to reload by cache clearing
and so
that has limited support in OFBiz; this slows things down reloading
lots of
stuff in development, and results in more resources used than needed
in
production
6. the deployment model of OFBiz is limited and the use of
static
fields for initialization makes it difficult to deploy in other ways;
there
are few init/destroy methods and object instances that would make
more
deployment models easier and more flexible; also because of this it
is
difficult to get data from other parts of the framework (for example
the
audit log stuff in the OFBiz Entity Engine uses ThreadLocal variables
to
pass userLoginId and visitId down since there is no other good way of
doing
it); in other words, the tools don't share a context
7. no API for apps; the framework is made up of an enormous
number of
classes that follow a bunch of different "patterns" (in quotes
because the
use of the term is generous) because of various people "cleaning"
things up
over time (also in quotes because the use of the term is generous),
and
there is no distinction between the API that apps are intended to use
and
the internal implementation of that API; this has the nasty side
effect of
making it difficult to find the object and method you want, AND it
makes
backward compatibility problems REALLY nasty because it gets people
believing that EVERY SINGLE object needs to ALWAYS be backward
compatible...
and that results in more and more piles of trash code lying around
over
time, and all of that code and differing patterns makes framework
changes
error-prone and unnecessarily difficult (and this is true for some of
the
app code in OFBiz too)
I should get back to work... there's a short list anyway...
The trick is how to solve these without abandoning backward
compatibility, and requiring a refactor of much of the framework and
then
based on that the updating of massive numbers of application
artifacts...
and that is just the stuff in OFBiz itself... not including
everything that
everyone else has written outside the project that they may want to
update.
And, ALL of that would have to be retested. Plus, it would take so
long to
get all of this done in a branch with huge numbers of changes while
others
are making incremental changes in the trunk making it nearly
impossible to
merge the branch into the trunk, so it would basically be a fork
anyway...
-David
Project Manager, POS? Even maybe My Portal?
Jacquees
