You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2006/10/29 07:41:43 UTC
How to manage jar files in OFBiz WAS [Re: [jira] Commented: (OFBIZ-401)
upgrade bsf to something a bit more modern]
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)
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?
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?)
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.
>
Re: How to manage jar files in OFBiz WAS [Re: [jira] Commented:
(OFBIZ-401) upgrade bsf to something a bit more modern]
Posted by Jacques Le Roux <ja...@les7arts.com>.
> 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)
+1
> 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?
I agree with David to keep only what is needed (no duplication) but it's one more task and we have already plenty, isn't ?
For the moment my advice would be "status quo"
> 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?)
I agree. Shark is already commented out. For Content this seems more complicated, I have no clear idea
Jacques
>
> 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.
> >
Re: How to manage jar files in OFBiz WAS [Re: [jira] Commented: (OFBIZ-401)
upgrade bsf to something a bit more modern]
Posted by Jacopo Cappellato <ti...@sastau.it>.
David E Jones wrote:
>
> ...
>
> That would leave us with just the page in the content manager to update
> in order to be able to remove JPublish...
>
> -David
>
>
I agree with David's comments and so I really think that getting rid of
the JPublish pages in the Content application should be an high priority
task now.
I could help with this in my spare time but since many of the Content's
screens are already broken or don't function properly, I'd love to get
some hints from the persons who have contributed to the component in the
past (e.g. Al and maybe Hans) about:
- the screens that are just an (incomplete) work in progress and can be
disabled (instead of migrated) for now
- the screens and other artifacts that are old or superseded or
misplaced or duplicated artifacts and can be removed (for example, there
is a services.xml file in the WEB-INF folder;
LookupPartyAndUserLoginAndPerson.ftl and LookupPerson.ftl in the content
folder; there are some files in the images folder that seems to me just
copies from the framework/images component; mysterious files such as
EditLayoutContent.ftl.multi in the layout folder etc. etc. etc...)
Thanks,
Jacopo
Re: How to manage jar files in OFBiz WAS [Re: [jira] Commented: (OFBIZ-401) upgrade bsf to something a bit more modern]
Posted by David E Jones <jo...@undersunconsulting.com>.
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.
>
Re: How to manage jar files in OFBiz WAS [Re: [jira] Commented: (OFBIZ-401)
upgrade bsf to something a bit more modern]
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Jacopo Cappellato schrieb:
[..]
> 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)
+1
Christian