If the current standard type would be "dependency", this would work IMHO.
It is not. It is "jar". This is perceived as "packaging", not a specific
semantic type that represents "dependency").
A bom is "type == pom, scope == import" which is a special case. If this
were "type == bom, scope == import" and maps onto "pom file" (extension ==
pom), this would make sense. It does not.
In the same vein, the type == "test-jar" should not be that. It should be
"tests" (because test-jar implies the packaging already). And it is unclear
to me what we should do if a type is given (e.g. "jar" which implies
dependency) but then a classifier ("tests"). All the semantics here are
muddled up.
All the "type / classifier" -> "extension" translation is ad hoc, there are
no defined rules anywhere. I think we could create this (for maven 4? maven
5?) but we can not retcon this for Maven 3 where type is a mixture between
"purpose" (dependency) and "packaging" (jar).
A dependency IMHO consists of
* gav -> coordinates of the artifact
* scope -> scope in which the artifact is valid
* "packaging" -> defines how the artifact is packaged if it is possible to
have multiple styles. At the minimum, we need to support "jar" and "file".
The default packaging may be controlled by the type but can be overridden.
I don't like "extension" because it implies that the collection of bytes on
disk has a specific name.
* "type" -> semantic type of the artifact. Default should be "dependency"
* "variant" to select a specific variant of an artifact. E.g. "x86_64" or
"arm64" for native artifacts.
"classifier" I think is the main problem. Today it serves double-duty as
"variant" but also affects the final name of the file on disk. Changing
the classifier actually affects the type, which it should not. But on the
other hand, setting the type should affect the final name on disk as well.
(e.g. type == "test-jar" would turn the name into
"artifact-version-tests.packaging-specific-extension"
It would be nice to fix all of this, but then again, what we have today is
so deeply entrenched in 20+ years of maven ecosystem, that I am not sure
that it can be done without breaking compatibility.
-h
On Sat, Oct 28, 2023 at 3:27 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> So, basically this is what am proposing:
> https://gist.github.com/cstamas/76f262538b5a11f6ee23d6d8c86f10ec
>
> Basically, Maven core (and hence plugins) could distinguish among different
> "types" of dependencies (while would all still be plain JARs).
> So "jar" would be put on classpath, "module" on module path, "agent" would
> got special treatment and so on.
>
> Point is to _differentiate_.
>
> T
>
> On Sun, Oct 29, 2023 at 12:21 AM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
> > Unsure from where you get that, but is wrong conclusion.
> >
> > You can have dep1:jar, dep2:module, dep3:agent and all 3 MAY
> > (ArtifactHandler dependent, assuming "jar", "module" and "agent" artifact
> > handlers all return extension=jar) refer to the same JAR file in your
> local
> > repository.
> >
> > Type merely adds "semantics" WHAT is it about, HOW to make use of it.
> > Please see
> >
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
> >
> > Thanks
> > T
> >
> > On Sun, Oct 29, 2023 at 12:17 AM Martin Desruisseaux <
> > martin.desruisse...@geomatys.com> wrote:
> >
> >> Le 2023-10-28 à 22 h 54, Tamás Cservenák a écrit :
> >>
> >> > I still see these just as new dependency types: "module", "agent",
> >> > "doclet", and so on.
> >> >
> >> Does "dependency type" means the <type> element inside <dependency>? If
> >> yes, then specifying a different type causes Maven to download a
> >> different JAR, without changing the kind of path (class path versus
> >> module path) where the JAR is put. The proposed <usage> element (or
> >> whatever equivalent alternatives) has the opposite semantic: it does not
> >> change the JAR to download, but put it on a different kind of path.
> >>
> >> Martin
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
>
