By far the easiest way to do it is via a separate maven module. It just adds another jar dependency. Alternatively, you can use the maven dependencies plugin to copy in code from another module to make an aggregate one (how we package a multi version jar in log4j2 at least).
On Mon, May 25, 2020 at 02:15 Emmanuel Lecharny <[email protected]> wrote: > Hi Matt, > > we could modify the build to generate distinguish packages for the > various JAVA version (at least for the LTS supported versions, like > Java 11 and Java 14). > > The thing is that we added some Jenkins tasks for Java 11 and 14n, and > MINA tests fail with those versions, so there are thing we need to > investigate before cutting a new release. > > Not that it should forbid us to get those specific versions though, > it's just that we need to get that fixed first. > > Regarding the build process, I can foresee the usage of profiles to > get those specific packages cut. However, we need to find a way to > have a common code base, with a way to make the extensions optional. > That probably mean excluding some specific java file from being > compiled in Java 8 - assuming we can limit the impact on just a few > added files -. > Or maybe a separate maven module ? > > On Sun, May 24, 2020 at 7:44 PM Matt Sicker <[email protected]> wrote: > > > > It appears that I assumed a ticket existed for this particular issue, > > but it doesn't. This is about SSHD in particular. In order to support > > the following: > > > > https://issues.apache.org/jira/browse/SSHD-594 > > https://issues.apache.org/jira/browse/SSHD-811 > > https://issues.apache.org/jira/browse/SSHD-704 > > > > Similarly to support the [email protected] cipher, > > > https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL.chacha20poly1305?annotate=HEAD > > > > All these issues either require using crypto APIs added in Java 11 or > > relying on dependencies (I assume there's no desire to maintain cipher > > implementations here). In Log4j, we've solved some of this problem by > > using multi-release jars to add version-specific support for newer > > APIs. In this case, we could include optional support for the JDK APIs > > when running a new enough JDK; otherwise, the fallback can use > > Bouncycastle-specific APIs where necessary. However, configuring a > > Maven project appropriately for multi-version jars is a pain, so I was > > wondering if there were any plans on going this route anywhere? > > > > On Sun, 24 May 2020 at 12:11, Jonathan Valliere <[email protected]> > wrote: > > > > > > I’m not sure what Mina project or specific problem you’re referring to. > > > > > > On Sun, May 24, 2020 at 12:22 PM Matt Sicker <[email protected]> wrote: > > > > > > > In order to support ChaCha20-Poly1305, Java 11 is required, or a > backport > > > > of the cipher and mac to Java 8 like in Bouncycastle (whose java > > > > implementation is based on an unrolled optimized C version). > > > > > > > > I was wondering if there was any way to package optional things for > multi > > > > release jars so that we could support ChaCha without requiring BC on > Java > > > > 11+? > > > > -- > > > > Matt Sicker <[email protected]> > > > > > > > > > > > > -- > > Matt Sicker <[email protected]> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Matt Sicker <[email protected]>
