Chris Howe wrote:
...
In regards to the parent thread...
Because of the "black boxiness" of jar use, shouldn't there be an
actual _reason to add, update, or delete a jar that relates to how it's
used in the community project?
In my opinion it would be great if we could stay up-to-date with the
latest stable release, even if we don't have particular issues with the
older jars (the reasons are that newer releases are generally better
than older ones, you can get more support in case of problems, and
sometimes continuous small upgrades are less expensive than big ones).
However I know it's not always possible, mainly for two reasons:
1) jars interdependencies
2) lack of resources in the community (updating and testing could take a
lot of time)
If there's a feature desired, an important bug addressed, or noticeable
increased efficiency, then great, we should vote on upgrading.
However,
I don't think it's necessarily wise to be updating for updating sake.
Especially given the number of external dependencies Apache OFBiz has
I don't think that the issue of dependencies external to the Apache
OFBiz project is a big one... if someone is building an external
application he should pick the jars to use and not rely on the ones
distributed with OFBiz.
For example, if it is true that the MinML2.jar is no more used by OFBiz
(both framework and applications) we should really remove it. If someone
has built a custom component based on the MinML2.jar (?) he will have to
package the jar in its own custom component and we have no way to
prevent this from happening.
Jacopo
