Support runtime only dependencies

[OLibutzki]

Currently every dependency which is declared using //DEPS is part of the compile classpath.

In some cases it might be beneficial to declare dependencies as "runtime only".

A JDBC driver is one concrete example. You rarely compile against the concrete driver, but you might need it at runtime to establish the DB connection.

[maxandersen]

Not disagreeing but some specific uses case you have that this would help ? (Besides slight inconvenience of a longer compile classpath ?)

[OLibutzki]

Some libraries are supposed to work without compiling against them. They just implement an API which one can use as compile dependency.

By declaring those libraries as runtime dependency one can ensure that the jbang script doesn't (accidently) compile against the lib.

Besides JDBC, JSR380 (Bean Validation) is another example. You need Hibernate Validator at runtime for bean validation to work, not at compile time.

[quintesse]

My first reaction would be that:

a) either you want to specify explicitly which driver/validator to use in the script at which point I'd say there's probably no problem adding it to the compile class path as well, right? Unless there's some problem with that I'm not aware of?

b) or you want to be able to specify the dependency at runtime only in which case I'd say to simply leave out the //DEPS fromt he script and specify it on the command line with the --deps option.

[maxandersen]

For editing it's useful not getting imports/content assist for stuff that shouldn't be visible.

[quintesse]

Well ... sure ... but that seems like pretty advanced functionality for scripts. There is a limit of gradle/maven functionality that we can cram in our simple format IMO. We're already going somewhat in that (wrong?) direction with exclusions that are using ! and comma separated lists etc. Can we do it? Sure! Should we? ....

[OLibutzki]

I totally agree that this is a convenience feature. It does not make additional things possible from a runtime perspective.

Being able to exclude dependencies is something different as in it might hold be back from using jbang because of some classpath conflicts I cannot resolve.

[OLibutzki]

Closed it accidently.

[quintesse]

Being able to exclude dependencies is something different as in it might hold be back from using jbang because of some classpath conflicts I cannot resolve.

I agree with that, it seems like something necessary. I do wish there was a nicer way to define those exclusions though. The same with this, if there was a nice way to define this without resorting to a Perl-like symbol extravaganza I would be all for it :-)

[maxandersen]

Is ! What You call a perl symbol ? :)

[quintesse]

It's when all features are implemented by adding yet another symbol.

Having to learn (and remember) that for exclusions you have to use some kind of symbol with another kind of separator greatly increases the complexity of the script format. (Remember that you're trying to "sell" this to universities for first year students as well, not just died-in-the-wool Java experts like us :-) )

[maxandersen]

@quintesse i'll argue first year students that have to deal with exclusions already are on a path to a place that requires help :) by not adding lots of complex syntax to enable pass that hell faster seem good to me.

[maxandersen]

but do please suggest an alternative to this - i'm struggling to find one that is not worse.

[maxandersen]

wait this issue is for runtime dependencies - that is not about !. That is on #150