Howdy,
0.1.3 out, got unpack ability (actually UnpackSink). Here is 0.1.3 in
action, doing "side-by-side" and "overlay" way of unpack:
https://gist.github.com/cstamas/36c49da724100a19feab1397e7381d0f
Oh, and Martin, the sink also unpacks only "unique" artifacts, so it will
not
Oh, and as a side effect, the plugin is way more snappier as well, look at
execution time diffs (I know, this is not "benchmark", but is telling):
https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51
toolbox needs almost only 60% of runtime that m-dep-p have.
T
On Tue, Mar 26, 2024
Rudimentary support for those is already present (equals, startWith,
endsWith) :)
So one can write ArtifactMatcher "spec expression" (that will be parsed
into ArtifactMatcher that is actually Predicate) as:
"artifact(gavoid)"
where "gavoid" can be "string" or "g:a" or "g:a:v" etc
Each field
Thanks Tamas for all your work. I'll sure have a look (but not right now as
I'm in a train station on a phone). Just to mention a feature I missed
yesterday in m-d-p: ability to filter on classifiers including *wildcards*.
Because I have dependencies with this kind of classifiers: natives-win,
Just for those brave... if you toy with it.
The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec"
parameters, that are parsed into ArtifactSink here:
Howdy,
Yes, m-dep-p is under maintained, it actually would need a rewrite as it
still uses MAT (and many other Maven2 archaic stuff) internally.
Hence, it will fail if used with 3.9+ features like "split repository" and
is suboptimal in many areas.
Toolbox 0.1.0 released, btw:
jbang
Hello Tamás,
For context, what are the tensions that you're trying to solve here?
Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink?
Do some goals feel like a bad fit?
Are you thinking of breaking it up or replacing it?
Greg
On Tue, Mar 26, 2024 at 8:52 AM Tamás
Howdy,
just to not let this discussion die off. Let me show a take on a "how
modern Maven plugin should look like" (that targets m-dependency-p goals,
sans analyze and some others) could look like:
https://github.com/maveniverse/toolbox
The "unpack" related goals are missing, not yet done, but
Yes, all of them.
purge-local-repository I use very often in Jenkins pipelines to clean up
afterwards.
Over the years I build a lot of pipelines, added checks to projects and so on.
The dependency plugin was very often my rescue. I can't remember each single
usage and project and its
I most frequently use tree and analyze, but have used others like the copy* and
unpack* goals, too.
I do miss an equivalent to tree for plugin dependencies.
--
Alexander Kriegisch
https://scrum-master.de
Tamás Cservenák schrieb am 21.03.2024 17:04 (GMT +01:00):
> I'd would be interested in
Many downstream package maintainers use :go-offline to build packages offline
in a container w/o outbound network access.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail:
czw., 21 mar 2024 o 20:54 Tamás Cservenák napisał(a):
> Howdy,
>
> What is the use case of "go offline"?
>
For me - I use go-offline to prefetch local repo.
I have a simple project which have a common dependencies like spring-boot
and some home made other commons dependencies in company,
On
Hey !
First of all, for everyone asking more info to understand where the pom
values come from and how they are computed, I think a very useful command
is:
**
mvn org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom
Greg,
For example, we recently converted the TrinoDB (
https://github.com/trinodb/trino) build, removed their use of "go offline"
So am just interested in any other patterns out there.
T
On Thu, Mar 21, 2024 at 9:40 PM Greg Chabala wrote:
> I do have an example at hand, though I am not sure I
I do have an example at hand, though I am not sure I would advocate for it:
https://blog.frankel.ch/faster-maven-builds/2/
There are undoubtedly better ways to achieve the author's goals, but I'm
not sure that's the fault of dependency:go-offline.
On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák
Greg,
would like to see such a project, do you have any examples at hand?
Am sure there are much simpler/better/more correct ways to do the same
thing.
T
On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala wrote:
> My understanding is dependency:go-offline is an effective way to
> pre-download
My understanding is dependency:go-offline is an effective way to
pre-download plugins and dependencies, for instance if one is making some
layer in a docker build container for later reuse.
On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák wrote:
> Howdy,
>
> What is the use case of "go offline"?
So,
in Maven2, the local repo was really "just a bunch of files" (totally wild
west).
With Maven3, and Resolver (yes, this is true from 3.0) the "enhanced" local
repository is used, that tries to "track" origin (of cached, not installed)
artifacts.
In Maven 3.9 the next step is made, which is a
Howdy,
What is the use case of "go offline"?
That is yet another goal coming from "Maven2 era" and messes up your local
repository (wrt back tracing dependencies,
https://issues.apache.org/jira/browse/MNG-7619)
I mean, if you do a build (w/o tests, or skipping most time stealing
steps), like "dry
+1 to this list from Slawomir:
- dependency:analyze / dependency:analyze-only
- dependency:copy
- dependency:copy-dependencies
- dependency:go-offline
- dependency:list
- dependency:tree
- dependency:unpack
- dependency:unpack-dependencies
On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski
Like a couple of other folks 90% of my usage is dependency:analyze and
dependency:tree. Other goals I barely notice.
On Thu, Mar 21, 2024 at 12:06 PM Tamás Cservenák wrote:
>
> Howdy,
>
> I'd would be interested in how users and devs are using
> maven-dependency-plugin:
>
Agreed,
Use of "purge-local-repository" is a very bad thing (next to "go offline"
and related goals).
They all come from the "maven2 era", and should never be used with Maven3...
T
On Thu, Mar 21, 2024 at 7:50 PM Richard Eckart de Castilho
wrote:
>
> > On 21. Mar 2024, at 19:43, Tamás
Hi
I use:
- dependency:analyze / dependency:analyze-only
- dependency:copy
- dependency:copy-dependencies
- dependency:go-offline
- dependency:list
- dependency:tree
- dependency:unpack
- dependency:unpack-dependencies
czw., 21 mar 2024 o 17:06 Tamás Cservenák napisał(a):
> Howdy,
>
> I'd
> On 21. Mar 2024, at 19:43, Tamás Cservenák wrote:
>
> I mean, I know what those goals do, I am just unsure WHY you needed those.
The current Apache UIMA release guidelines still list them as suggested steps
to perform before a local trial build to ensure locally cached artifacts do
not
Howdy,
Oliver: all, really?
I wonder what you used for goals like "purge-local-repository",
"resolve-plugins" etc :)
I mean, I know what those goals do, I am just unsure WHY you needed those.
T
On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer
wrote:
> Hi,
>
> over the time I used all of
Hi,
over the time I used all of them in different projects and I think all
of them are needed.
Viele Grüße
Oliver
Am 21.03.24 um 17:04 schrieb Tamás Cservenák:
Howdy,
I'd would be interested in how users and devs are using
maven-dependency-plugin:
Hi,
I mostly use the "analyze" (mostly the "analyze-only") and "tree" goals,
but I have also already used "copy/unpack-dependencies", "sources",
"purge-local-repository" and "resolve".
IMHO the "versions" plugin has a few functionalities that feel like could
also belong to the dependencies
Hi
For me it is:
* Tree: human work on transitivity
* List: pre-resolve for the runtime (dump jar list in a file)
* Resolve: CI init phase
Le jeu. 21 mars 2024 à 17:54, Christian Stein a écrit :
> I use the "resolve" goal like this:
>
> mvn --batch-mode --no-transfer-progress
Hey,
mainly tree and analyze (note: we also use enforcer-plugin with some
rules for dependencies)
Greetings
Matthias
Am 21.03.2024 um 17:04 schrieb Tamás Cservenák:
Howdy,
I'd would be interested in how users and devs are using
maven-dependency-plugin:
I use the "resolve" goal like this:
mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt
org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve
...and parse the output for Java module names and whether they are
"automatic".
The tree goal is my go to for this plugin. I also like the analyze.
A wish I have is to get a more clearer view of the resolved dependencies
version with regard to the declared dependencyManagement and/or the
shortest path to dependency.
For example, when I see the dependency slf4j-api with
The one I use the most from the command line is "tree" (
https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html)
I wish I could say "ignore test scope" to help me understand my runtime
dependencies better.
Gary
On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák wrote:
> Howdy,
>
Most of the time I use copy-dependencies goal to build non fat jar
deployments. Meanwhile tree goal helps figure out multimodule dependency
clashes by showing resolved ransitive dependencies.
As for the rest, i can see where and what could use them, but I haven't
used them directly.
On Thu, Mar
33 matches
Mail list logo
