Cool - thanks.
I agree there are a lot of things that can be changed that will improve the
project greatly - but at the same time those changes will break backward
compatibility. I'm sure many of the developers have lists like David's that
contain things they would like to change, but they are hesitant to do so
because it might break backward compatibility.
Before this thread gets inundated with developer's wish lists, I would like to
suggest that we address one single simple issue first:
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? David suggested major revisions. Is that reasonable? Any other
ideas?
I'm asking end users - not committers or PMC members (we've already had this
discussion).
My experience with the developer community has convinced me that they are open
to the opinions and suggestions of end users. So let's discuss, debate, reach
an agreement, and move forward from there.
-Adrian
--- On Thu, 1/20/11, David E Jones <d...@me.com> wrote:
> On Jan 20, 2011, at 9:02 PM, Adrian Crum wrote:
>
> > --- On Thu, 1/20/11, David E Jones <d...@me.com>
> wrote:
> >> What the project needs is cutoff points at major
> revision
> >> releases after which attempts at backward
> compatibility are
> >> totally abandoned in favor of making something
> better.
> >
> > Why don't we discuss that further? Perhaps in a new
> thread?
>
> Okay, here's the new thread.
>
> To kick it off there are probably lots of facets of this to
> discuss, but the biggest question (IMO) is: what will we get
> rid of? Another way of looking at that is: how will we
> decide what to get rid of?
>
> This gets even trickier as time goes on and new things are
> introduced that are alternatives to old things. One example
> is the FTL macro based widget renderers... the old ones can
> go away. Another would by the Query Builder that Scott was
> working on (OFBIZ-4053), and that could result in getting
> rid of a bunch of stuff in the Delegator and
> GenericDelegator. There are also hundreds of methods that
> simply the same as another method in the same class but with
> fewer arguments and defaults for the missing arguments, and
> tons of those can and should go away (many are there for
> backward compatibility only).
>
> But is any of this really doable in OFBiz given desires and
> priorities of the community?
>
> Heck, we have complaints about EVERYTHING. Constant
> complaints about every little change. If all of the
> delegator.find* methods are suddenly gone... just imagine
> the complaints (well, not to mention the refactoring of code
> in OFBiz itself!).
>
> We have complaints about formatting changes in code. We
> have complaints about any and all refactoring changes
> (moving code, renaming, splitting up or combining methods or
> classes).
>
> What about getting rid of the dozens of totally useless
> util classes in OFBiz? Most of them could (and maybe should)
> be tossed in favor of other open source stuff, or even
> better in favor of new features in Java or that are handled
> inherently in Groovy or other tools used a lot in OFBiz.
>
> How about making things more consistent in OFBiz by using
> groovy for all expressions and such? We could get rid of the
> BSH defaults, the UEL stuff, and so on. Yeah, I know a lot
> of work has gone into these things... but consider the state
> of things now and the pain involved in using some of these
> cumbersome tools.
>
> Of course, is this even doable... and worth it? Could we
> even retest all of the code that would be affected by these
> lower level changes? Could we do this without huge efforts
> in branches? Because the framework and applications are tied
> together we can't easily advance the framework freely and
> then once we like it do a feature freeze and start getting
> the applications/etc to catch up.
>
> Stepping back I guess the real question is: can we even do
> these sorts of things at this point in the life of the
> project?
>
> The jQuery branch is an interesting example. I think that
> worked because it was a change with relatively few touch
> points, and only a couple of people were interested in it so
> everyone else left them alone while they worked on it. But
> what about bigger changes that result in a need for changes
> in thousands of lines of existing code?
>
> -David
>
>
>
