Introduction

The current implementation of Grouper uses Ant tasks to build its artifacts, relying on third-party dependencies being supplied along with each submodule. The versions of these jar files are not always clear, as the version is often missing from the filename, and the MANIFEST.MF file is sometimes missing an Implementation-Version property or it is inaccurate. When comparing these files versus official sources (e.g. Maven repositories), some of them are identical to published versions, some are close matches, and some can't be matched to any known version. One goal of this project is to replace all official jars with ones from known provenance. Files should always include the version number in the filename, to make it much easier to identify the version, and to make it easier to track down in public locations.

In addition, some of these supplied jars are many versions behind the current release. Where possible, we should upgrade to the latest version that is still compatible without breaking existing functionality.

The identification compares local jars against versions uploaded to the Maven Central Repository (http://search.maven.org/). The versions for supplied jars are taken first from the MANIFEST.MF property Implementation-Version if available, then from the version in the filename, otherwise any other clues in the MANIFEST file of the jar. If the version can be identified, a guess at a corresponding version in the Maven repository is compared, The strongest match is an identical checksum. The second best is that all of the class files are a binary match, disregarding Java source code, Javadoc html files, testing classes, or other miscellaneous files. If there are extra or missing classes, it suggests that either the alleged version is misidentified, or the supplied jar bundles multiple libraries into a single jar file. If there still is no good match, the supplied file is left alone, as it will likely be upgraded later.

Testing upgraded jars will first involve running the full test suite from the source code JUnit tests (2100+ tests over 5 hours), to verify no regressions are introduced. Then the Grouper UI, Web Services, and other submodules will need to be broadly tested to confirm all functions continue to work.

 Status as of Grouper 2.4.0 Release (in 2018)

As of Grouper release 2.4.0, the libraries have been updated in the official distribution. The equivalent dependency versions in Maven pom.xml files have also been updated to match as close as possible. Grouper 2.3.0 or earlier versions have not been updated, even with patches, except to remedy specific issues.

Grouper API

Phase 1 - Identify jars identical or close matches with official versions, rename or replace with official one if needed

Of the approximately 70 jars in the lib/grouper, lib/jdbcSamples, and lib/jetty directories, a good number already match both the checksum and the filename, so that nothing needs to be done.

Some others match the checksum of a published file, but are missing the version number from the filename. These can be renamed:

Others don't match the checksum, but have identical .class objects within the files, so wouldn't be affected by updating to the official version. The file differences are solely in the existence of javadoc or source code, or in other properties in the manifest file.

The remaining files either didn't have its version available in the Maven repository, or had significant differences with the published version, so more analysis is needed.

Phase 2 - Identify unneeded jars

It's feasible that, over time, a library may have been added that is no longer needed due to code changes. If a library can be safely removed from the distribution, it means a smaller distribution file size, and is one less library to be maintained and updated. If a library is not needed by the Grouper API library but is needed in another subproject, it should be moved out of the API library folder and into the other project's folder.

The Grouper source code has certain direct dependencies on third-party library jars. Many of these libraries have dependencies of their own. Two methods that can be used to discover these dependencies are the Java jdeps command and Maven packaging operations. While these methods can reliably identify compile-phase libraries, it is harder to know about classes that are needed at runtime.

Phase 3 - Where possible, upgrade remaining jars to the latest version

Already the latest version:

correctly named but not current version -> git rm and git add the new one:

Files at the latest version, allegedly the correct name but not an official maven version -> replace with official one and update in git:

Files that weren't a good match to Maven anyway, git remove and replace

Note that the following could not be upgraded to the latest version due to compile or test issues:

Grouper UI

Phase 1 - Identify jars identical or close matches with official versions, rename or replace with official one if needed


Identical checksums, can be renamed:


Don't match checksum, but *.class files identical (difference is *.java, javadoc, or manifest)


Most classes match, but a few minor differences:


Phase 2 - Identify unneeded jars


Using Java jdeps command, along with explicit dependencies listed for Maven versions of included jars, identify libraries that can potentially be removed:


It was later discovered that taglibs-datetime and taglibs-request are needed by Struts 1 and the admin UI. They are being left out since the admin UI will eventually be removed.


Phase 3 - Where possible, upgrade remaining jars to the latest version



Also, the supplied servlet.jar seems to be the fully implemented servlet library normally supplied by the servlet container. Thus, it was replaced by the API stubs servlet-api and jsp-api



Grouper WS

As most of the libraries in this project already match versions from the Maven repository, little needed to be done here. Upgrading the exising jars, along with analysis of potentially unneeded libraries, weren't done at this time.


Subject

The subject module has been combined into the grouper module.


GrouperClient

The grouper client is aimed at creating an executable jar. Thus, there are no external libraries involved.