> where properties are totally extensible,
And if now I could supply additional properties from the xml-model ...
Am 29.10.23 um 00:40 schrieb Tamás Cservenák:
And finally this is hardly gonna happen in Maven 3 lifespan, as sadly
ArtifactHandler of it is quite limited: has only one flag:
https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
Sadly, Maven4 Type continued on this path, but luckily we are in alpha, and
will propose a PR to type that currently looks like this:
https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80
And would rework it to be more (if not same as) the resolver ArtifactType:
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java#L63
where properties are totally extensible, for example "add to classpath" is
really just one flag (added by ArifactType):
https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L58
So, ArtifactProperties could be extended with "constitutesModulePath",
"agent" and so on... To make this really extensible.
In maven3 the ArtifactHandler this makes it impossible. There is still hope
in Maven 4
Thanks
T
On Sun, Oct 29, 2023 at 12:32 AM Tamás Cservenák <ta...@cservenak.net>
wrote:
This would also mean, that if you have a dependency that is already JPMS
modularized (is java9+ and has module-info), then:
a) if you declare it as type="jar" it means you want to put it on
classpath (use it as "plain old jar")
b) if you declare it as type="module" it means you want it on modulepath
etc
On Sun, Oct 29, 2023 at 12:30 AM Tamás Cservenák <ta...@cservenak.net>
wrote:
Of course, the logic HOW and WHAT to make with these would be needed to
be added to javadoc, compiler and all the plugins that need to distinguish.
But this would stop any need for any heuristic, guesswork, smart-ness,
etc...
OTOH, if we introduce new packaging lifecycle "module" (so a project that
builds module would do project/packaging=module), it could nicely enforce
things like:
- prevent non allowed packages
- enforce presence of module-info.class (maybe some light verification)
- ensure project is Java9+ etc
Most of this was somewhat done in Takari Lifecycle (also with custom
packaging like "takari-jar" was).
T
On Sun, Oct 29, 2023 at 12:26 AM 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
