Very happy to report that this was resolved in the just-released 3.3.0. See
https://issues.apache.org/jira/browse/MDEP-761. Verbose dependency tree
works great now! Thanks to everyone who worked on it, including Ian
Lavallee for reimplementing it for Maven 3 and Filipe Roque for the fix so
that it
This is also common at my workplace, with the resolution always being to
delete the empty file and try again. We haven't nailed down a
reproducible way to cause it, but it does seem to happen more often when
network conditions are flaky. I agree that deleting the file would be a
user-friendly thing
e.org%3E
The conclusion was also that there's no great way to accomplish this. I
think one good way to fix this issue would be to have Maven resolve
test-scoped dependencies transitively when you depend on test-jars, but
perhaps there's a good reason why that's not practical or not a good idea.
--
Andy Feldman
--
Andy Feldman
On Mon, May 3, 2021 at 3:43 PM Compte Messagerie <
informatique.e...@gmail.com> wrote:
> hello,
> i try to install dspace 6.3 on centos 8 with apache-maven-3.8.1 and
> java-11.0.11
> when i start the command:
>
> $mvn package -X
(TreeMojo.java:276)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[...]
--
Andy Feldman
On Mon, May 3, 2021 at 6:49 AM Enrico Olivelli wrote:
> Nick,
> are you able to see what is doing Maven in those 30 minutes ?
>
> you can run with the "-X" flag to see Mave
Yes, the release plugin works fine on just one module. That's exactly what
we do, using the --projects (-pl) flag to only build the module(s) we want
to release, in combination with release:prepare release:perform. You could
probably achieve the same thing by running Maven from the submodule
direct
n only checks would be
skipped, but if you set -Denforcer.skip=true, it would also cause
skipChecks to be true, so both executions would be skipped. I haven't
actually tested it though.
--
Andy Feldman
mmand
line. But like I said, I haven't tried this approach so you'd have to
experiment and see if it works for you.
On Mon, Sep 14, 2020 at 10:38 AM Andy Feldman wrote:
> I agree this behavior is unexpected. But it's different for properties! So
> a workaround here is to have
I agree this behavior is unexpected. But it's different for properties! So
a workaround here is to have a unique property for each check you want to
skip, so that you can override the property by command line rather than
overriding the configuration directly. Then you can have a single
way to set
his by excluding the netty-common dependency
from bookkeeper-common and running dependency:tree again, which actually
you said you did as well, so I'm curious what we did differently.
Anyway, I hope this helps!
--
Andy Feldman
Wealthfront
On Tue, May 26, 2020 at 11:59 AM Debraj Manna
wrote:
removing the dependency on bookkeeper-common and running
dependency:tree again to see if netty-common still shows up.
--
Andy Feldman
Wealthfront
Would `mvn dependency:tree -Dverbose -Dincludes=grpc-api` work in this
case? The documentation uses it in a very similar situation, to find out
the transitive dependency path to two different versions of the same
dependency:
https://maven.apache.org/plugins/maven-dependency-plugin/examples/resolvin
.html#Project_Inheritance
Where did you get the version 0.0.1-20190903.165620-1 from? Is the parent
artifact already published to a Maven repo? In that case, you would instead
want , which tells it to look in a repo for the parent.
Hope that helps,
--
Andy Feldman
On Tue, Sep 3, 2019 at 4:42 PM Nel
I have observed similar behavior with the version number. My conclusion was
that dependencyManagement is not transitive.
Example of what I observed: I have a project my-library with transitive
dependencies on 3rd-party-library version 1.1 and 1.2 that would normally
resolve to 1.1. I use dependenc
I agree that this behavior seems risky. It's especially bad that the issue
cannot be caught in unit tests, even those which cover the code paths in Y
that call X.
I don't think the idea of manually checking the dependency tree is
realistic for larger projects, but the enforcer plugin seems perfect
On Dec 26, 2017 11:34, "Stephen Connolly"
wrote:
On Sun 24 Dec 2017 at 18:01, Andy Feldman wrote:
> Assuming I have a dependency relationship of "my-project -> my-library ->
> upstream-library", with each dependency in compile scope, I know that
> my-proj
hat I can get the intended behavior? I want
upstream-library to be picked up as runtime scope for my-project, not as
compile scope.
Thanks,
--
Andy Feldman
17 matches
Mail list logo