<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.infinite-erp.co.id/index.php?action=history&amp;feed=atom&amp;title=How_To_Upgrade_a_Library</id>
	<title>How To Upgrade a Library - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.infinite-erp.co.id/index.php?action=history&amp;feed=atom&amp;title=How_To_Upgrade_a_Library"/>
	<link rel="alternate" type="text/html" href="https://wiki.infinite-erp.co.id/index.php?title=How_To_Upgrade_a_Library&amp;action=history"/>
	<updated>2026-04-06T18:35:19Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.31.1</generator>
	<entry>
		<id>https://wiki.infinite-erp.co.id/index.php?title=How_To_Upgrade_a_Library&amp;diff=1152&amp;oldid=prev</id>
		<title>Wikiadmin: Created page with &quot;== Overview ==  {{(!)|The intended audience of this document is mainly Openbravo staff. It describes the internal process to be followed whenever a library needs to be upgrade...&quot;</title>
		<link rel="alternate" type="text/html" href="https://wiki.infinite-erp.co.id/index.php?title=How_To_Upgrade_a_Library&amp;diff=1152&amp;oldid=prev"/>
		<updated>2021-09-14T01:02:00Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;== Overview ==  {{(!)|The intended audience of this document is mainly Openbravo staff. It describes the internal process to be followed whenever a library needs to be upgrade...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;== Overview ==&lt;br /&gt;
&lt;br /&gt;
{{(!)|The intended audience of this document is mainly Openbravo staff. It describes the internal process to be followed whenever a library needs to be upgraded. It applies both to libraries in Openbravo 3 distribution as well as to libraries delivered by modules.}}&lt;br /&gt;
&lt;br /&gt;
From time to time, it is necessary to upgrade a Java library (a jar file) to a newer version. Motivations for this can be diverse:&lt;br /&gt;
&lt;br /&gt;
* Make use of new capabilities&lt;br /&gt;
* Get rid of bugs in older version&lt;br /&gt;
* Keep updated stack&lt;br /&gt;
* ...&lt;br /&gt;
&lt;br /&gt;
To upgrade a library the process described bellow needs to be followed.&lt;br /&gt;
&lt;br /&gt;
== Prerequisites ==&lt;br /&gt;
&lt;br /&gt;
{{(warn!)|If any of the following prerequisites is not satisfied, it will '''not be possible''' to upgrade the library to the newer version!!}}&lt;br /&gt;
&lt;br /&gt;
Note these prerequisites apply also when adding a new library.&lt;br /&gt;
&lt;br /&gt;
=== JDK version compatibility ===&lt;br /&gt;
&lt;br /&gt;
'''All''' jars need to be compatible with, at least, the [http://wiki.openbravo.com/wiki/System_Requirements#Server:_software_stack lowest supported JDK version] by Openbravo. If the jar is compiled with a higher version, it will not be usable in instances running an older one (yes in the other way around).&lt;br /&gt;
&lt;br /&gt;
To check the JDK version used to compile this library:&lt;br /&gt;
&lt;br /&gt;
* Unzip the new jar: &amp;lt;code&amp;gt;unzip ''new-library.jar'' -d /tmp/new-library&amp;lt;/code&amp;gt;&lt;br /&gt;
* Typically in the &amp;lt;code&amp;gt;META-INF/MANIFEST.MF&amp;lt;/code&amp;gt; file there is information about the JDK used to compile it&lt;br /&gt;
* It is also posible to check the JDK used to compile &amp;lt;code&amp;gt;.class&amp;lt;/code&amp;gt; files. This is done with the &amp;lt;code&amp;gt;javap&amp;lt;/code&amp;gt; program checking the major version value. [http://stackoverflow.com/a/1096159/2834815 Here] you can find how they correspond with the currently used numbers. The following script list versions of all &amp;lt;code&amp;gt;.class&amp;lt;/code&amp;gt; files, note it can take time in case there are many files in the jar: &amp;lt;code&amp;gt;for f in `find -name &amp;quot;*class&amp;quot;`; do javap -verbose $f | grep &amp;quot;major version&amp;quot;; done | sort | uniq&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=== License compatibility ===&lt;br /&gt;
&lt;br /&gt;
Usually libraries select a license and they stick to it among different versions. But sometimes, license is changed from a version to another.&lt;br /&gt;
&lt;br /&gt;
When upgrading a library (or including a new one), you need to check the newer version's license.&lt;br /&gt;
&lt;br /&gt;
* If it is the same as the older version, there is no problem.&lt;br /&gt;
* If it is a different one, check in the &amp;lt;code&amp;gt;legal/Licensing.txt&amp;lt;/code&amp;gt; file:&lt;br /&gt;
** If the new license is already used by any of the included libraries, no problem&lt;br /&gt;
** If not, lawyer needs to be asked whether the new license allows to distribute this library&lt;br /&gt;
&lt;br /&gt;
== Process ==&lt;br /&gt;
&lt;br /&gt;
Once the prerequisites are satisfied, the upgrade process consists on the following steps:&lt;br /&gt;
&lt;br /&gt;
=== Check for API changes ===&lt;br /&gt;
&lt;br /&gt;
A new library version can change its public API. To check these changes:&lt;br /&gt;
&lt;br /&gt;
  hg clone clone https://code.openbravo.com/erp/devel/api-checks/&lt;br /&gt;
  cd api-checks/java/tools&lt;br /&gt;
  java -classpath japitools.jar net.wuffies.japi.Japize as /tmp/old-api apis ''path_to_old_jar'' $JAVA_HOME/jre/lib/rt.jar $JAVA_HOME/jre/lib/jsse.jar +org # change org with the topmost part of the package in the library&lt;br /&gt;
  java -classpath japitools.jar net.wuffies.japi.Japize as /tmp/new-api apis ''path_to_new_jar'' $JAVA_HOME/jre/lib/rt.jar $JAVA_HOME/jre/lib/jsse.jar +org # change org with the topmost part of the package in the library&lt;br /&gt;
  ./japicompat /tmp/old-api.japi.gz /tmp/new-api.japi.gz | tee /tmp/api-checks.txt&lt;br /&gt;
&lt;br /&gt;
These steps will generate a &amp;lt;code&amp;gt;/tmp/api-checks.txt&amp;lt;/code&amp;gt; file detailing all changes that might exist.&lt;br /&gt;
&lt;br /&gt;
==== Check source compatibility ====&lt;br /&gt;
&lt;br /&gt;
Even when the api-checks tools do not find any API changes, there may be source incompatibilities of the new version with the previous ones, see [https://issues.openbravo.com/view.php?id=31432#c81723 here] an example. To check this, review the release notes of the library from the previous to the new version.&lt;br /&gt;
&lt;br /&gt;
==== Check how these changes affect published modules ====&lt;br /&gt;
&lt;br /&gt;
{{(!)|This step is only applicable in case of API changes or when including a new library.}}&lt;br /&gt;
&lt;br /&gt;
Get the code of all published modules in Central Repository. If you have access to Central Repository server, follow next steps, if not, ask someone else (ALO, SHU, AMA...) to do it for you.&lt;br /&gt;
&lt;br /&gt;
 git clone https://github.com/alostale/ob-scripts.git&lt;br /&gt;
 ob-scripts/getAllModules/get-modules.sh&lt;br /&gt;
 ob-scripts/getAllModules/unzip-modules.sh&lt;br /&gt;
&lt;br /&gt;
This will generate a &amp;lt;code&amp;gt;src&amp;lt;/code&amp;gt; directory with sources of all published modules.&lt;br /&gt;
&lt;br /&gt;
Now you can check in the code how the library is used there and whether these changes can affect them. This will give you an idea of the risk of these changes, and might, eventually, require to abort the upgrade process.&lt;br /&gt;
&lt;br /&gt;
===== Adding a new library =====&lt;br /&gt;
&lt;br /&gt;
When adding a new library, check in published modules whether there are already modules that deliver it. Pay special attention whether they include a different version to the one you want to update, because in this case incompatibility issues could appear when installing that module together with your library. Depending on how big the impact is a decision on what to do (proceed and communicate it to owner, abort upgrade...) will be required to be taken.&lt;br /&gt;
&lt;br /&gt;
==== Publish API changes ====&lt;br /&gt;
&lt;br /&gt;
In case there are API change publish them in the [[API_changes|wiki]] following the defined process.&lt;br /&gt;
&lt;br /&gt;
=== Update &amp;lt;code&amp;gt;legal&amp;lt;/code&amp;gt; folder ===&lt;br /&gt;
&lt;br /&gt;
All modules containing third party libraries should have a &amp;lt;code&amp;gt;legal&amp;lt;/code&amp;gt; directory, which lists the licenses of all included libraries. It also has a &amp;lt;code&amp;gt;Licensing.txt&amp;lt;/code&amp;gt; file, listing all library versions and the license they have.&lt;br /&gt;
&lt;br /&gt;
* Update &amp;lt;code&amp;gt;Licensing.txt&amp;lt;/code&amp;gt; file to reflect new version&lt;br /&gt;
* In case of a different license:&lt;br /&gt;
** Include the text if it is not present yet&lt;br /&gt;
** Check if old license is still used by any other library, if not, remove the not used license file&lt;br /&gt;
&lt;br /&gt;
=== Update the .classpath file ===&lt;br /&gt;
&lt;br /&gt;
The library is referenced in the .classpath file. If the name of the jar has changed, the file must be updated with the new name.&lt;br /&gt;
&lt;br /&gt;
=== Update wiki ===&lt;br /&gt;
&lt;br /&gt;
When upgrading a library included within Openbravo 3 distribution, update the [[Openbravo_Libraries|wiki page]] that list all the libraries included.&lt;br /&gt;
&lt;br /&gt;
[[Category:HowTo]]&lt;/div&gt;</summary>
		<author><name>Wikiadmin</name></author>
		
	</entry>
</feed>