Re: plugin of a plugin
Thanks, I keep forgetting about its custom nature. I've asked before, but do you think its possible for Maven to validate the configuration elements like Intellij does?
Re: What could cause a missing JAR in WEB-INF?
> I have *war that I've built on 3 different Macs (maven-war-plugin 3.3.2). > Is there a reason you're rebuilding your WAR three times on different Macs? > The code is pulled from my local git repo, and the supporting jars are from > a local Nexus repository. Are they all building from the same git branch/ref? Everything is pulled current? > The missing JAR is in each local repository. I do not see this JAR when I > run `mvn dependency:tree`, though I see a different (newer) version as > "provided." Provided means you are in charge of supplying the JAR, not Maven. Typically this means you expect the JAR will already be available at runtime, e.g. in your application server's provided JARs, so there's no point in bundling it into your WAR. Are you certain this is not just a case of having different application server versions installed, or someone manually updated the provided JARs on one of them? > The missing JAR doesn't seem to matter when the webapp runs (no > problems found so far). Any idea as to why, and > what I can (or should?) do for a consistent build? Make sure you're not using version ranges, and that all versions are specified. For more tips, see: https://maven.apache.org/guides/mini/guide-reproducible-builds.html This is all hypothetical, you didn't show/reference a concrete example pom we could look at.
Re: What could cause a missing JAR in WEB-INF?
Have you tried diffing the effective-pom on the various machines? How about running with debug logs? Does the waven-war-plugin maybe outputs why it picks or excludes dependencies from the war? Le ven. 14 avr. 2023 à 21:34, Thad Humphries a écrit : > I have *war that I've built on 3 different Macs (maven-war-plugin 3.3.2). > The code is pulled from my local git repo, and the supporting jars are from > a local Nexus repository. All Macs use the same setup--Amazon Corretto Java > 11 and Maven 3.9.1. The ~/.m2/settings.xml are identical. Two of the Macs > produce the same *war (a Mini with 10.15.7 and a MacBook with 12.6.5). The > third Mac--also a Mini with 10.15.7--is missing one JAR file in > WEB-INF/lib. How can this be? > > The missing JAR is in each local repository. I do not see this JAR when I > run `mvn dependency:tree`, though I see a different (newer) version as > "provided." The missing JAR doesn't seem to matter when the webapp runs (no > problems found so far). Any idea as to why, and what I can (or should?) do > for a consistent build? > > -- > "Hell hath no limits, nor is circumscrib'd In one self-place; but where we > are is hell, And where hell is, there must we ever be" --Christopher > Marlowe, *Doctor Faustus* (v. 111-13) >
What could cause a missing JAR in WEB-INF?
I have *war that I've built on 3 different Macs (maven-war-plugin 3.3.2). The code is pulled from my local git repo, and the supporting jars are from a local Nexus repository. All Macs use the same setup--Amazon Corretto Java 11 and Maven 3.9.1. The ~/.m2/settings.xml are identical. Two of the Macs produce the same *war (a Mini with 10.15.7 and a MacBook with 12.6.5). The third Mac--also a Mini with 10.15.7--is missing one JAR file in WEB-INF/lib. How can this be? The missing JAR is in each local repository. I do not see this JAR when I run `mvn dependency:tree`, though I see a different (newer) version as "provided." The missing JAR doesn't seem to matter when the webapp runs (no problems found so far). Any idea as to why, and what I can (or should?) do for a consistent build? -- "Hell hath no limits, nor is circumscrib'd In one self-place; but where we are is hell, And where hell is, there must we ever be" --Christopher Marlowe, *Doctor Faustus* (v. 111-13)
Re: plugin of a plugin
Hi, doesn't look odd the moment you know plugin authors can name configuration elements anything they want. They could call it , but that doesn't make it an UFO. That said, spotbugs seems to use the findbugs artifact as a dependency in a plugin like manner. They just choose to call it that way. What is odd is: Usually you could just declare plugin dependencies, and they could have discovered them automatically. I don't know why they chose this way instead. tl;dr: it's a custom thing. You cannot declare plugin>config>plugins on any other plugins. HTH On Fri, 14 Apr 2023, 09:44 Delany, wrote: > Hi. Two things look odd here > > > com.github.spotbugs > spotbugs-maven-plugin > 4.7.3.4 > > > > com.h3xstream.findsecbugs > findsecbugs-plugin > 1.12.0 > > > > > Whats the difference between declaring plugins dependencies and declaring > plugin plugins? > Only dependencies are mentioned here: > https://maven.apache.org/guides/mini/guide-configuring-plugins.html > > And why is findsecbugs-plugin-1.12.0.jar copied to > ${project.build.directory} when I run mvn spotbugs:check? > > Kind regards, > Delany >
plugin of a plugin
Hi. Two things look odd here com.github.spotbugs spotbugs-maven-plugin 4.7.3.4 com.h3xstream.findsecbugs findsecbugs-plugin 1.12.0 Whats the difference between declaring plugins dependencies and declaring plugin plugins? Only dependencies are mentioned here: https://maven.apache.org/guides/mini/guide-configuring-plugins.html And why is findsecbugs-plugin-1.12.0.jar copied to ${project.build.directory} when I run mvn spotbugs:check? Kind regards, Delany