jpublish.jar

I vote +1 for remove JPublish from OFBIZ.

Thanks
Marco


---------- Initial Header -----------

From      : "David E Jones" [hidden email]
To          : [hidden email]
Cc          :
Date      : Wed, 13 Dec 2006 16:16:00 -0700
Subject : Re: jpublish.jar

>
>  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]
> >
> >
> >
>
>

------------------------------------------------------
Passa a Infostrada. ADSL e Telefono senza limiti e senza canone Telecom
http://click.libero.it/infostrada14dic06

[Jacopo Cappellato]

Si Chen wrote:
> David,
>
> Thinking about it further, I would have to agree with you.  Since
> jpublish is no longer used by anything in the core OFBIZ, there is not
> necessarily a reason to keep it any more.  Maintaining backward
> compatibility is something that we'll just have to deal with separately.
>

In my opinion backward compatibility is important and is something we
have to take into account but in the same time we have to evaluate the
pros and cons case by case.
As regards JPublish, since its community is no more actively maintaining
it, it was relying on old jars (that we are now upgrading) and patching
it would also mean to upgrade the OFBiz code related to it... and
evidently very few guys here are interested in doing it since we had to
keep old jars instead of upgrading JPublish.
This was becoming a problem, see for example
https://issues.apache.org/jira/browse/OFBIZ-311

> I guess it just came as a shock is all.

The OFBiz's trunk is always pretty stable, this is how we want to keep
it and we are all involved in this goal.
There are pros (e.g. we can minimize the creation of stable releases,
the trunk is very easy to checkout/build and run etc...) and cons (new
features are a bit slower to implement, it is more difficult for new
developers to see thei patches included etc...) with this approach.
This means that one OFBiz "nightly build" is usually much more stable
and usable that the "nightly build"s of other open source projects.
However the OFBiz trunk remains a development snapshot and it is not
guaranteed that it is always stable; and obviously it is not guaranteed
that an external custom component (I'm not thinking of Opentaps now,
since I'm pretty sure that there are no more JPublish pages there) can
always work without any changes against the latest trunk... this is
really out of our possibilities.

> I did not realize that the plan
> was to remove jpublish rather than just deprecate it in favor of the
> screen widgets, since that's what seems to have happened to the regions
> framework from long long ago.

As you know, JPublish has been deprecated a lot of time ago, I have
personally migrated dozens of OFBiz's pages from JPublish to the widgets
in the last year(s?) in my spare time; I think that all the
custom/proprietary components outside could have done the same; if not,
this is not a big deal, they'll have to complete the migration to the
screens before upgrading to the svn revisions higher than 485561.

> I really would have liked some advanced
> notice about framework changes to plan things out.
>

I agree with Si, this can really be improved: I think we should add a
notice in the OFBiz news section of the site warning about this, and
maybe preparing a page with some instructions about the migration to
widgets or what can be done to re-introduce the JPublish jars
(discouraged, in my opinion).

> Speaking of which, then, does the upgrading of the bsf jars mean that
> you or anybody else who actually contributes to the project is planning
> to do something with it in the near future?  Might be nice to know :)
>

I really don't know... however the migration was not done just to
upgrade that jar.

Jacopo