Introduce use of OpenSAML BOM to IdP dependency management
Description
Environment
Activity
Brent PutmanSeptember 11, 2018 at 1:42 AM
Updated in:
OpenSAML: 4b8ea8f8a413ccb1c98ba2b1a6640b19d6da1264
IdP: 8c4417deb9ef9c170e2c149dc36a8e4bd020ca36
Brent PutmanSeptember 11, 2018 at 1:40 AM
I agree. Although the BOM isn't really about API. It includes the -impl artifacts for example. But it seems cleaner to separate them out, since the vast majority of people wouldn't need the tests. I'll go ahead and do that.
Scott CantorSeptember 10, 2018 at 11:31 PM
I think I would be in favor of splitting them out. We don't really define our test jars as part of the API.
Brent PutmanSeptember 10, 2018 at 11:28 PM
This seems to work as-is and we could nominally close this.
One question that has occurred to me in hindsight is whether the existing primary BOM really ought to include all the test scope dependencies that I just added for all the test jars, e.g:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>opensaml-core</artifactId>
<version>${project.version}</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>I tried to see if there was any hint anywhere about conventions of a BOM project containing test jars or not, but couldn't find anything. Maybe Ian or someone else has some opinion or background on this.
I think the likely alternative would be to just create a new tests-only BOM, and move the test jars there. Technically speaking it's ok like it is, but I think once we publish 3.4.0 with the test jars in the main BOM, we're committed to that. So if we want to split off a tests-only BOM, then we should probably do it now. It's just a couple of minutes of work in any case.
Whichever we choose, we should probably also do the same for the IdP BOM module, so an extensions/plugin project could easily leverage the IdP test-jar artifacts
Thoughts?
Brent PutmanSeptember 8, 2018 at 12:50 AM
Once I got around some unrelated build issues documented in OSJ-212, this was fairly straightforward.
Other than the steps already documented, the only other thing required was that the OpenSAML BOM needed to be updated to also have all of modules enumerated for use in IdP tests, with type=test-jar and scope=test.
IdP builds and tests cleanly locally via Maven. If Jenkins is happy, then this is likely done.
OpenSAML changes in 1a3001c86c725df0d3304fe6d2574abe69c6d308.
IdP changes in 7f67f0f0690af68ed0e1d237fbf23b4af4f52c74.
Eat our own dog food and use the opensaml-bom to standardize use of OpenSAML artifacts within the IdP.
Import opensaml-bom in idp-parent's <dependencyManagement> section
Review, cleanup, and standarize how OpenSAML artifacts are referenced
remove individual modules' use of opensaml version properties
omit <version> from dependency decls
This should clean up a transitive dependency issue noted in OSJ-212.