[labkey-adam]

Rationale

Shrink the api module by moving classes that only one module uses into that module, so they no longer compile on the api build path that every module waits on.

Each moved class takes its owning module's package (e.g. org.labkey.api.reader.XMLStreamReaderWrapper → org.labkey.ms2.reader.XMLStreamReaderWrapper); the two that move into a module API keep their package. Classes referenced by name from Spring XML, labkey.tld, or client code stay in api, as do classes that rely on package-private or protected access to api internals.

Related Pull Requests

• https://github.com/LabKey/premiumModules/pull/830
• Move single-module classes out of api into their owning modules commonAssays#1098
• Move single-module classes out of api into their owning modules customModules#291
• Move single-module classes out of api into their owning modules OConnorLabModules#221
• Move single-module classes out of api into their owning modules targetedms#1300
• https://github.com/LabKey/limsModules/pull/2573
• Move single-module classes out of api into their owning modules testAutomation#3272
• Move single-module classes out of api into their owning modules snprcEHRModules#1028

Changes

• Move api classes and JSPs used by a single platform module into core, query, experiment, study, pipeline, survey, assay, filecontent, search, wiki, and visualization
• Move two classes into the assay and study module APIs
• Move unit and integration test registrations for moved classes from ApiModule to their new modules
• Remove unused classes
• Move several classes from the study module to the specimen module