I also think that the build should not produce different artifacts depending on a profile.
If the jar file gets too big when embedding the JDBC driver, we may want to consider producing two build artifacts: the jar file without RDB support and another one (e.g. with classifier "rdb") that embeds the drivers. Regards Julian On Fri, Apr 28, 2017 at 1:15 PM, Davide Giannella <[email protected]> wrote: > On 26/04/2017 09:32, Julian Reschke wrote: >> On 2017-04-26 10:28, Davide Giannella wrote: >> >>> a release we're not triggering any specific profile. >> >> Well, in that case we're not triggering the profile, right? > > Exactly. Therefore the released oak-run never embedded any jdbc so far. > Anyone correct me if I'm wrong. > >> >>> Regardless, the fastest solution is to increase the size according to >>> what you see. However is this a new dependency you're adding as of new >>> features? >> >> No, it always has been the case. >> >> However, if you select all RDB profiles you'll include essentially all >> JDBC drivers, in which case maintaining the limit becomes pretty >> pointless... > > I'd say you could change the size for the RDB profiles only (adding the > enforcer size under the profiles) or simply increase the general size. > > It seems strange to me that we're not embedding the jdbc dependencies > for the released jar. Maybe we want to change that and simplify. > > How bit is the generated jar for the RDB profiles? > > D.
