Oh, and just as "dependency reduced pom", the flatten does not work within
the reactor _either_.
In fact, the existence of a flatten plugin per se is an IMHO sign that
"something is wrong" here.
Thanks
T
On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau
wrote:
> Hmm, new types are not a real
Romain, the "fat" flag was always present, since Maven 3.0 (with
introduction of resolver).
Really, nothing new here. Even you already use it (without knowing).
Resolver is (and was) abused currently (see my other mail), this is more to
unleash its potential instead.
T
On Tue, Oct 31, 2023 at 12
Hmm, new types are not a real option for that, it is fully the lifecycle
(plugin chain thesz days since lifecycles are never rich enough and it
depends too much on projects.
Your fatjar example is not a type but the flatten plugin presence and it is
really not a type cause it implies a specific po
Hi,
we solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621&version=12353789
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPMD%20AND%20resolution%20%3D%20Unresolved
Staging repo:
https://reposit
... makes resolver STOP _whatever_ the referenced POM list as dependencies
(basically does not matter, the node once collected will NOT dive into
getting possible children).
T
On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák wrote:
> The fat* mechanism is already present even in maven 3.9, but n
The fat* mechanism is already present even in maven 3.9, but not so visible:
https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51
Is "fat" when this method returns true.
Moreover, the new type would give you (as a
Howdy,
The fat* is needed to STOP resolver resolving further external dependencies
(or in-reactor ones), it gives you more control to _express_ this case to
Maven.
Typical case:
- you have in reactor "uber" JAR built (with replace POM set)
- hence, you deploy the rewritten POM, so for consumers y
Canceling the vote because a regression has surfaced. I will respin shortly.
M
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
I don't understand fatjar and fatmodule. Why would we need that? How would
maven treat this different from a regular jar / module ?
-h
On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák wrote:
> Howdy,
>
> The current draft of types we want to introduce (and packaging):
> https://gist.github.co
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 == impor
the thing is modules are one example but you also have several plugin
related dependencies (living doc one is a common example I hit and I
workaround with provided or test but this is wrong, another one can be a
generator plugin, but most common ones are assembler plugins where sets
enable to toggl
Modules are just regular dependencies that need to end up on the module
path instead of the classpath. Creating a new section in the pom (with all
its pains, because it would not just be "modules" but also
"moduleManagement", akin to "dependencyManagement") is IMHO a really bad
idea. Also, "module"
Howdy,
Here is an issue I initially created for Resolver 2.0.0 to fix some
believed bugs, edge cases:
https://issues.apache.org/jira/browse/MRESOLVER-391
For impatiens: you can find TL;DR at the end.
But so far it turned out that -- while user facing issues do exist -- they
stem from littered ma
13 matches
Mail list logo
