The latest version of Lucene is causing build failures in our traditional all-in-one jarred dependencies and functional code build. We've known for some time that this is not consistent with best practices, despite it's conveniences. We are proposing removing this large jar from the build and providing a single jar with LexEVS code as will as a dependency folder. This will require updated scripts, but will not change much in our packaging of LexEVS since we already have the option of providing 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:
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 update dependencies.
Dependency Management: A single jar makes it difficult to understand 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.
Portability and maintenance is one step.
Our build process could probably use an update. (This still may not solve all our dependency problems where manifests create special class loading situations)
Safran, Tracy (NIH/NCI) [C]
There are three main build types that need to be considered, the admin build, the service build and the client build.
The admin build is handled by Rob or I. We drop it into a directory and then expect the various admin scripts and such to work against it. Whether this is one jar or multiple isn’t really an issue as we aren’t building against it or using Maven in any capacity. We can move to a model where we build the loader jars and place them ourselves but would need some support to get this set up with the proper ant and pom files.
The service build is the war placed into JBoss and used to run the service. This is the war file that relies on the current lbRuntime.jar. This is currently being built and deployed by anthill pro, which is deprecated. I don’t know what the new build scheme will be, but we will want to find out before we make any final decisions about how we will set up the packaging. I don’t think this needs a change on its own, but we need to keep a wary eye on it in case Anthill gets discontinued and we have to use a different build method.
The client build is what users will grab in order to query the API. Right now our code examples and jars support a caCORE query model. I do not believe we are required to use caCORE anymore, but I will send out some questions today to find out. If we can dump caCORE this might make the client leaner and simpler. All of our example code utilizes the caCORE to reach the API so we would need to update all of this documentation. We also have current users that utilize the caCORE method that would need to be supported in the short term.
We discussed a few weeks ago that CBIIT is making more use of Maven and would like to see the client distributed that way, with dependencies separate but specified in a POM, per the Maven model. I tried to do a test project today in Eclipse using the client that is currently in Maven but couldn’t find documentation for how to set this up.
Bauer, Scott (NIH/NCI) [C]
Given we don't have any uses of the lbRuntime jar other than in the circumstances where the local runtime is used for loading and administration purposes, It appears we can proceed to adjust the build to stop building the larger jar when time allows.
Bauer, Scott (NIH/NCI) [C]
Gilberto also weighed in with this comment
Hi Scott, your suggestion is reasonable, I’m good with it. Thx, Gilberto