depends what their license is. EPL is (weak) copyleft. Thus I would like to avoid exposing it downstream as api.
LieGrue, strub > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > If we still can't reuse jakata artifacts (their license is ok and there is > no impl reference inside so we should just use them, right?) it sounds > natural > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <jlmonte...@tomitribe.com> > a écrit : > >> Hi all, >> >> I was digging into some other specifications and see what would pass >> Jakarta TCK and realized that geronimo-security_1.0_spec content actually >> mixes 2 specifications. >> >> https://github.com/eclipse-ee4j/security-api >> >> and >> >> https://github.com/eclipse-ee4j/jaspic >> >> I thought the initial intent was to create a specific artifact per >> specification. >> Mixing them is a bit annoying from a certification perspective. >> It's also not clean because in Tomcat for instance, there is already >> jaspic API so it becomes a duplicate. >> >> Would it be possible to split them up in 2 artifacts? >> >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >>
