Re: war plugin incompatibility
I think that I have fixed this problem by adding the following stanza to the maven war plugin descriptor: false On 11/9/23 2:46 PM, Rick Hillegas wrote: I am trying to install a Derby release into my local maven repository. The world has changed underneath me in the last year and a half since I published the last Derby release. The Derby maven-based publication poms can be found under https://svn.apache.org/repos/asf/db/derby/code/trunk/maven2/ The Derby publication poms don't do much. They just sign the Derby artifacts and copy them into the repository. No jars or wars are actually built by the publication poms. That happens elsewhere. On my first attempt, I used the maven version I used a year and a half ago: 3.8.6. One of the Derby artifacts is a war file and its associated publication pom contained this plugin stanza: org.apache.maven.plugins maven-war-plugin 2.1.1 When I executed a top level mvn clean install the command failed with the following error: [WARNING] Error injecting: org.apache.maven.plugin.war.WarMojo com.google.inject.ProvisionException: Unable to provision, see the following errors: 1) Error injecting constructor, java.lang.ExceptionInInitializerError: Cannot access defaults field of Properties at org.apache.maven.plugin.war.WarMojo.(Unknown Source) while locating org.apache.maven.plugin.war.WarMojo followed at the end by [ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project derbywar: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Unable to load the mojo 'war' in the plugin 'org.apache.maven.plugins:maven-war-plugin:2.1.1' due to an API incompatibility: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Cannot access defaults field of Properties So I upgraded maven to version 3.9.5 and I upgraded the war plugin stanza to specify maven plugin version 3.3.1. Now "mvn clean install" raises the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:3.3.1:war (default-war) on project derbywar: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) -> [Help 1] Since all I am doing is signing jars and wars, I don't think that a web.xml file should be required. I would appreciate your advice for how to get over this speedbump. Thanks, -Rick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
war plugin incompatibility
I am trying to install a Derby release into my local maven repository. The world has changed underneath me in the last year and a half since I published the last Derby release. The Derby maven-based publication poms can be found under https://svn.apache.org/repos/asf/db/derby/code/trunk/maven2/ The Derby publication poms don't do much. They just sign the Derby artifacts and copy them into the repository. No jars or wars are actually built by the publication poms. That happens elsewhere. On my first attempt, I used the maven version I used a year and a half ago: 3.8.6. One of the Derby artifacts is a war file and its associated publication pom contained this plugin stanza: org.apache.maven.plugins maven-war-plugin 2.1.1 When I executed a top level mvn clean install the command failed with the following error: [WARNING] Error injecting: org.apache.maven.plugin.war.WarMojo com.google.inject.ProvisionException: Unable to provision, see the following errors: 1) Error injecting constructor, java.lang.ExceptionInInitializerError: Cannot access defaults field of Properties at org.apache.maven.plugin.war.WarMojo.(Unknown Source) while locating org.apache.maven.plugin.war.WarMojo followed at the end by [ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war (default-war) on project derbywar: Execution default-war of goal org.apache.maven.plugins:maven-war-plugin:2.1.1:war failed: Unable to load the mojo 'war' in the plugin 'org.apache.maven.plugins:maven-war-plugin:2.1.1' due to an API incompatibility: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Cannot access defaults field of Properties So I upgraded maven to version 3.9.5 and I upgraded the war plugin stanza to specify maven plugin version 3.3.1. Now "mvn clean install" raises the following error: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-war-plugin:3.3.1:war (default-war) on project derbywar: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) -> [Help 1] Since all I am doing is signing jars and wars, I don't think that a web.xml file should be required. I would appreciate your advice for how to get over this speedbump. Thanks, -Rick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: finding source of outdated dependencies
Ah! So, reading between the lines, you're recommending that I issue this command: mvn help:effective-pom -Dverbose=true I didn't know there was a `verbose` option for the effective POM that had anything to do with dependency management. Thanks. That gives me effective dependency management, along with the POM it comes from—even with line numbers. Nice! And (drumroll …) it looks like `biz.aQute.bnd:biz.aQute.bnd.annotation:6.4.1` is coming from `org.apache.logging:logging-parent:10.1.1`. And `org.mockito:mockito-inline:4.8.1` was getting in because one of my own dependencies hasn't been updated to use my newer root POM, which manages the versions of testing libraries. hehe It's good to find out—and now to know /how/ to find out. Thanks, Tamás. Garret On 11/9/2023 5:25 PM, Tamás Cservenák wrote: Well, depMgt is "flattened" (so if depMgt import of POM imports another POM and ...), and if you use verbose with effective, you will see the source of flattened things, at least T On Thu, Nov 9, 2023 at 9:18 PM Garret Wilson wrote: On 11/9/2023 5:10 PM, Tamás Cservenák wrote: Howdy, Did you try to take a peek at effective POM? Hi. The effective POM doesn't show me anything helpful—and I don't know that I expected it to. The effective POM simple resolves the inheritance tree, right? I don't know if that would have any relationship to transitive dependency management. But also,https://issues.apache.org/jira/browse/MPH-183 So that seems to be a suggestion someone made to make the effective POM show something about dependency management, but was never finished/integrated? Garret On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson wrote: In my Maven project (an aggregate project with child projects) I issue the following command for the Versions Maven Plugin: mvn versions:display-dependency-updates There are a couple of outdated dependencies I'm not sure where are coming from: [INFO] The following dependencies in Dependency Management have newer versions: [INFO] biz.aQute.bnd:biz.aQute.bnd.annotation 6.4.1 -> 7.0.0 [INFO] org.mockito:mockito-inline 4.8.1 -> 5.2.0 Unfortunately, try as I might, I can't find which library references these. I've tried the following with the Maven Dependency Plugin, both in the root project and in child projects: mvn dependency:tree None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or `org.mockito:mockito-inline`. The two suspects are: * `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or `org.apache.logging.log4j:log4j-bom:2.21.1` (for `biz.aQute.bnd:biz.aQute.bnd.annotation`) * `com.fasterxml.jackson:jackson-bom:2.15.3` (for `org.mockito:mockito-inline`) But those are just suspicions based upon the additional dependency management I have in the subprojects where those outdated dependencies show up. Is there any command I can use to find out which dependency is bringing in the outdated dependencies listed by the Versions Maven Plugin? Thanks, Garret - To unsubscribe,e-mail:users-unsubscr...@maven.apache.org For additional commands,e-mail:users-h...@maven.apache.org
Re: finding source of outdated dependencies
You can try: mvn versions:display-dependency-updates -DprocessDependencyManagementTransitive=false https://www.mojohaus.org/versions/versions-maven-plugin/display-dependency-updates-mojo.html#processDependencyManagementTransitive czw., 9 lis 2023 o 21:04 Garret Wilson napisał(a): > > In my Maven project (an aggregate project with child projects) I issue > the following command for the Versions Maven Plugin: > > mvn versions:display-dependency-updates > > There are a couple of outdated dependencies I'm not sure where are > coming from: > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] biz.aQute.bnd:biz.aQute.bnd.annotation 6.4.1 > -> 7.0.0 > [INFO] org.mockito:mockito-inline 4.8.1 > -> 5.2.0 > > Unfortunately, try as I might, I can't find which library references > these. I've tried the following with the Maven Dependency Plugin, both > in the root project and in child projects: > > mvn dependency:tree > > None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or > `org.mockito:mockito-inline`. > > The two suspects are: > > * `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or > `org.apache.logging.log4j:log4j-bom:2.21.1` (for > `biz.aQute.bnd:biz.aQute.bnd.annotation`) > * `com.fasterxml.jackson:jackson-bom:2.15.3` (for > `org.mockito:mockito-inline`) > > But those are just suspicions based upon the additional dependency > management I have in the subprojects where those outdated dependencies > show up. > > Is there any command I can use to find out which dependency is bringing > in the outdated dependencies listed by the Versions Maven Plugin? > > Thanks, > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > -- Sławomir Jaranowski - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: finding source of outdated dependencies
Well, depMgt is "flattened" (so if depMgt import of POM imports another POM and ...), and if you use verbose with effective, you will see the source of flattened things, at least T On Thu, Nov 9, 2023 at 9:18 PM Garret Wilson wrote: > On 11/9/2023 5:10 PM, Tamás Cservenák wrote: > > Howdy, > > > > Did you try to take a peek at effective POM? > > Hi. The effective POM doesn't show me anything helpful—and I don't know > that I expected it to. The effective POM simple resolves the inheritance > tree, right? I don't know if that would have any relationship to > transitive dependency management. > > > But also,https://issues.apache.org/jira/browse/MPH-183 > > So that seems to be a suggestion someone made to make the effective POM > show something about dependency management, but was never > finished/integrated? > > Garret > > > On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson > > wrote: > > > >> In my Maven project (an aggregate project with child projects) I issue > >> the following command for the Versions Maven Plugin: > >> > >> mvn versions:display-dependency-updates > >> > >> There are a couple of outdated dependencies I'm not sure where are > >> coming from: > >> > >> [INFO] The following dependencies in Dependency Management have newer > >> versions: > >> [INFO] biz.aQute.bnd:biz.aQute.bnd.annotation 6.4.1 > >> -> 7.0.0 > >> [INFO] org.mockito:mockito-inline 4.8.1 > >> -> 5.2.0 > >> > >> Unfortunately, try as I might, I can't find which library references > >> these. I've tried the following with the Maven Dependency Plugin, both > >> in the root project and in child projects: > >> > >> mvn dependency:tree > >> > >> None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or > >> `org.mockito:mockito-inline`. > >> > >> The two suspects are: > >> > >> * `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or > >> `org.apache.logging.log4j:log4j-bom:2.21.1` (for > >> `biz.aQute.bnd:biz.aQute.bnd.annotation`) > >> * `com.fasterxml.jackson:jackson-bom:2.15.3` (for > >> `org.mockito:mockito-inline`) > >> > >> But those are just suspicions based upon the additional dependency > >> management I have in the subprojects where those outdated dependencies > >> show up. > >> > >> Is there any command I can use to find out which dependency is bringing > >> in the outdated dependencies listed by the Versions Maven Plugin? > >> > >> Thanks, > >> > >> Garret > >> > >> > >> - > >> To unsubscribe, e-mail:users-unsubscr...@maven.apache.org > >> For additional commands, e-mail:users-h...@maven.apache.org > >> > >>
Re: finding source of outdated dependencies
On 11/9/2023 5:10 PM, Tamás Cservenák wrote: Howdy, Did you try to take a peek at effective POM? Hi. The effective POM doesn't show me anything helpful—and I don't know that I expected it to. The effective POM simple resolves the inheritance tree, right? I don't know if that would have any relationship to transitive dependency management. But also,https://issues.apache.org/jira/browse/MPH-183 So that seems to be a suggestion someone made to make the effective POM show something about dependency management, but was never finished/integrated? Garret On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson wrote: In my Maven project (an aggregate project with child projects) I issue the following command for the Versions Maven Plugin: mvn versions:display-dependency-updates There are a couple of outdated dependencies I'm not sure where are coming from: [INFO] The following dependencies in Dependency Management have newer versions: [INFO] biz.aQute.bnd:biz.aQute.bnd.annotation 6.4.1 -> 7.0.0 [INFO] org.mockito:mockito-inline 4.8.1 -> 5.2.0 Unfortunately, try as I might, I can't find which library references these. I've tried the following with the Maven Dependency Plugin, both in the root project and in child projects: mvn dependency:tree None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or `org.mockito:mockito-inline`. The two suspects are: * `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or `org.apache.logging.log4j:log4j-bom:2.21.1` (for `biz.aQute.bnd:biz.aQute.bnd.annotation`) * `com.fasterxml.jackson:jackson-bom:2.15.3` (for `org.mockito:mockito-inline`) But those are just suspicions based upon the additional dependency management I have in the subprojects where those outdated dependencies show up. Is there any command I can use to find out which dependency is bringing in the outdated dependencies listed by the Versions Maven Plugin? Thanks, Garret - To unsubscribe, e-mail:users-unsubscr...@maven.apache.org For additional commands, e-mail:users-h...@maven.apache.org
Re: finding source of outdated dependencies
Howdy, Did you try to take a peek at effective POM? But also, https://issues.apache.org/jira/browse/MPH-183 T On Thu, Nov 9, 2023 at 9:04 PM Garret Wilson wrote: > In my Maven project (an aggregate project with child projects) I issue > the following command for the Versions Maven Plugin: > > mvn versions:display-dependency-updates > > There are a couple of outdated dependencies I'm not sure where are > coming from: > > [INFO] The following dependencies in Dependency Management have newer > versions: > [INFO] biz.aQute.bnd:biz.aQute.bnd.annotation 6.4.1 > -> 7.0.0 > [INFO] org.mockito:mockito-inline 4.8.1 > -> 5.2.0 > > Unfortunately, try as I might, I can't find which library references > these. I've tried the following with the Maven Dependency Plugin, both > in the root project and in child projects: > > mvn dependency:tree > > None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or > `org.mockito:mockito-inline`. > > The two suspects are: > > * `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or > `org.apache.logging.log4j:log4j-bom:2.21.1` (for > `biz.aQute.bnd:biz.aQute.bnd.annotation`) > * `com.fasterxml.jackson:jackson-bom:2.15.3` (for > `org.mockito:mockito-inline`) > > But those are just suspicions based upon the additional dependency > management I have in the subprojects where those outdated dependencies > show up. > > Is there any command I can use to find out which dependency is bringing > in the outdated dependencies listed by the Versions Maven Plugin? > > Thanks, > > Garret > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
finding source of outdated dependencies
In my Maven project (an aggregate project with child projects) I issue the following command for the Versions Maven Plugin: mvn versions:display-dependency-updates There are a couple of outdated dependencies I'm not sure where are coming from: [INFO] The following dependencies in Dependency Management have newer versions: [INFO] biz.aQute.bnd:biz.aQute.bnd.annotation 6.4.1 -> 7.0.0 [INFO] org.mockito:mockito-inline 4.8.1 -> 5.2.0 Unfortunately, try as I might, I can't find which library references these. I've tried the following with the Maven Dependency Plugin, both in the root project and in child projects: mvn dependency:tree None of the output mentions `biz.aQute.bnd:biz.aQute.bnd.annotation` or `org.mockito:mockito-inline`. The two suspects are: * `com.amazonaws:aws-lambda-java-log4j2:1.6.0` or `org.apache.logging.log4j:log4j-bom:2.21.1` (for `biz.aQute.bnd:biz.aQute.bnd.annotation`) * `com.fasterxml.jackson:jackson-bom:2.15.3` (for `org.mockito:mockito-inline`) But those are just suspicions based upon the additional dependency management I have in the subprojects where those outdated dependencies show up. Is there any command I can use to find out which dependency is bringing in the outdated dependencies listed by the Versions Maven Plugin? Thanks, Garret - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Keeping java's version in sync with project's version
Hi Joseph!
Not really sure what you mean by "keep java's version in sync".
Since you said "-version option on my project", I am guessing you have
a CLI app and you want to report the version which you specify in your
pom.xml file.
Now to do that and have it working with your project, here are the
steps I usually take.
This is just an extended version of what Alex already wrote.
If you have a multi-module project, and you want to access your
project version in many other modules, just create a dedicated module.
You can also apply the steps to a single-module project.
This module should have a class in its own package (Maybe Version.java).
It should load a file "version.properties" from the src/main/resources folder.
Now the trick: put it into the same directory structure as your
Version.java file's package.
For the file to get populated, add this line:
my.project.version=${project.version}
Now, enable resource filtering for your project [1].
When building the project, you should see the filtered file:
${module}/target/classes/path/to/package/version.properties (next
to the compiled Version.class).
In your Version.java, load the file using the standard Properties
mechanism and expose the version via a simple getter.
This way you can use the version in other modules, too.
If you want to add other properties, you can add plugins like the
build-number-maven-plugin to your build.
This way you do not need to rely on parsing xml or property files
which may be out of scope for your classes.
HTH,
- Ben
[1] -
https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html
Am Do., 9. Nov. 2023 um 01:18 Uhr schrieb Joseph Kessselman
:
>
> For obvious reasons, if would be nice if the -version option on my
> project automatically reported the version I'd set in the pom.xml rather
> than my trying to synchronize the two manually.
>
> The best approaches I've found so far are in
> https://stackoverflow.com/questions/2712970/get-maven-artifact-version-at-runtime
> ... but there's a note that at least one of them doesn't work in all
> classloaders, or in openjdk.
>
> I'm willing to have the pom write this into a file that the Java code
> would query, if that's what it takes to have a portable solution, but
> I'm not sure what the best way to express that would be.
>
>
> There must be an established Best Practices solution for this, right?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Keeping java's version in sync with project's version
I'll just mention that I've used the file referenced in the StackOverflow
question, META-INF/maven/${groupId}/${artifactId}/pom.properties, before to
do something much like you describe, print my application version to the
log at startup.
It did not need any special configuration to appear, and only took a
handful of lines to getResourceAsStream(), load into a Properties object,
and ask pomProperties.getProperty("version","development"). 'development'
is a safety default here for when the project is running in a context
before being packaged, like testing.
Now, how does pom.properties get populated? Will it always be populated?
Will this still work in a Java 9+/JPMS/Maven 4+ world? Unspecified,
exercise for the reader.
