On Oct 29, 2006, at 12:41 AM, Jacopo Cappellato wrote:
Yes,
when we'll upgrade the bsh.jar we will need to upgrade the JPublish
version as well... but this is not an easy task and I don't know if
there will be enough interest for this since JPublish is almost no
more used for developing OFBiz ui.
This raises some general issues that we should discuss:
a) how to track the version of the jar files distributed with
OFBiz? (I think it is a good idea to append the revision number to
the name of the jar file)
Yes, we should make a practice of this now. A long time ago we tried
to avoid adding the version number to the name because we had various
files that listed out all of the jar files. We don't do that any
more, instead we list directories and all jars in those directories
are included.
We should also always include the library name and version number in
the commit log.
b) how to manage jar interdependencies? For example, the new
JPublish distribution depends on several jar files (included in the
JPublish distribution), and some of them (such as the bsh.jar file)
are already included in OFBiz but could be of a different release
(older or newer)... how should be handle situation like this one?
This is a really annoying practice. The best solution is to break
open the jar, pull out the redundant pieces, and then build a new jar
with what remains.
Still, I don't know that we want to update JPublish. The problem with
it is that it is no longer all that actively maintained and doesn't
really have a sufficient user community to keep the project moving.
There are certainly others using it, but since there aren't enough it
means that if we want to continue using it we would have to take on
some of the updating work. This is one of the reasons we started
moving away from it, and we have run into this with other libraries/
projects as well.
c) this last point is a philosophical issue: it is nice to keep the
older tools in the framework (such as the integration with
JPublish), even if in the OFBiz distribution they are no more used
(but this is still not the case of JPublish, used by the Shark and
Content components), however what should we do when the older tools
make more difficult the upgrade to newer tools (new jars etc...)? I
think that this could slow down the growth of OFBiz because it is
difficult to find people willing to help to keep updated with the
rest of the system things that are not really used. (should we
think of a framework-lite distribution of the OFBiz framework that
contains just the things that the svn version of OFBiz uses?)
As long as we depend on other open source projects this is guaranteed
to be a problem. I think in general this is just something we'll have
to live with.
If something we are using is not being maintained and we don't want
to maintain it, we need to find a replacement. For JPublish we have a
replacement now with the Screen Widget, and we just have some
straggler code that is still using JP. These we should probably move
over so we can get rid of JPublish and move on.
In general I don't like tossing old tools, even deprecated ones, but
in this case JPublish is getting in the way of other things and
unless someone has an objection to this and wants to help update it
or whatever is needed, then we should just let it go. As a worst case
the code is always in the SVN history and someone can resurrect it as
needed.
Shark is a different thing. If it becomes too much of a problem we
might eventually consider removing it from the code base, but for now
we can just leave it out of the build and deploy stuff (ie comment
out the shark line in the component-load.xml file). This is a project
that is being actively maintained and we are just behind, or really
the initial work was never quite finished. At this point I don't
think it is causing any problems, so we can just comment it out. For
now we could probably ignore the JPublish stuff there and when
someone gets interested in it again they will find it is not working
because it needs to be screen-ized. That may increase the barrier to
entry in the future, but really if anyone wants to get into it the
project will require at least a few days of updating and refactoring
and such.
That would leave us with just the page in the content manager to
update in order to be able to remove JPublish...
-David
Jacopo
Jacques Le Roux (JIRA) wrote:
[ http://issues.apache.org/jira/browse/OFBIZ-401?
page=comments#action_12445373 ] Jacques Le Roux
commented on OFBIZ-401:
---------------------------------------
Reviewing more seriously this issue I realised that the problem
Jacopo encoutered is related to JPublish.
I checked source (http://jpublish.cvs.sourceforge.net/jpublish/
jpublish/src/org/jpublish/action/ScriptAction.java?view=log) :
Jpublish does not use IBM no more for 2 years and a half now. So
it seems that updating JPublish to last stable should do the trick...
In Revision 1.34 you may see David's work :o)
upgrade bsf to something a bit more modern
------------------------------------------
Key: OFBIZ-401
URL: http://issues.apache.org/jira/browse/OFBIZ-401
Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: framework
Affects Versions: SVN trunk
Reporter: Adam Heath
Assigned To: Jacques Le Roux
Priority: Trivial
Fix For: SVN trunk
Attachments: bsf.diff
OfBiz still uses a bsf version from when it was hosted/maintained
by ibm. The attached patch fixes this(does a search/replace),
changing the package names.
