Use of ancient libraries in ofbiz, and release candidates

[Adam Heath-2]

Recently, I filed a bug(OFBIZ-401), to update bsf.jar to something more
modern.  This was backed out, as ofbiz makes use of an ancient jpublish
that also uses the older bsf.

Just recently, I had another case occur, with an old library.
commons-fileupload is also very old, and the current version has an api
change.

I find it very annoying that such old stuff is still in use in ofbiz,
especially if a release is pending.  Any application integrator that is
going to use ofbiz is going to want to use more modern libraries, but
will not be able to, as all the interdependent code in ofbiz is using
older stuff.

Can we make it a release goal to update the libraries to something much
more modern?  I'm willing to help produce a list, giving each library,
the version in use, the upstream location, and the most recent version.

[Si Chen-2]

I don't know about the particulars of the commons-fileupload library,  
but the problem with the bsf is that it interfered with the currently  
used jpublish.  If you can supply an upgrade combination of bsf and  
jpublish that still works, I think that should work for me (and  
hopefully the other committers as well.)  Otherwise, given how little  
the bsf library is actually used in the core ofbiz applications and  
framework, it made little sense to break existing functionality just  
to get a newer version of it.

In general the goal of updating the libraries is a good one, but in  
my opinion it has to be well-tested so that the functionality of the  
core project is not compromised.

On Nov 1, 2006, at 12:52 PM, Adam Heath wrote:

> Recently, I filed a bug(OFBIZ-401), to update bsf.jar to something  
> more
> modern.  This was backed out, as ofbiz makes use of an ancient  
> jpublish
> that also uses the older bsf.
>
> Just recently, I had another case occur, with an old library.
> commons-fileupload is also very old, and the current version has an  
> api
> change.
>
> I find it very annoying that such old stuff is still in use in ofbiz,
> especially if a release is pending.  Any application integrator  
> that is
> going to use ofbiz is going to want to use more modern libraries, but
> will not be able to, as all the interdependent code in ofbiz is using
> older stuff.
>
> Can we make it a release goal to update the libraries to something  
> much
> more modern?  I'm willing to help produce a list, giving each library,
> the version in use, the upstream location, and the most recent  
> version.

Best Regards,

Si
[hidden email]

[BJ Freeman]

I actually had to compile the org.apache.bsf from apache SVN to get the
latest SVN to compile.
had to replace the import com.ibm.bsf with the import org.apache.bsf

Adam Heath sent the following on 11/1/2006 12:52 PM:

> Recently, I filed a bug(OFBIZ-401), to update bsf.jar to something more
> modern.  This was backed out, as ofbiz makes use of an ancient jpublish
> that also uses the older bsf.
>
> Just recently, I had another case occur, with an old library.
> commons-fileupload is also very old, and the current version has an api
> change.
>
> I find it very annoying that such old stuff is still in use in ofbiz,
> especially if a release is pending.  Any application integrator that is
> going to use ofbiz is going to want to use more modern libraries, but
> will not be able to, as all the interdependent code in ofbiz is using
> older stuff.
>
> Can we make it a release goal to update the libraries to something much
> more modern?  I'm willing to help produce a list, giving each library,
> the version in use, the upstream location, and the most recent version.
>

[Adam Heath-2]

Si Chen wrote:
> I don't know about the particulars of the commons-fileupload library,
> but the problem with the bsf is that it interfered with the currently
> used jpublish.  If you can supply an upgrade combination of bsf and
> jpublish that still works, I think that should work for me (and
> hopefully the other committers as well.)  Otherwise, given how little
> the bsf library is actually used in the core ofbiz applications and
> framework, it made little sense to break existing functionality just to
> get a newer version of it.

Yes, well, there is a patch from someone else from 2004(see the bug)
that fixes that.  And that patch was never applied.

It's all well and good to provide patches, but if they never get applied
by those in charge, it makes those that provide said patches reluctant
to provide more in the future.

> In general the goal of updating the libraries is a good one, but in my
> opinion it has to be well-tested so that the functionality of the core
> project is not compromised.

So, instead of going forward, fixing jpublish, you'd rather stay back?
Why does one person have to do all the work at fixing something?

[Si Chen-2]

Adam,

If there were some older patches that got missed two years ago, maybe  
it's good to submit them again.  We do have more committers back then.

As to the general question of why patches don't get applied "by those  
in charge," obviously we could all work harder for the good of the  
project.  However, please don't underestimate the amount of time that  
it takes committers to review patches and test them.  If you or  
anybody feels that your patches are ignored, please try to make it  
more clear (a) what your patch does--send in screenshots, describe  
how it works, etc. and (b) above all, write good, clean code that can  
just go in right away.  There are patches in jira which are  
themselves buggy, difficult to understand, formatted incorrectly,  or  
just don't even patch.  Also, it helps if you contribute on a  
somewhat regular basis so that your patches are coming from a  
"trusted" source.

Last of all, it's not a matter of one person having to do all the  
work at fixing something.  The fact is, we're all working here all  
the time to help make it better.  However, it's not a good practice  
to put half-finished things in the project, or break one feature to  
make another work.  That just creates more problems for everybody.  
One of the stated policies for us the committers, in fact, is not to  
commit things until they're reasonably complete and functional--and  
we could all do better at it.

On Nov 1, 2006, at 2:00 PM, Adam Heath wrote:

> Si Chen wrote:
>> I don't know about the particulars of the commons-fileupload library,
>> but the problem with the bsf is that it interfered with the currently
>> used jpublish.  If you can supply an upgrade combination of bsf and
>> jpublish that still works, I think that should work for me (and
>> hopefully the other committers as well.)  Otherwise, given how little
>> the bsf library is actually used in the core ofbiz applications and
>> framework, it made little sense to break existing functionality  
>> just to
>> get a newer version of it.
>
> Yes, well, there is a patch from someone else from 2004(see the bug)
> that fixes that.  And that patch was never applied.
>
> It's all well and good to provide patches, but if they never get  
> applied
> by those in charge, it makes those that provide said patches reluctant
> to provide more in the future.
>
>> In general the goal of updating the libraries is a good one, but  
>> in my
>> opinion it has to be well-tested so that the functionality of the  
>> core
>> project is not compromised.
>
> So, instead of going forward, fixing jpublish, you'd rather stay back?
> Why does one person have to do all the work at fixing something?

Best Regards,

Si
[hidden email]

[Adrian Crum]

Si,

Adam was a big contributor before you came along. At the time he was considered
a "trusted" source.


Si Chen wrote:

> Adam,
>
> If there were some older patches that got missed two years ago, maybe  
> it's good to submit them again.  We do have more committers back then.
>
> As to the general question of why patches don't get applied "by those  
> in charge," obviously we could all work harder for the good of the  
> project.  However, please don't underestimate the amount of time that  
> it takes committers to review patches and test them.  If you or  anybody
> feels that your patches are ignored, please try to make it  more clear
> (a) what your patch does--send in screenshots, describe  how it works,
> etc. and (b) above all, write good, clean code that can  just go in
> right away.  There are patches in jira which are  themselves buggy,
> difficult to understand, formatted incorrectly,  or  just don't even
> patch.  Also, it helps if you contribute on a  somewhat regular basis so
> that your patches are coming from a  "trusted" source.
>
> Last of all, it's not a matter of one person having to do all the  work
> at fixing something.  The fact is, we're all working here all  the time
> to help make it better.  However, it's not a good practice  to put
> half-finished things in the project, or break one feature to  make
> another work.  That just creates more problems for everybody.   One of
> the stated policies for us the committers, in fact, is not to  commit
> things until they're reasonably complete and functional--and  we could
> all do better at it.
>
> On Nov 1, 2006, at 2:00 PM, Adam Heath wrote:
>
>> Si Chen wrote:
>>
>>> I don't know about the particulars of the commons-fileupload library,
>>> but the problem with the bsf is that it interfered with the currently
>>> used jpublish.  If you can supply an upgrade combination of bsf and
>>> jpublish that still works, I think that should work for me (and
>>> hopefully the other committers as well.)  Otherwise, given how little
>>> the bsf library is actually used in the core ofbiz applications and
>>> framework, it made little sense to break existing functionality  just to
>>> get a newer version of it.
>>
>>
>> Yes, well, there is a patch from someone else from 2004(see the bug)
>> that fixes that.  And that patch was never applied.
>>
>> It's all well and good to provide patches, but if they never get  applied
>> by those in charge, it makes those that provide said patches reluctant
>> to provide more in the future.
>>
>>> In general the goal of updating the libraries is a good one, but  in my
>>> opinion it has to be well-tested so that the functionality of the  core
>>> project is not compromised.
>>
>>
>> So, instead of going forward, fixing jpublish, you'd rather stay back?
>> Why does one person have to do all the work at fixing something?
>
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>
>

[Si Chen-2]

I wasn't suggesting that he was not, and I am aware that he was a  
contributor before.  As this is a public list, I was hoping to  
explain why (at least from my perspective) sometimes patches aren't  
applied.

On Nov 1, 2006, at 2:48 PM, Adrian Crum wrote:

> Si,
>
> Adam was a big contributor before you came along. At the time he  
> was considered a "trusted" source.
>
>
> Si Chen wrote:
>
>> Adam,
>> If there were some older patches that got missed two years ago,  
>> maybe  it's good to submit them again.  We do have more committers  
>> back then.
>> As to the general question of why patches don't get applied "by  
>> those  in charge," obviously we could all work harder for the good  
>> of the  project.  However, please don't underestimate the amount  
>> of time that  it takes committers to review patches and test  
>> them.  If you or  anybody feels that your patches are ignored,  
>> please try to make it  more clear (a) what your patch does--send  
>> in screenshots, describe  how it works, etc. and (b) above all,  
>> write good, clean code that can  just go in right away.  There are  
>> patches in jira which are  themselves buggy, difficult to  
>> understand, formatted incorrectly,  or  just don't even patch.  
>> Also, it helps if you contribute on a  somewhat regular basis so  
>> that your patches are coming from a  "trusted" source.
>> Last of all, it's not a matter of one person having to do all the  
>> work at fixing something.  The fact is, we're all working here  
>> all  the time to help make it better.  However, it's not a good  
>> practice  to put half-finished things in the project, or break one  
>> feature to  make another work.  That just creates more problems  
>> for everybody.   One of the stated policies for us the committers,  
>> in fact, is not to  commit things until they're reasonably  
>> complete and functional--and  we could all do better at it.
>> On Nov 1, 2006, at 2:00 PM, Adam Heath wrote:
>>> Si Chen wrote:
>>>
>>>> I don't know about the particulars of the commons-fileupload  
>>>> library,
>>>> but the problem with the bsf is that it interfered with the  
>>>> currently
>>>> used jpublish.  If you can supply an upgrade combination of bsf and
>>>> jpublish that still works, I think that should work for me (and
>>>> hopefully the other committers as well.)  Otherwise, given how  
>>>> little
>>>> the bsf library is actually used in the core ofbiz applications and
>>>> framework, it made little sense to break existing functionality  
>>>> just to
>>>> get a newer version of it.
>>>
>>>
>>> Yes, well, there is a patch from someone else from 2004(see the bug)
>>> that fixes that.  And that patch was never applied.
>>>
>>> It's all well and good to provide patches, but if they never get  
>>> applied
>>> by those in charge, it makes those that provide said patches  
>>> reluctant
>>> to provide more in the future.
>>>
>>>> In general the goal of updating the libraries is a good one,  
>>>> but  in my
>>>> opinion it has to be well-tested so that the functionality of  
>>>> the  core
>>>> project is not compromised.
>>>
>>>
>>> So, instead of going forward, fixing jpublish, you'd rather stay  
>>> back?
>>> Why does one person have to do all the work at fixing something?
>> Best Regards,
>> Si
>> [hidden email]

Best Regards,

Si
[hidden email]

[David E Jones-2]

On Nov 1, 2006, at 3:00 PM, Adam Heath wrote:

> Si Chen wrote:
>> I don't know about the particulars of the commons-fileupload library,
>> but the problem with the bsf is that it interfered with the currently
>> used jpublish.  If you can supply an upgrade combination of bsf and
>> jpublish that still works, I think that should work for me (and
>> hopefully the other committers as well.)  Otherwise, given how little
>> the bsf library is actually used in the core ofbiz applications and
>> framework, it made little sense to break existing functionality  
>> just to
>> get a newer version of it.
>
> Yes, well, there is a patch from someone else from 2004(see the bug)
> that fixes that.  And that patch was never applied.
>
> It's all well and good to provide patches, but if they never get  
> applied
> by those in charge, it makes those that provide said patches reluctant
> to provide more in the future.

There is no "you" and "us". OFBiz is a community driven project, so  
there is only an "us". If you want something done about this sort of  
problem, and it's certain a problem, then you can help. In fact there  
are lots of ways you or anyone can help:

1. pay committers to review and commit patches; there is no conflict  
of interest or anything wrong with this and while it's not required  
to get a patch in, OFBiz is NOT A SPONSORED PROJECT, meaning no  
committers are paid for anything they do with the project, unless a  
client pays them for it

2. start getting involved more with OFBiz and become a committer,  
this way you can help solve this problem not only for yourself, but  
for everyone else as well

3. review patches that others submit to see if they cause any  
problems or need changes before they can be committed; this is a  
_HUGE_ problem as the majority of the patches coming in have  
problems, and sometimes (like your OFBIZ-401 patch) they cause big  
problems that break lots of stuff and don't improve anything material  
or immediate

>> In general the goal of updating the libraries is a good one, but  
>> in my
>> opinion it has to be well-tested so that the functionality of the  
>> core
>> project is not compromised.
>
> So, instead of going forward, fixing jpublish, you'd rather stay back?
> Why does one person have to do all the work at fixing something?

What's this one person stuff? I think you need a vacation or  
something to help adjust your attitude. Did you read all of the posts  
about this issue on the mailing lists? Various side effects of the  
patch were identified and a plan was laid out with a list of specific  
things that needed to be done in order to move forward with it. One  
person? Who was that one person? If anyone on this issue so far it  
has been Jacopo.

-David

[David E Jones-2]

On Nov 1, 2006, at 3:48 PM, Adrian Crum wrote:

> Si,
>
> Adam was a big contributor before you came along. At the time he  
> was considered a "trusted" source.

Yes and no. From where I'm sitting I'd say Si has done and continues  
to do far more for OFBiz and every user of OFBiz than Adam or anyone  
else aside from a small handful of people.

Adam has contributed some great stuff. We have him to thank for most  
of the great caching stuff that is in the Entity Engine right now. I  
personally also have him to thank for dozens of hours debugging and  
fixing that stuff... so "trusted" may be going a little far. Adam is  
certainly a contributor and has contributed great things, and I don't  
think anyone can dispute that, but apples are apples and oranges are  
oranges.

-David

> Si Chen wrote:
>
>> Adam,
>> If there were some older patches that got missed two years ago,  
>> maybe  it's good to submit them again.  We do have more committers  
>> back then.
>> As to the general question of why patches don't get applied "by  
>> those  in charge," obviously we could all work harder for the good  
>> of the  project.  However, please don't underestimate the amount  
>> of time that  it takes committers to review patches and test  
>> them.  If you or  anybody feels that your patches are ignored,  
>> please try to make it  more clear (a) what your patch does--send  
>> in screenshots, describe  how it works, etc. and (b) above all,  
>> write good, clean code that can  just go in right away.  There are  
>> patches in jira which are  themselves buggy, difficult to  
>> understand, formatted incorrectly,  or  just don't even patch.  
>> Also, it helps if you contribute on a  somewhat regular basis so  
>> that your patches are coming from a  "trusted" source.
>> Last of all, it's not a matter of one person having to do all the  
>> work at fixing something.  The fact is, we're all working here  
>> all  the time to help make it better.  However, it's not a good  
>> practice  to put half-finished things in the project, or break one  
>> feature to  make another work.  That just creates more problems  
>> for everybody.   One of the stated policies for us the committers,  
>> in fact, is not to  commit things until they're reasonably  
>> complete and functional--and  we could all do better at it.
>> On Nov 1, 2006, at 2:00 PM, Adam Heath wrote:
>>> Si Chen wrote:
>>>
>>>> I don't know about the particulars of the commons-fileupload  
>>>> library,
>>>> but the problem with the bsf is that it interfered with the  
>>>> currently
>>>> used jpublish.  If you can supply an upgrade combination of bsf and
>>>> jpublish that still works, I think that should work for me (and
>>>> hopefully the other committers as well.)  Otherwise, given how  
>>>> little
>>>> the bsf library is actually used in the core ofbiz applications and
>>>> framework, it made little sense to break existing functionality  
>>>> just to
>>>> get a newer version of it.
>>>
>>>
>>> Yes, well, there is a patch from someone else from 2004(see the bug)
>>> that fixes that.  And that patch was never applied.
>>>
>>> It's all well and good to provide patches, but if they never get  
>>> applied
>>> by those in charge, it makes those that provide said patches  
>>> reluctant
>>> to provide more in the future.
>>>
>>>> In general the goal of updating the libraries is a good one,  
>>>> but  in my
>>>> opinion it has to be well-tested so that the functionality of  
>>>> the  core
>>>> project is not compromised.
>>>
>>>
>>> So, instead of going forward, fixing jpublish, you'd rather stay  
>>> back?
>>> Why does one person have to do all the work at fixing something?
>> Best Regards,
>> Si
>> [hidden email]

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>

> Si Chen wrote:
> > I don't know about the particulars of the commons-fileupload library,
> > but the problem with the bsf is that it interfered with the currently
> > used jpublish.  If you can supply an upgrade combination of bsf and
> > jpublish that still works, I think that should work for me (and
> > hopefully the other committers as well.)  Otherwise, given how little
> > the bsf library is actually used in the core ofbiz applications and
> > framework, it made little sense to break existing functionality just to
> > get a newer version of it.
>
> Yes, well, there is a patch from someone else from 2004(see the bug)
> that fixes that.  And that patch was never applied.
>
> It's all well and good to provide patches, but if they never get applied
> by those in charge, it makes those that provide said patches reluctant
> to provide more in the future.

Adam,

I'm the one that commited the bsf patch and finally reverted it back.
If you were aware of a problem and knew that a patch existed why did not you submitted this patch or simply tell about it ?
Of course I may have figured it out myself and use the new JPublish library with your patch when I realised the problem origin.
But the reason we choose not to go further is that we expect soon not to use JPublish anymore.
And also because there are hotter topics around.

In the future don't hesitate to submit new patches. Be sure I will be happy to review and commit them.
It's always a pleasure to work with people having a good knowledge of OFBiz and its history.

Thanks to share this knowledge

Jacques

[cjhowe]

As I have been guilty of needing a jab in the ribs
like this in the past...That's enough bickering.

Amongst the attitude/responsibility checking that has
gone on in this thread there are only two questions
that require responses.

1) Can we/is it necessary to determine a better plan
of action for updating/purging stale 3rd party
libraries?

2) What are the obstacles in attracting more
patches/improvements and how can we get more
non-commiter involvement in JIRA reviews?

To the first question, my proposed solution would be
to put a little effort into the example component for
the various ways of accomplishing tasks with the
tools/hooks available in OFBiz along with status
notes.  Followed up by adopting OFBiz technology
standards and then limiting  OFBiz solutions using
those technologies in the community project (ie
possibly eliminating the usage of beanshell scripts
entirely in favor of minilang).  What this
accomplishes is reducing the number of 3rd party
libraries that are show stoppers to maintain,
especially considering this thread is based on two
technologies that OFBiz has preferred approaches for.

I'd like to hear other's opinions for the second.

[Jacopo Cappellato]

Hi Adam,

Adam Heath wrote:
> ...
> Can we make it a release goal to update the libraries to something much
> more modern?  I'm willing to help produce a list, giving each library,
> the version in use, the upstream location, and the most recent version.

this information will be indeed useful; the best thing to do, if you
want to help, is to complete the information available in this page:

http://docs.ofbiz.org/display/OFBADMIN/Libraries+Included+in+OFBiz

You can add comments to that page and then we will take care of
integrating it in the page itself.

Jacopo

[Jacopo Cappellato]

Chris,

your post is interesting:

Chris Howe wrote:
> ...
> 2) What are the obstacles in attracting more
> patches/improvements and how can we get more
> non-commiter involvement in JIRA reviews?
>

The number of patches and contributors is slowly growing every day and
this is a great thing.
However it's true that the committer/non-commiter involvement in JIRA
reviews is low and usually the only person that reviews/comments on it
is the committer to which the issue is assigned.
And this is a problem and I think that there is something we could do to
improve this.

For everyone: there are many ways to review a patch:

a) open it with a text editor to study it; this is not a reliable way of
reviewing a patch but it is very quick and can be very useful to
understand if the patch is formally correct (e.g. doesn't contain
absolute filepaths), if the formatting/coding standards are accurate
(e.g. it doesn't contain tabs), if there are license issues (for
example, are all the license headers in place?) and also to discover
possible issues with it

b) ask questions to the author of the patch (adding a comment to the
Jira issue) to get more information, if you need it

c) apply the patch and verify if the system builds and runs correctly
(ant clean, ant build) with no new warnings or error messages in the log
files; if xml files have been updated, check the syntax agains their xsd
files using an xml parser

d) test the patch by reproducing the use case scenario

In my opinion, even if a guy doesn't have time (or knowledge) to deeply
test a patch (from #a to #d), he/she could at least help with #a and
#b... then he/she should post a comment to the issue with his/her
opinion, for example:

"I don't have time to apply the patch, however, after a quick review it
seems formally correct, except for some formatting issues (tabs instead
of spaces) in the class ExampleClass; here is a new patch that fixes this."

And the committers, that have the power of veto, *should* ideally
comment every issue, even the ones for areas they don't know well, even
just to state that they don't have time to comment, so that the other
committers can get a better understanding of the feeling of the group;
for an example of this, a few minutes ago I've added a comment to the
following issue:

http://issues.apache.org/jira/browse/OFBIZ-405#action_12446546

Another example could be:

"No time to review this patch, I fear that there could be some problems
with promotions; please test carefully before committing."

Jacopo

[davidnwelton]

> For everyone: there are many ways to review a patch:

> c) apply the patch and verify if the system builds and runs correctly
> (ant clean, ant build) with no new warnings or error messages in the log
> files; if xml files have been updated, check the syntax agains their xsd
> files using an xml parser
>
> d) test the patch by reproducing the use case scenario

This is another thing that automated testing helps with tremendously.
It gives you confidence that you can modify things and be relatively
sure of generating a warning if you've inadvertently broken something.

--
David N. Welton
 - http://www.dedasys.com/davidw/

Linux, Open Source Consulting
 - http://www.dedasys.com/

[Adam Heath-2]

David E Jones wrote:

>
> On Nov 1, 2006, at 3:48 PM, Adrian Crum wrote:
>
>> Si,
>>
>> Adam was a big contributor before you came along. At the time he was
>> considered a "trusted" source.
>
> Yes and no. From where I'm sitting I'd say Si has done and continues to
> do far more for OFBiz and every user of OFBiz than Adam or anyone else
> aside from a small handful of people.
>
> Adam has contributed some great stuff. We have him to thank for most of
> the great caching stuff that is in the Entity Engine right now. I
> personally also have him to thank for dozens of hours debugging and
> fixing that stuff... so "trusted" may be going a little far. Adam is
> certainly a contributor and has contributed great things, and I don't
> think anyone can dispute that, but apples are apples and oranges are
> oranges.

It's hard to compare any one person to any other one person.  I've been
much more active in the past, that as of late.  I tend to just wake up
once in a blue moon, and send stuff off.

However, I really don't have a firm grasp on the entirety of the ofbiz
application suite.  The entity engine, I pretty much know inside and
out(and wait 'til you see my next thing(end of month more than likely)).
 But the application code is not something I really know.  And, there's
a *lot* more application code than any low-level base stuff.

[Adam Heath-2]

Si Chen wrote:
> Adam,
>
> If there were some older patches that got missed two years ago, maybe
> it's good to submit them again.  We do have more committers back then.

My general feeling from a bit ago, was that patches tended to languish,
and not get applied.  Once instance, I filed a bug during the 2005 users
conference, that fixed an off-by-one bug in the ofbiz-home resolver.  An
obvious one-line fix, that sat around for ages.  When simple things tend
to get ignored, it makes one less likely to try and push more complex
changes.

I have noticed a change in that recently, however.

> As to the general question of why patches don't get applied "by those in
> charge," obviously we could all work harder for the good of the
> project.  However, please don't underestimate the amount of time that it
> takes committers to review patches and test them.  If you or anybody
> feels that your patches are ignored, please try to make it more clear
> (a) what your patch does--send in screenshots, describe how it works,
> etc. and (b) above all, write good, clean code that can just go in right
> away.  There are patches in jira which are themselves buggy, difficult
> to understand, formatted incorrectly,  or just don't even patch.  Also,
> it helps if you contribute on a somewhat regular basis so that your
> patches are coming from a "trusted" source.

What kind of automated testing is there?  What are the procedures that
committers do?  It'd be nice to get this documented, so that those
willing to help can try to do more of the work themselves.  Pushing
things out to the leaves can reduce strain on those in the center.

Of course, writing this documentation itself takes time.  Unfortunately,
this often turns into a catch-22.  Those at the upper levels are so busy
doing work, that they have no time to write documentation or train
others so that more can be delegated.  It happens all the time in
debian, and can be very frustrating for all involved.

> Last of all, it's not a matter of one person having to do all the work
> at fixing something.  The fact is, we're all working here all the time
> to help make it better.  However, it's not a good practice to put
> half-finished things in the project, or break one feature to make
> another work.  That just creates more problems for everybody.  One of
> the stated policies for us the committers, in fact, is not to commit
> things until they're reasonably complete and functional--and we could
> all do better at it.

As for the one person, it seems those in this thread are feeling like I
was attacking, or singling people out.  That was not my intention.  If
people read it that way, then it was my fault for allowing such an
interpretation to occur.

I will admit that I only did a compile test, and a search/replace on the
package names(for this particular bug(401)).  That was plain oversite on
my part.  Internally, we don't use jpublish, nor the screen widget, for
our own applications, so this generally isn't a problem for us.

I will be revisiting this bsf issue, and getting jpublish to work, as I
really think this patch needs to be in rather soon.

>
> On Nov 1, 2006, at 2:00 PM, Adam Heath wrote:
>
>> Si Chen wrote:
>>> I don't know about the particulars of the commons-fileupload library,
>>> but the problem with the bsf is that it interfered with the currently
>>> used jpublish.  If you can supply an upgrade combination of bsf and
>>> jpublish that still works, I think that should work for me (and
>>> hopefully the other committers as well.)  Otherwise, given how little
>>> the bsf library is actually used in the core ofbiz applications and
>>> framework, it made little sense to break existing functionality just to
>>> get a newer version of it.
>>
>> Yes, well, there is a patch from someone else from 2004(see the bug)
>> that fixes that.  And that patch was never applied.
>>
>> It's all well and good to provide patches, but if they never get applied
>> by those in charge, it makes those that provide said patches reluctant
>> to provide more in the future.
>>
>>> In general the goal of updating the libraries is a good one, but in my
>>> opinion it has to be well-tested so that the functionality of the core
>>> project is not compromised.
>>
>> So, instead of going forward, fixing jpublish, you'd rather stay back?
>> Why does one person have to do all the work at fixing something?
>
> Best Regards,
>
> Si
> [hidden email]
>
>
>
>

[Adam Heath-2]

Jacques Le Roux wrote:
> I'm the one that commited the bsf patch and finally reverted it back.
> If you were aware of a problem and knew that a patch existed why did
> not you submitted this patch or simply tell about it ?  Of course I may
> have figured it out myself and use the new JPublish library with your
> patch when I realised the problem origin. But the reason we choose not
> to go further is that we expect soon not to use JPublish anymore. And
> also because there are hotter topics around.

I was not aware of that older patch when I sent the new one.  Even tho I
had sent an email in that old thread, I had forgotten all about it.

What is the time-frame on removing jpublish?  A week?  Then I can wait.
 If a month, then no, I'll get the entire change finished, and send it
all in.

Unfortunately, I *must* get jpublish working with a new bsf, for our
internal work.  We've committed to the new bsf, and for time sakes, I am
using the patch internally.  I wasn't aware of the jpublish issue until
this bug was commented on, so now I am forced to fix this for our own
clients.

[Jacques Le Roux]

Hi Adam,

I can't answer accuratly because I have no time to put on this now. However I may help a bit if needed.
You have certainly view the last message about JPublish by David else here it is attached.

Jacques

From: "Adam Heath" <[hidden email]>
> What is the time-frame on removing jpublish?  A week?  Then I can wait.
>  If a month, then no, I'll get the entire change finished, and send it
> all in.
> Unfortunately, I *must* get jpublish working with a new bsf, for our
> internal work.  We've committed to the new bsf, and for time sakes, I am
> using the patch internally.  I wasn't aware of the jpublish issue until
> this bug was commented on, so now I am forced to fix this for our own
> clients.


On Nov 8, 2006, at 1:11 AM, [hidden email] wrote:

> Author: jacopoc
> Date: Wed Nov  8 00:11:41 2006
> New Revision: 472420
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=472420
> Log:
> One more content screen converted to widgets.
> Now there are just 10 remaining JPublish screens (all in the layout/
> template menu)... I've tried to work on them but I'm giving up  
> since they seem too broken/incomplete/dirty and I'm too ignorant  
> about them to try to understand how they work from the source code:
> maybe someone out there that knows better than me that pages (and  
> their statsus) could help with this, at least with a few suggestions.
> It would be really great to finalize this effort because these  
> JPublish pages are the LAST 10 ones that we have in OFBiz.

I'd say for stuff that is now broken (and I know there is a fair bit  
of it...) to just do a quick and dirty pass at changing the JPublish  
XML files into screen definitions (ie moving to set operations, etc)  
and then if they aren't working just don't worry about it. Hopefully  
at some point someone will actually need/want these and will go  
through that work. If that never does happen, chances are something  
else will be designed to replace them and we'll just toss them.

So yes, for now I'd say just do the minimum needed to get the  
JPublish stuff removed without losing too much of what is there.  
Heck, even putting the content of the JPublish pagedef XML file in a  
comment in the actions block of the new screen definitions would be  
okay by me...

-David