jpublish.jar
Locked
12
12
jpublish.jar
 
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
I see no reason to maintain the jpublish code in OFBiz. Due to the fact
all future components and enhancements to existing components will all be widget based. If the core OFBiz no longer depends on JPublish, then I see no reason to maintain the old code. On the flip side, older versions of OFBiz which are not being updated to use the current version will continue to include the JPublish component and should have no effect on these projects. All new contributions to OFBiz should follow the widget pattern, as such I see no point in maintaining the old JPublish handlers. I don't like the idea of new contributions following older patterns. IMO, the code (ajax) should be converted to use JSON request handler pattern. I assume that since JPublish was used, this was intended to follow the XML method for responses. Maybe we should open up more discussion regarding new patterns. I see a number of AJAX being implemented in the near future and my biggest fear is that all of these will be following different patterns. We need to set a standard and follow it through the code base. Andrew David E Jones wrote: > > From a project perspective a branch seems like a lot of overhead for > this. Are you saying that you want to maintain such a branch? This would > include regular merges, etc. > > The Screen Widget has been around for over 2 years, and JPublish hasn't > been maintained in at least that much time. Perhaps it's time to > recommend that everyone stop using it? > > Part of the trouble is that there are other things that JPublish depends > on that we'll want to update or change, and any of those (like bsf) that > get in the way of updating other things will just branch out to a big > old problem... > > -David > > > On Dec 13, 2006, at 3:16 PM, Si Chen wrote: > >> How about we make a branch called "newbsf"? We can put all the changes >> for the new bsf jars there, and if Adam ever shows up with a new >> jpublish then we can merge it back in? >> >> On Dec 13, 2006, at 2:11 PM, David E Jones wrote: >> >>> >>> I am not opposed to this. >>> >>> It would have been nice if this had come up as an approach during >>> earlier and ongoing discussions as quite a few changes have now been >>> made to exclude JPublish (it would have to be put back into the >>> NOTICE/LICENSE files, the Libraries Included in OFBiz page, removed >>> from the OPTIONAL_LIBRARIES and change build files, code, etc. >>> >>> We would also need to keep a repository or at least a patch and >>> how-to somewhere so the jar file could be reproduced. >>> >>> -David >>> >>> >>> On Dec 13, 2006, at 2:13 PM, Si Chen wrote: >>> >>>> David, >>>> >>>> We and some other people we work with all have OFBIZ-based >>>> applications from the ofbiz 3.x days which are jpublish-based, so to >>>> remove jpublish from the SVN and put in something which is >>>> incompatible with it basically breaks all of our applications and >>>> forces us to start to diverge from the core ofbiz code base in a way >>>> that we don't want to. >>>> >>>> I know what you mean about jpublish being not actively maintained, >>>> but the flipside it seems just to work ok for us, so we don't need >>>> to do too much for it. >>>> >>>> I guess if we can coordinate with Adam Heath to get a new >>>> bsf-compatible jpublish in the SVN then everything will be fine. >>>> Until then, are you planning to do something with the new bsf >>>> modules? Could it wait until Adam finds it in his kindness to send >>>> us an updated jpublish that he keeps promising? >>>> >>>> On Dec 13, 2006, at 12:13 PM, David E Jones wrote: >>>> >>>>> >>>>> Do we really want to do this? Part of the reason we wanted to >>>>> remove JPublish is that there doesn't seem to be much a community >>>>> around it and no one is maintaining it. >>>>> >>>>> In other words, if we want it in OFBiz, we have to maintain it... >>>>> Unless it is really useful for something, I have a big problem with >>>>> that... >>>>> >>>>> So, I guess in order to decide it would be good to know what you're >>>>> planning on (or have done) with JPublish that wouldn't work with >>>>> other things... and then see if that justifies maintaining JPublish. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Dec 13, 2006, at 10:48 AM, Si Chen wrote: >>>>> >>>>>> When do you think you can send this in? >>>>>> >>>>>> On Dec 13, 2006, at 9:42 AM, Adam Heath wrote: >>>>>> >>>>>>> Si Chen wrote: >>>>>>>> David, >>>>>>>> >>>>>>>> I see that you've removed jpublish so that the newer versions of >>>>>>>> bsf can >>>>>>>> be integrated. What can we do to put jpublish back into the main >>>>>>>> repository? Is there a newer version of jpublish which would >>>>>>>> work well >>>>>>>> with the newer bsf stuff? We have a lot of things which require >>>>>>>> jpublish, including some ajax-related stuff we were going to >>>>>>>> contribute >>>>>>>> back. >>>>>>> >>>>>>> I've got a fixed jpublish I need to send in. I downloaded the >>>>>>> version >>>>>>> that ofbiz is using, and did the s/com.ibm.bsf/org.apache.bsf/ fix. >>>>>>> Seems to work locally. >>>>>>> >>>>>>> Just been so busy. >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Si >>>>>> [hidden email] >>>>>> >>>>>> >>>>>> >>>> >>>> Best Regards, >>>> >>>> Si >>>> [hidden email] >>>> >>>> >>>> >> >> Best Regards, >> >> Si >> [hidden email] >> >> >> > |
smime.p7s (4K)
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
What do we have which depends on BSF? I see no reason not to keep the
older code available [in an optional or specialized area] until everyone can migrate off of it. However, we need to restrict new contributions. If people are developing off JPublish, I don't think we want to accept the contribution until it is migrated to screen widgets. We don't want to introduce old patterns back into the code base now that we finally have all this migrated. Andrew Si Chen wrote: > David, Andy - > > I agree completely on having standards for the code. > > It's not a matter of putting new jpublish code into OFBIZ but just a > matter of giving people backward compatibility so they can stay with the > project and, as a result, hopefully continue to contribute to it. > > As a pragmatic solution, how about we try Chris Howe's suggestion to use > bsf-2.2 instead of -2.4, so we can just either keep jpublish.jar in the > project or at least keep it compatible with OFBIZ? > > On Dec 13, 2006, at 3:26 PM, A. Zeneski wrote: > >> I see no reason to maintain the jpublish code in OFBiz. Due to the fact >> all future components and enhancements to existing components will all >> be widget based. >> >> If the core OFBiz no longer depends on JPublish, then I see no reason to >> maintain the old code. >> >> On the flip side, older versions of OFBiz which are not being updated to >> use the current version will continue to include the JPublish component >> and should have no effect on these projects. >> >> All new contributions to OFBiz should follow the widget pattern, as such >> I see no point in maintaining the old JPublish handlers. >> >> I don't like the idea of new contributions following older patterns. >> IMO, the code (ajax) should be converted to use JSON request handler >> pattern. I assume that since JPublish was used, this was intended to >> follow the XML method for responses. >> >> Maybe we should open up more discussion regarding new patterns. I see a >> number of AJAX being implemented in the near future and my biggest fear >> is that all of these will be following different patterns. >> >> We need to set a standard and follow it through the code base. >> >> Andrew >> >> David E Jones wrote: >>> >>> From a project perspective a branch seems like a lot of overhead for >>> this. Are you saying that you want to maintain such a branch? This would >>> include regular merges, etc. >>> >>> The Screen Widget has been around for over 2 years, and JPublish hasn't >>> been maintained in at least that much time. Perhaps it's time to >>> recommend that everyone stop using it? >>> >>> Part of the trouble is that there are other things that JPublish depends >>> on that we'll want to update or change, and any of those (like bsf) that >>> get in the way of updating other things will just branch out to a big >>> old problem... >>> >>> -David >>> >>> >>> On Dec 13, 2006, at 3:16 PM, Si Chen wrote: >>> >>>> How about we make a branch called "newbsf"? We can put all the changes >>>> for the new bsf jars there, and if Adam ever shows up with a new >>>> jpublish then we can merge it back in? >>>> >>>> On Dec 13, 2006, at 2:11 PM, David E Jones wrote: >>>> >>>>> >>>>> I am not opposed to this. >>>>> >>>>> It would have been nice if this had come up as an approach during >>>>> earlier and ongoing discussions as quite a few changes have now been >>>>> made to exclude JPublish (it would have to be put back into the >>>>> NOTICE/LICENSE files, the Libraries Included in OFBiz page, removed >>>>> from the OPTIONAL_LIBRARIES and change build files, code, etc. >>>>> >>>>> We would also need to keep a repository or at least a patch and >>>>> how-to somewhere so the jar file could be reproduced. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Dec 13, 2006, at 2:13 PM, Si Chen wrote: >>>>> >>>>>> David, >>>>>> >>>>>> We and some other people we work with all have OFBIZ-based >>>>>> applications from the ofbiz 3.x days which are jpublish-based, so to >>>>>> remove jpublish from the SVN and put in something which is >>>>>> incompatible with it basically breaks all of our applications and >>>>>> forces us to start to diverge from the core ofbiz code base in a way >>>>>> that we don't want to. >>>>>> >>>>>> I know what you mean about jpublish being not actively maintained, >>>>>> but the flipside it seems just to work ok for us, so we don't need >>>>>> to do too much for it. >>>>>> >>>>>> I guess if we can coordinate with Adam Heath to get a new >>>>>> bsf-compatible jpublish in the SVN then everything will be fine. >>>>>> Until then, are you planning to do something with the new bsf >>>>>> modules? Could it wait until Adam finds it in his kindness to send >>>>>> us an updated jpublish that he keeps promising? >>>>>> >>>>>> On Dec 13, 2006, at 12:13 PM, David E Jones wrote: >>>>>> >>>>>>> >>>>>>> Do we really want to do this? Part of the reason we wanted to >>>>>>> remove JPublish is that there doesn't seem to be much a community >>>>>>> around it and no one is maintaining it. >>>>>>> >>>>>>> In other words, if we want it in OFBiz, we have to maintain it... >>>>>>> Unless it is really useful for something, I have a big problem with >>>>>>> that... >>>>>>> >>>>>>> So, I guess in order to decide it would be good to know what you're >>>>>>> planning on (or have done) with JPublish that wouldn't work with >>>>>>> other things... and then see if that justifies maintaining JPublish. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> >>>>>>> On Dec 13, 2006, at 10:48 AM, Si Chen wrote: >>>>>>> >>>>>>>> When do you think you can send this in? >>>>>>>> >>>>>>>> On Dec 13, 2006, at 9:42 AM, Adam Heath wrote: >>>>>>>> >>>>>>>>> Si Chen wrote: >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>> I see that you've removed jpublish so that the newer versions of >>>>>>>>>> bsf can >>>>>>>>>> be integrated. What can we do to put jpublish back into the main >>>>>>>>>> repository? Is there a newer version of jpublish which would >>>>>>>>>> work well >>>>>>>>>> with the newer bsf stuff? We have a lot of things which require >>>>>>>>>> jpublish, including some ajax-related stuff we were going to >>>>>>>>>> contribute >>>>>>>>>> back. >>>>>>>>> >>>>>>>>> I've got a fixed jpublish I need to send in. I downloaded the >>>>>>>>> version >>>>>>>>> that ofbiz is using, and did the s/com.ibm.bsf/org.apache.bsf/ >>>>>>>>> fix. >>>>>>>>> Seems to work locally. >>>>>>>>> >>>>>>>>> Just been so busy. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Si >>>>>>>> [hidden email] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Si >>>>>> [hidden email] >>>>>> >>>>>> >>>>>> >>>> >>>> Best Regards, >>>> >>>> Si >>>> [hidden email] >>>> >>>> >>>> >>> > > Best Regards, > > Si > [hidden email] > > > > |
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
Re: jpublish.jar
|
|
| Free forum by Nabble | Edit this page |