Date: Thu, 28 Mar 2024 10:26:26 -0400 (EDT) Message-ID: <984047735.706.1711635986262@ip-10-208-27-219.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_705_397126663.1711635986259" ------=_Part_705_397126663.1711635986259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The latest version of Lucene is causing build failures in our tr= aditional all-in-one jarred dependencies and functional code build. W= e've known for some time that this is not consistent with best practices, d= espite it's conveniences. We are proposing removing this large jar fr= om the build and providing a single jar with LexEVS code as will as a depen= dency folder. This will require updated scripts, but will not change = much in our packaging of LexEVS since we already have the option of providi= ng separate dependency files in the with the installer as well as a single = LexEVS jar.
Best practice notes around building a single combined runtime jar:
Cons
Legal: Some dependency jars may have licensing restrictions that prevent= packaging with other dependencies.
Technical: Custom class loaders sometimes look for specific resources or= classes inside of specific jar files. This makes our build fragile as we u= pdate dependencies.
Dependency Management: A single jar makes it difficult to understa= nd what the project really depends on.
Our Build is Ant Based: More advanced single jar solutions such as= OneJar have a maven integration. Moving to maven as a primary build = process would be a big risk for the project and may not solve the problem.<= /p>
Pros:
Portability and maintenance is one step.
Our build process could probably use an update. (This still may not solv= e all our dependency problems where manifests create special class loading = situations)