Catalog script-ref for uber artifacts

[cstamas]

trafficstars

Is your feature request related to a problem? Please describe. I have a CLI artifact that is uber of main one (that is a maven-plugin), with classifier "cli". Naturally, cli JAR is self contained. I want to have catalog that tells jbang "I need this artifact ONLY" (like resolve file vs resolve transitively file). The catalog entry is https://github.com/maveniverse/jbang-catalog/blob/main/jbang-catalog.json#L20

I think this is pretty common, that if artifact pointed at is "sub artifact" (have classifier), Maven would pick up POM, but IMO for jbang "use case" this is not needed. JBang could be smart, and resolve transitively if no classifier present, or resolver artifact along if classifier present, as this seems to me as pretty common situation (main JAR w/ CLI uber jar).

Currently toolbox works, but I have warnings as slf4j-simple is twice present on classpath (once in uber CLI and once as resolved dependency):

[cstamas@angeleyes toolbox (main)]$ jbang toolbox@maveniverse
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/home/cstamas/.m2/repository-oss/eu/maveniverse/maven/plugins/toolbox/0.1.0/toolbox-0.1.0-cli.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/cstamas/.m2/repository-oss/org/slf4j/slf4j-simple/1.7.36/slf4j-simple-1.7.36.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.SimpleLoggerFactory]
Toolbox 0.1.0 (MIMA Runtime 'standalone-static' version 2.4.8)
=======
          Maven version 3.9.6
...

Describe the solution you'd like Somehow to express that i want 'resolve file' and not 'resolve transitively' operation here.

Describe alternatives you've considered I tried to use direct HTTPS URL to Central, like https://repo.maven.apache.org/maven2/eu/maveniverse/maven/plugins/toolbox/0.1.0/toolbox-0.1.0-cli.jar for scriprt-ref, and it did work, kinda, but asked me to "trust" Maven Central, which is kinda nonsense, as when script-ref is G:A:V it resolves from there without asking for "trust".

Additional context ...

[quintesse]

This does indeed seem a reasonable request. @maxandersen wdyt? Or are we perhaps missing a use-case where we would still want to resolve dependencies?

but asked me to "trust" Maven Central, which is kinda nonsense, as when script-ref is G:A:V it resolves from there without asking for "trust".

It's indeed strange that GAVs don't ask you to trust while using a direct link does, unfortunately given the amount of Maven repos/mirrors I don't think we could add those URLs as trusted by default. Should we on the other hand ask the users to trust GAVs? (I remember having had a discussion about executable artifacts with a Maven maintainer some years ago and he told me that the reason Maven doesn't have a feature to run artifacts is because it would make it way too easy for non-developers to run untrusted code... which is basically what we are doing now. Personally I think we should ask to trust)

[maxandersen]

I see this as fetch Gav excluding transitive dependencies.

Which we've discussed in past at https://github.com/jbangdev/jbang/issues/150

The main blocker is figuring out consistent syntax and see if our resolver can do it nicely.

[cstamas]

Resolver calls this "resolve artifact": https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/RepositorySystem.java#L164-L195

[maxandersen]

About the trust - I guess we could expand our trusting to be on repo / groupid / artifact / version level.

So you can trust either all of central all of mavenverse or the specific artifact versions.

[quintesse]

I see this as fetch Gav excluding transitive dependencies.

I thought this could be more of an additional/orthogonal feature, but, @cstamas , I've been looking into the classifiers (eg https://www.baeldung.com/maven-artifact-classifiers) and you can't assume that using a classifier automatically means that you don't need to do any resolving. For example classifiers can be used to support multiple different versions of an artifact (for example for different JDKs or for different OSes) and they would still need their dependencies resolved. So it seems @maxandersen is right and we need some other feature to allow the user to prevent/disable resolving.

I guess we could expand our trusting to be on repo / groupid / artifact / version level.

I see the group/artifact/version as relatively easy, but the repo? Or do you mean that we ask for trust if the user adds a --repo line or if the code has a //REPO line? That shouldn't be too hard. Also if the user has repos defined in their settings.xml we can perhaps assume that they are trusted.

[cstamas]

Agreed, in general "have classifier" should not mean "it does not depend on it's transitive hull". I was more like have some consensus that classifier "uber" or "cli" implies is self contained. Maybe a config?

[maxandersen]

Im not a fan of magic classifier.

Some modifier for the Gav expression would be nice so can use it both in //deps and commandline.

[cstamas]

On a related note... in Maven4: https://github.com/apache/maven/pull/1459