2018 CI migration Spring project determination

We have an ear that contains 3 wars, 1 utility jar project, and ~30 EJB jar’s. The ear has a *lot* of jar’s in its <project>/lib directory. Among them are the Spring jar’s.

Attached are the screen shots referenced below. I have available a workspace for this example. It only contains 2 projects versus our real situation with ~34 of our war’s/jar’s and 100+ third party jar’s. Even stripped down, it’s too big for your forum upload limit of ~12M. I have it on DropBox if you want the link.

stafftrack_utility is the root project that must be built first. FWIW, it is a member of the ear via the ear’s project properties -> Deployment -> Deployment Assembly list. See attachment Migration1.png. With either project properties -> Libraries -> EAR Libraries or a User Library whose contents are all jar’s in the ear’s lib directory, the stafftrack_utility project shows up in the project migration view. See attachment Migration2.png. Note the inclusion of Spring Core in the Third Party User Library. The reason the project being in the migration list is that ME thinks it needs to have the Spring Facet added only because the Spring jar’s are in the build path. See attachment Migration3.png. It does not have that facet currently, nor should it. See attachment Migration4.png.

If the stafftrack_utility project is changed so that EAR Library and Third Party User Library are replaced by Third Party – No Spring, stafftrack_utility is removed from the list following a refresh of the Workspace Migration view. See attachment Migration5.png.

Applied to our real environment, there are a whole lot of EJB jar’s that the migration insists need the Spring facet and it’s simply wrong. It makes far more sense to me to use the EAR Library functionality built into Eclipse on all those projects than it does to assume that the presence of Spring jar’s on the build path means a project is a Spring project.