Re: enforce module descriptions

[Delany]

Enforcer - I should have known. Thanks

On Fri, 9 Feb 2024, 18:50 Konrad Windszus,  wrote:

> You can probably use
> https://www.mojohaus.org/extra-enforcer-rules/requirePropertyDiverges.html
> to enforce a distinct description per module.
>
> Konrad
>
> > On 9. Feb 2024, at 17:48, Delany  wrote:
> >
> > Yes. I mean, of course, right? Description is like name and artifactId.
> > These should never inherit.
> >
> > On Thu, 8 Feb 2024, 22:42 ,  wrote:
> >
> >>> I also want to require a description for each module.
> >>
> >> you mean enforce a different description in a module vs its parent
> value?
> >>
> >> - Mail original -
> >> De: "Delany" 
> >> À: "Maven Users List" 
> >> Envoyé: Jeudi 8 Février 2024 06:27:55
> >> Objet: enforce module descriptions
> >>
> >> Hi. I'm using enforcer to require a project description
> >> https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
> >>
> >> But I also want to require a description for each module.
> >> The description is inherited so they will always have a description.
> >>
> >> Is this possible?
> >>
> >> Thanks,
> >> Delany
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
>

Re: enforce module descriptions

[Delany]

Yes. I mean, of course, right? Description is like name and artifactId.
These should never inherit.

On Thu, 8 Feb 2024, 22:42 ,  wrote:

> > I also want to require a description for each module.
>
> you mean enforce a different description in a module vs its parent value?
>
> - Mail original -
> De: "Delany" 
> À: "Maven Users List" 
> Envoyé: Jeudi 8 Février 2024 06:27:55
> Objet: enforce module descriptions
>
> Hi. I'm using enforcer to require a project description
> https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html
>
> But I also want to require a description for each module.
> The description is inherited so they will always have a description.
>
> Is this possible?
>
> Thanks,
> Delany
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

enforce module descriptions

[Delany]

Hi. I'm using enforcer to require a project description
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html

But I also want to require a description for each module.
The description is inherited so they will always have a description.

Is this possible?

Thanks,
Delany

Re: deploying java app

[Delany]

Hi Peter,

Firstly, compile and package are part of the same lifecycle (the default
lifecycle), so its not necessary to specify both.

Then you can add this profile to your pom so you don't have to run the
dependency plugin separately.


  dispatch
  
${project.artifactId}
  

  maven-dependency-plugin
  

  copy-artefacts
  install
  
copy
  
  

  
${project.groupId}
${project.artifactId}
${project.version}
${project.packaging}
  

/mnt/remote_app/
  

  
copy-dependencies
install

  copy-dependencies


  /mnt/remote_app/libs/
  false
  false
  true
  true
  runtime

  


  
  


Build with `mvn clean install -Pdispatch`

Regards,
Delany

On Tue, 31 Oct 2023 at 17:33, Peter Carlson  wrote:

> I currently use the below commands to prepare my java application:
>
> mvn clean compile package dependency:copy-dependencies
>
> Then I manually copy the files with:
>
>cp target/myapp-1.0-SNAPSHOT.jar /mnt/remote_app/myapp.jar
>cp target/dependency/* /mnt/remote_app/libs/
>
> I'm wondering:
>
> 1) what plugin would be best to do the copy command for me?
>
> 2) is there a single command I can do to perform all the tasks above?
>
> Peter
>
>

Re: passing compiler args via a properties file

[Delany]

Thank you. Its not happening though. I also tried it from the pom, so
-Xplugin:ErrorProne
-XepExcludedPaths:.*/target/.* @${build.root}/ep.config

Made more difficult by lack of visibility what's going on with the javac
processors.


On Sun, 24 Sept 2023 at 16:23, Stanimir Stamenkov
 wrote:

> [With some more context from the original message.]
>
> Sun, 24 Sep 2023 15:45:49 +0200, /Stanimir Stamenkov/:
> > Sun, 24 Sep 2023 15:45:49 +0200, /Delany/:
> >
> >> I can also quickly run a build to catch on issue
> >> that I'm trying to eradicate by adding
> >> -Dep="-XepDisableAllChecks -Xep:ReferenceEquality:ERROR"
> >>
> >> But having all those rules on one line makes reviewing changes a pain.
> >> I don't really want to config the whole build with the compiler
> arguments.
> >>
> >> Is there a way to specify these in a properties file and have each
> >> argument on its own line?
> >
> > Have you tried using @file (a-la javadoc options):
> >
> >
> https://docs.oracle.com/en/java/javase/17/docs/specs/man/javac.html#command-line-argument-files
>
> Maybe:
>
> -Dep=@myoptions
>
> And in "myoptions" file:
>
> -XepDisableAllChecks
> -Xep:ReferenceEquality:ERROR
>
> --
> Stanimir
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

passing compiler args via a properties file

[Delany]

Hi,

Passing a few arguments to the compiler is done easily enough through the
pom,
but when there are many arguments it starts to gets hairy,
especially when I'm configuring a plugin in multiple levels of inheritance.

For example, there are many bugpatterns in errorprone
https://errorprone.info/docs/flags

I want my build pom to set the basic settings for the compiler


  -Xlint:all,-serial,-processing
  -XDcompilePolicy=byfile
  -Xplugin:ErrorProne -XepExcludedPaths:.*/target/.* ${ep}


And then my project can decide whether it want to override errorprone
default levels for specific rules

https://maven.apache.org/configure.html
I can add this one line to maven.config
-Dep=-Xep:ArgumentSelectionDefectChecker:WARN -Xep:AssertFalse:WARN
-Xep:EqualsHashCode:WARN -Xep:AvoidObjectArrays:WARN
-Xep:BareDotMetacharacter:WARN -Xep:CatchAndPrintStackTrace:WARN
-Xep:OperatorPrecedence:WARN -Xep:StatementSwitchToExpressionSwitch:WARN
-Xep:SuppressWarningsWithoutExplanation:WARN

And that does the job. I can also quickly run a build to catch on issue
that I'm trying to eradicate by adding
-Dep="-XepDisableAllChecks -Xep:ReferenceEquality:ERROR"

But having all those rules on one line makes reviewing changes a pain.
I don't really want to config the whole build with the compiler arguments.

Is there a way to specify these in a properties file and have each argument
on its own line?

Kind regards,
Delany

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Delany]

Try this https://github.com/aspan/jaxb2-basics
Delany

On Thu, 24 Aug 2023 at 20:21, David Hoffer  wrote:

> That one works great as a general purpose XJC tool and supports JAXB4 but
> unfortunately to use any of the plugin options
>
> -XtoString
> -Xequals
> -XhashCode
> -Xcopyable
>
> Requires the use of jaxb2-basics according to the
> docs which is ancient and stuck in JDK8 and prior.  So, not an option for a
> JDK17 Java EE 10 application.
>
> If anyone knows of newer plugin extensions that can support JDK17 let me
> know.
>
> Thanks,
> -David
>
> On Tue, Aug 22, 2023 at 2:46 PM Delany  wrote:
>
> > This one has JAXB4 support
> > https://github.com/phax/maven-jaxb2-plugin
> > Delany
> >
> >
> >
> > On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:
> >
> > > I think that is based on:
> > >
> > > org.jvnet.jaxb2.maven2
> > > maven-jaxb2-plugin
> > >
> > > Which, I can't get to work with JDK17 and to be compatible with the
> rest
> > of
> > > my app has to be at Java EE 10.
> > >
> > > I'm currently trying to use:
> > >
> > > org.codehaus.mojo
> > > jaxb2-maven-plugin
> > > 3.1.0
> > >
> > > As it's current; seems to support JDK17 Java 10 well.  But it seems
> they
> > > dropped support for -X argument options.  Or I just can't find how it's
> > > supported.
> > >
> > > I have also tried:
> > >
> > > org.apache.cxf
> > > cxf-xjc-plugin
> > > 4.0.0
> > >
> > > And it too is current, supports JDK17 and Java 10.  It does have
> > extension
> > > support for:
> > >
> > > toString
> > > defaultValue
> > >
> > > But does not have support for:
> > > equals
> > > hashCode
> > >
> > > And those I would really like to have.  Trying to find a way to have
> all
> > 4
> > > of those options.
> > >
> > > -Dave
> > >
> > > On Tue, Aug 22, 2023 at 1:31 PM Delany 
> > wrote:
> > >
> > > > Try here https://stackoverflow.com/a/32336886/2746335
> > > > Delany
> > > >
> > > > On Tue, 22 Aug 2023 at 21:16, David Hoffer 
> wrote:
> > > >
> > > > > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17
> > > project.
> > > > > I'm using version 3.1.0.  I can get it to generate the Java code
> but
> > > > can't
> > > > > find any way to add support for optional things like:
> > > > >
> > > > > toString
> > > > > equals
> > > > > hashCode
> > > > > defaultValue
> > > > >
> > > > > Can someone point me in the right direction on how to add these
> very
> > > > useful
> > > > > options to the generated code.
> > > > >
> > > > > Thanks,
> > > > > -Dave
> > > > >
> > > >
> > >
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Delany]

This one has JAXB4 support
https://github.com/phax/maven-jaxb2-plugin
Delany



On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:

> I think that is based on:
>
> org.jvnet.jaxb2.maven2
> maven-jaxb2-plugin
>
> Which, I can't get to work with JDK17 and to be compatible with the rest of
> my app has to be at Java EE 10.
>
> I'm currently trying to use:
>
> org.codehaus.mojo
> jaxb2-maven-plugin
> 3.1.0
>
> As it's current; seems to support JDK17 Java 10 well.  But it seems they
> dropped support for -X argument options.  Or I just can't find how it's
> supported.
>
> I have also tried:
>
> org.apache.cxf
> cxf-xjc-plugin
> 4.0.0
>
> And it too is current, supports JDK17 and Java 10.  It does have extension
> support for:
>
> toString
> defaultValue
>
> But does not have support for:
> equals
> hashCode
>
> And those I would really like to have.  Trying to find a way to have all 4
> of those options.
>
> -Dave
>
> On Tue, Aug 22, 2023 at 1:31 PM Delany  wrote:
>
> > Try here https://stackoverflow.com/a/32336886/2746335
> > Delany
> >
> > On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:
> >
> > > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17
> project.
> > > I'm using version 3.1.0.  I can get it to generate the Java code but
> > can't
> > > find any way to add support for optional things like:
> > >
> > > toString
> > > equals
> > > hashCode
> > > defaultValue
> > >
> > > Can someone point me in the right direction on how to add these very
> > useful
> > > options to the generated code.
> > >
> > > Thanks,
> > > -Dave
> > >
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Delany]

Try here https://stackoverflow.com/a/32336886/2746335
Delany

On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:

> I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17 project.
> I'm using version 3.1.0.  I can get it to generate the Java code but can't
> find any way to add support for optional things like:
>
> toString
> equals
> hashCode
> defaultValue
>
> Can someone point me in the right direction on how to add these very useful
> options to the generated code.
>
> Thanks,
> -Dave
>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Delany]

Quite honestly this is a horrendous abuse of configuration, not to mention
design and security principles, and thoroughly inelegant.
It brings to mind a Go proverb "A little copying is better than a little
dependency."
I've had my say though. If you want to set a property and not have it
inherited in other repos, put it in .\.mvn\maven.config
Delany

On Thu, 3 Aug 2023 at 03:45, Garret Wilson  wrote:

> On 8/1/2023 7:42 PM, Garret Wilson wrote:
> > …
> > Now the child POMs can turn off deployment by simply setting
> > `maven.deploy.skip` to `false`, and kill two birds with one stone:
> > deployment will be disabled whether the Nexus Staging Plugin or the
> > Maven Deploy Plugin was used.
>
> In my previous message I explained how to set up the Nexus Staging
> Plugin so that it can easily be disabled in child projects (along with
> the Maven Build Plugin) using one simple property: `maven.deploy.skip`.
> Now for the next step, the grand finale.
>
> In my original question, I asked if there was a way to keep the Nexus
> Staging Plugin from being inherited in child POMs by default. Really
> "inherited" is an implementation detail. What I really wanted to know is
> if there was to configure the Nexus Staging Plugin to be enabled by
> default in the parent POM, but be disabled by default in the child POM.
> The semantic distinction is subtle, but important; it turns out that
> there's no way to turn off inheritance, but with a few tricks (i.e.
> quite a few very ugly hacks), we can change the default configuration
> based upon whether the plugin is being invoked in the parent POM (here
> `com.globalmentor:globalmentor-root`) or from some child POM.
>
> If Maven supported expressions (oh, if only), this would be rather
> straightforward. Since it doesn't we'll use
> `org.codehaus.mojo:build-helper-maven-plugin` to do things that no one
> should ever have to do (or even consider) in a POM; it looks like this:
>
> ```xml
> 
>org.codehaus.mojo
>build-helper-maven-plugin
>
>  
>set-is-skip-deploy-false-or-prefixed
>validate
>
>  regex-property
>
>
>  maven.deploy.skip
> _${project.groupId}_${project.artifactId}
> ^_com\.globalmentor_globalmentor-root$
>  false
>  false
>
>  
>  
>set-is-skip-deploy
>initialize
>
>  regex-property
>
>
>  maven.deploy.skip
>  ${maven.deploy.skip}
>  ^_.*
>  true
>  false
>
>  
>
> 
> ```
>
> I won't explain here what's going on; I intend to write a blog post
> about it some day. The end result is that if the
> `com.globalmentor:globalmentor-root` POM is in effect, the
> `maven.deploy.skip` property is set to `true`; for any other descendant
> project, the `maven.deploy.skip` property is set to `false`. It works
> like this pseudocode:
>
> ```xml
> 
>
> $("${project.groupId}:${project.artifactId}}"!="com.globalmentor:globalmentor-root)
> ```
>
> (Wouldn't it be nice to have expressions like this.)
>
> I succeeded in pulling off effectively what I asked for. But in reality
> I would like the `maven.deploy.skip` property to be determined by
> whether `nexus.host` is set to some value, and I want `nexus.host` to be
> set to a default value in `com.globalmentor:globalmentor-root` but not
> in child POMs. But that sort of two-layered logic (although simple if
> Maven supported expressions) is too much for the ugly kludge I'm using
> (and more than my mind wants to deal with).
>
> So in the end I settled for a sort of compromise: I made the value of
> `maven.deploy.skip` dependent on whether `nexus.host` is set to a
> non-empty string. Thus the Nexus Staging Plugin is enabled by default,
> but in any child POM I can easily turn off deployment by setting the
> `nexus.host` to the empty string, like this:
>
> ```xml
> 
>
> ```
>
> This automatically turns off `maven.deploy.skip` via this ugly kludge:
>
> ```xml
> 
>org.codehaus.mojo
>build-helper-maven-plugin
>
>  
>set-is-skip-deploy-true-or-prefixed
>validate
>
>  regex-property
>
>
>  maven.deploy.skip
>  _${nexus.host}
>  ^_$
>  true
>  false
>
>  
>  
>set-is-skip-deploy
>initialize
>
>  regex-property
>
>
>  maven.deploy.skip
>  ${maven.deploy.skip}
>  ^_.*
>  false
>  false
>
>  
>
> 
> ```
>
> I'll live with this for now. I'll probably wind up writing a Maven
> set-property-from-expression plugin at some point, when I can't digest
> this sort of nasty workaround any more.
>
> Garret
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Delany]

Oh hi Nils. Yeah well a compromise is reached. I would still support a ban
on  tag in project-specific settings - more for enforcer.
Its just about maintaining good abstractions. "User settings" what should
that mean? Its basically the settings that a user doesn't want to commit.

You wanted "This is currently the only artifact repository that our build
pipelines can access, but developers will sometimes want to build a project
locally that requires other artifact repositories, e.g. a third-party
GitHub project or an experimental Proof of Concept project which requires
dependencies from a repository that hasn't been added to our in-company
artifact repository yet. A global settings file that defaults to our
private artifact repository would interfere with such local builds."

I just don't get the use case since I regularly make use of an alternative
repository configured in my user settings when I test maven pre-releases


  stage
  

  stage

  
  

  staging
  Maven Staging
  
https://repository.apache.org/content/repositories/maven-${stage}/

  
  

  staging-plugin
  Maven Staging
  
https://repository.apache.org/content/repositories/maven-${stage}/

  

  


When abstractions erode it becomes difficult to think. In this case though
the idea of user settings was never a strong one.

Delany

On Mon, 31 Jul 2023 at 18:44, Nils Breunese  wrote:

> Delany  wrote:
>
> > In any case, what repository on the Internet is configured to allow
> > anonymous uploads? The settings.xml must always be populated with
> 
> > credentials for a deployment to take place.
> > If you fear someone accidentally uploading artefacts to random repos then
> > "you're doing it wrong". Credential in settings.xml and managed manually
> or
> > someone other provisioning system = a good night sleep
> > That's why I'm not a fan of
> https://issues.apache.org/jira/browse/MNG-5659
>
> If you’re committing any file with credentials "you’re doing it wrong”.
> There are however also valid use cases for which project-specific settings
> are a very nice solution, so I’m happy it’s finally coming in Maven 4.
>
> Nils.
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Delany]

Deploy is a phase in the default lifecycle
https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
So whatever plugins are bound to that phase will be executed if you ask
Maven to run to that phase. To see what those executions would be, run
mvn fr.jcgay.maven.plugins:buildplan-maven-plugin:1.5:list-phase

The "deploy" goal of the deploy-maven-plugin requires configuration of the
 section
https://maven.apache.org/plugins/maven-deploy-plugin/usage.html

In any case, what repository on the Internet is configured to allow
anonymous uploads? The settings.xml must always be populated with 
credentials for a deployment to take place.
If you fear someone accidentally uploading artefacts to random repos then
"you're doing it wrong". Credential in settings.xml and managed manually or
someone other provisioning system = a good night sleep
That's why I'm not a fan of https://issues.apache.org/jira/browse/MNG-5659

Delany


On Mon, 31 Jul 2023 at 18:02, Garret Wilson  wrote:

> On 7/31/2023 3:07 AM, Delany wrote:
> > Perhaps you're getting confused because you conflate 2 issues:
> > … prevent general configuration like  from being inherited.
> > … preventing plugin configuration from being inherited.
>
> I do not conflate them—I do not think they are the same thing. I said
> they are both similar in one aspect: they have to be defined in order to
> publish the parent POM itself, but they semantically may not apply to
> projects that _use_ the parent POM, and thus may not be desired to be
> inherited.
>
> But I don't want to get off-track; perhaps it was unwise to even mention
> the `` issue and risk going down a different rabbit hole. I'll
> stick to the plugin configuration inheritance topic.
>
> > The second, to disable executions by default, just configure the phase to
> > none. Do this if the plugin/goal lacks a  parameter.
>
> Ah, I had forgotten about the `none` trick—thanks for
> reminding me, Delany.
>
> Let me confirm something: if I disable the Nexus Staging Maven Plugin by
> using `none` in a child POM, what will happen when a
> developer types `mvn deploy`? Nothing? I only ask because Tamás had
> mentioned the Maven Deploy Plugin. But I'm looking at the latest [super
> POM](https://maven.apache.org/ref/3.9.3/maven-model-builder/super-pom.html),
>
> and it looks like Maven Deploy Plugin is only activated in the
> `performRelease` profile (which is to be removed anyway).
>
> So if using `none` with the Nexus Staging Maven Plugin
> completely disables all staging and deployment, that may be the easiest
> way to disable it in the child POM. Thanks again for the tip.
>
> Garret
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Delany]

Perhaps you're getting confused because you conflate 2 issues:

One is about a way to prevent general configuration like  from
being inherited. Currently the only way to do this is through profiles -
which you reject off-hand.
Allowing a project model to be composited with MNG-5102 is another possible
solution.

The other is about preventing plugin configuration from being inherited.
But again there are 2 sides: general plugin configuration and execution
configuration.
You use inherited tag to prevent the first.
The second, to disable executions by default, just configure the phase to
none. Do this if the plugin/goal lacks a  parameter. And if you want
the execution to fire on the parent, set the phase to none in
pluginManagement and a valid phase in plugin, but add inherited=false.

Profiles are not perfect but they do the job, and you can literally use
them for everything, including modules (although your IDE might be unhappy
about it).
You want convenience, but not too convenient! But you can't have your cake
and eat it.
For super-secret configuration, rely on configuring the build environment
via settings.xml.

Delany

On Mon, 31 Jul 2023 at 03:05, Garret Wilson  wrote:

> On 7/30/2023 9:18 PM, Nick Stolwijk wrote:
> > I took a quick look at the Maven-Nexus-plugin and there is an option to
> > disable it (skipNexusStagingDeployMojo), so I would start there.
>
> I in fact did start there. I don't know if you happened to read this
> part of my question which started this thread:
>
>  > … let's instead find an easy way to turn it off. I don't see in the
> documentation (see link above) that there's even
>  > a "skip" property. Is there? I see that the Maven Deploy Plugin has
> such a feature.
>  > I also see that there is a `skipNexusStagingDeployMojo`, but that
> appears to be neither a configuration property
>  > nor a user property, but only a "plugin flag" which is "passed in
> from the CLI" using `-D`.
>  > Is there a "skip" configuration property for the Nexus Staging Maven
> Plugin ?
>
> So I guess I'm back to where I started.
>
> Garret
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Delany]

If its that risky not to use profiles then it shouldn't be in the root
parent pom at all.
Do like one would for signing: rely on the environment to be setup for that
purpose, i.e. put it in settings.xml
You can still have the guts of it in the pom.
Delany


On Sun, 30 Jul 2023 at 21:46, Garret Wilson  wrote:

> On 7/30/2023 4:37 PM, Mantas Gridinas wrote:
> > Sounds like a job for profiles, …
>
> It is not a job for profiles. If I put it in a profile, a developer has
> to only mistakenly use `-P nexus` or whatever the profile is, and our
> super-secret million-dollar project gets published. I want it to be
> disabled altogether.
>
> > Another idea is to have 2 poms: one for your root, the other for module
> > definitions, and latter would use relative parent for the former.
>
> Hidden somewhere in your answer is the assumption that I do not publish
> this second POM. So now I have a sharing issue—developers can no longer
> use this second POM from Maven Central, and I have to have some other
> distribution mechanism.
>
> With that in mind, I could just simply not publish the root POM to begin
> with. Problem solved. Except that the problem is not solved. The problem
> is how I publish a POM and have its children not have the publishing
> enabled by default. Your answer, boiled down to its essence, says, "just
> don't publish the root POM"—but publishing the root POM is part of the
> problem statement, and what makes the problem difficult.
>
> > Third one is to fiddle with -m/--modules flag by telling maven to only
> > include modules in the reactor provided by that flag.
>
> I was never too good with the violin. I would prefer not to fiddle with
> things. I also don't want to use CLI flags. I simply want to have a
> child POM work normally, with publishing disabled unless I add something
> simple to the child POM itself.
>
> Garret
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: elegant way to disable Nexus staging/deployment in child POMs

[Delany]

What happens if you add this to the pluginManagement/plugin section?

false

Delany

On Sun, 30 Jul 2023 at 20:29, Garret Wilson  wrote:

> I have a "root" POM which I use as the inheritance ancestor of all my
> projects: https://github.com/globalmentor/globalmentor-root
>
> By default it's configured to use the [Nexus Staging Maven
> Plugin](
> https://github.com/sonatype/nexus-maven-plugins/blob/main/staging/maven-plugin/README.md).
>
> It even has a handy `nexus.host` property to define the Nexus server
> (because Sonatype actually puts accounts on separate old-school hosts,
> but I digress).
>
> The catch-22 here is that I need this configuration to be turned on for
> me to publish this POM to Maven Central, yet there are descendant
> projects that use it that I never want to publish to Maven Central. I
> don't want this publishing feature turned on by default in child
> projects. I would prefer to have a flag that I simply turn on in child
> projects (i.e. opt-in) that are to be made public. Any way to have the
> Nexus Staging Maven Plugin enabled in the POM itself for publishing to
> Maven Central, but have it disabled by default for inherited problems?
>
> I'm guessing the answer is "no", so let's instead find an easy way to
> turn it off. I don't see in the documentation (see link above) that
> there's even a "skip" property. Is there? I see that the Maven Deploy
> Plugin has such a feature. I also see that there is a
> `skipNexusStagingDeployMojo`, but that appears to be neither a
> configuration property nor a user property, but only a "plugin flag"
> which is "passed in from the CLI" using `-D`. Is there a "skip"
> configuration property for the Nexus Staging Maven Plugin ?
>
> Does anybody know of a better approach for easily disabling publishing
> to Maven Central in an inheriting project?
>
> Garret
>
> P.S. I'm debating whether this question would be better published on
> Stack Overflow, but in my experience it seems that the Maven experts
> seem to respond here more than on Stack Overflow.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Confused about how to override a transient artifact version

[Delany]

Hi David,

When I want to know what's bringing in a dependency I use
https://github.com/ferstl/depgraph-maven-plugin

mvn depgraph:aggregate -DtargetIncludes=:jackson-databind

And it drops a nice diagram in the root build dir.


  com.github.ferstl
  depgraph-maven-plugin
  4.0.2
  
true

classpath:depgraph/depgraph.json
-Kfdp -Goverlap=false -Gstart=30
-Gsep=+10,10
dot
true
true
false

false
*
  

Delany

On Sat, 29 Jul 2023 at 01:29, David Karr  wrote:

> In general, I know how to override transient artifact versions. You add an
> "exclusion" for the artifact on the dependency that is including that
> dependency, and then you manually add that dependency in the same pom where
> you added the exclusion.  In my case, the version I want is defined in a
> bom in our parent pom, so I don't have to specify the version in that
> dependency.
>
> This works fine, if I do this exclusion and inclusion in the overall "child
> pom".
>
> However, I maintain the parent pom and platform, and there will be dozens
> of "child poms" that will need to do this.  I would much rather do this
> "fixup" in the poms for the libraries in our platform.  Those poms specify
> the dependencies whose versions I need to control.
>
> I've been struggling with trying to do this, along with trying to
> understand the output of "mvn dependency:tree" and the apparently
> functionally similar output in the "Dependency Hierarchy" view in Eclipse
> using the m2e plugin.  Although I can loosely see the hierarchical output
> from these, I find determining the actual details of where dependencies are
> coming from is very mystifying.
>
> To get down to actual details, my problem is that I'm ending up with
> different versions of "jackson-core" and "jackson-databind".  I need to
> ensure that I have the same versions of both.  I am getting v2.14.1 of
> jackson-databind and v2.13.5 of jackson-core.  We are specifying v2.13.5 in
> our parent pom, but somehow something in the tree is giving us v2.14.1 of
> jackson-databind.
>
> I'm going to include here a small excerpt of the "dependency:tree" output
> for our child pom:
>
>  com.att.idp:RiskAssessmentMS:jar:2.8.0
> +- com.att.idp:idp-seed-sdk-core:jar:2.8.0:compile
> +- org.jasypt:jasypt:jar:1.9.3:compile
> +- com.io7m.xom:xom:jar:1.2.10:compile
> +- com.att.idp:idp-health:jar:2.8.0:compile
> |  +- org.springframework.boot:spring-boot-actuator:jar:2.7.5:compile
> |  +- com.att.idp:idp-logging-core:jar:2.8.0:compile (version selected from
> constraint [2.8.0,2.8.100))
> |  |  \- ch.qos.logback:logback-core:jar:1.2.9:compile
> |  +- redis.clients:jedis:jar:3.8.0:compile
> |  |  \- org.apache.commons:commons-pool2:jar:2.11.1:compile
> |  +- com.github.fppt:jedis-mock:jar:0.1.23:compile
> |  |  \- com.google.auto.value:auto-value-annotations:jar:1.6.2:compile
> |  \- com.att.idp.voltage:vibesimplejava:jar:6.21.0.0:compile
> +- com.fasterxml.jackson.core:jackson-core:jar:2.13.4:compile
> +- com.fasterxml.jackson.core:jackson-databind:jar:2.14.1:compile
>
> The "idp-health" library is one of our wrapper libraries.  That specifies
> dependencies that pull in jackson-databind, and in those dependencies I
> have excluded jackson-databind and included a specific dependency for
> jackson-databind. As the bom imported from the parent pom specifies v2.13.5
> for that, I would expect I would get jackson-databind v2.13.5, but I'm
> still getting v2.14.1.
>
> I'm very confused.
>
> I think I remember seeing discussions in the dev list about improving the
> output of dependency:tree to be clearer, I don't know if there's been any
> progress on that.
>

Re: Maven 3.3.9 allows overriding readonly parameters for plugins

[Delany]

Hi Nikos,
That goal is only intended to be configured from project.build.resources.
You can rather use
https://maven.apache.org/plugins/maven-resources-plugin/copy-resources-mojo.html

https://issues.apache.org/jira/browse/MRESOURCES-293
Delany

On Sun, 16 Jul 2023, 17:19 Nikos Dragazis,  wrote:

> Hi everyone,
>
> I'd like to expose a deviation in maven's behavior regarding readonly
> parameters in plugins. It seems that, starting from version 3.3.9, maven
> no longer ignores configuration parameters for readonly arguments.
>
> In more detail:
>
> I have a project that follows the `war` packaging lifecycle and I'd like
> to parameterize some resource files. Therefore, I tried to use the
> maven-resources-plugin with a configuration that looks like this:
> ```
> 
>org.apache.maven.plugins
>maven-resources-plugin
>2.6
>
>  
>
> src/main/resources/META-INF
>  META-INF
>  true
>  
>persistence.xml
>  
>
>
> src/main/resources/META-INF
>  META-INF
>  false
>  
>persistence.xml
>  
>
>  
>
> 
> ```
> When running the `resources` goal with maven 3.3.3, I noticed that maven
> ignores the inclusion/exclusion lists from the plugin's configuration,
> i.e., the plugin copies `persistence.xml` unfiltered. However, this is
> not the case with maven 3.3.9, where it actually filters the file.
>
> Later on, I figured that the `resources` parameter is readonly for the
> `resources` goal, and it gets its default value from the build/resources
> element. So, I would expect maven to either ignore the `resources`
> parameter from the configuration of the `resources` goal (like what
> happens in maven 3.3.3), or throw an error. That said, I find the
> behavior of maven 3.3.9 unexpected.
>
> I'd love any feedback on this.
>
> Thanks,
> Nikos
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Multi-module Maven projects and Scala-aware artifact IDs

[Delany]

Bouncycastle does similar, e.g. bcprov-jdk15to18-173.jar
<https://www.bouncycastle.org/download/bcprov-jdk15to18-173.jar>
https://www.bouncycastle.org/latest_releases.html

Delany

On Mon, 12 Jun 2023 at 18:51, Greg Chabala  wrote:

> >
> > Has anyone faced this before?
> >
>
> Yes. The fact that Scala's binary incompatibility leaked into artifact IDs
> rather than being a classifier irritates me still.
>
> I have no good solution for you. The mess that would have come from using
> Maven for cross version Scala builds led me to follow the status quo of
> using sbt for Scala projects. The question you linked is a good summary of
> the compromises.
>
> My belief is that if sbt didn't exist the Scala community would have been
> more motivated to improve this, with different artifact naming conventions
> and/or improvements to Maven.
>
> Greg
>

Re: Maven 3.9.2 - Could not acquire read lock

[Delany]

GraphBuilder.build
(DefaultGraphBuilder.java:76)
15:33:02  at org.apache.maven.DefaultMaven.buildGraph
(DefaultMaven.java:448)
15:33:02  at org.apache.maven.DefaultMaven.doExecute
(DefaultMaven.java:197)
15:33:02  at org.apache.maven.DefaultMaven.doExecute
(DefaultMaven.java:173)
15:33:02  at org.apache.maven.DefaultMaven.execute
(DefaultMaven.java:101)
15:33:02  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:910)
15:33:02  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
15:33:02  at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
15:33:02  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
15:33:02  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
15:33:02  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
15:33:02  at java.lang.reflect.Method.invoke (Method.java:566)
15:33:02  at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:283)
15:33:02  at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:226)
15:33:02  at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:407)
15:33:02  at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:348)
15:33:02  Suppressed: java.lang.IllegalStateException: Attempt 1: Could
not acquire write lock for
'C:\ws\targ-2.2.16\.m2\repository\.locks\com.segway~segway-build~1-SNAPSHOT.lock'
in 120 SECONDS

Delany


On Sat, 27 May 2023 at 08:28, Dan Tran  wrote:

> Hi
>
> My multi-threaded build encounters the below failure at the very end of the
> build
>
> *05:26:33*  Suppressed: java.lang.IllegalStateException: Attempt
> 1: Could not acquire read lock for
> 'artifact:ch.qos.logback:logback-classic:1.2.12' in 150
> SECONDS*05:26:33*  at
>
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)*05:26:33*  at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:275)*05:26:33*  at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:260)*05:26:33*  at
>
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)*05:26:33*  at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
> (DefaultProjectDependenciesResolver.java:182)*05:26:33*  at
>
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:224)*05:26:33*  at
>
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:136)
>
>
> Some observation
>
>
> 1. Seems to happen only on slow build host/agent
>
> 2. The failure is 2/3 into the build where logback-classic is the most
> common dependency of all modules should be at local already
>
> 3. Increase lock time not helping
>
> 4. why readlock? instead of writelock
>
>
> Thought?
>
>
> Thanks
>
>
> -D
>

Re: Maven Artifact Resolver not seeing latest plugins on Maven Central on my machine

[Delany]

Try renaming `C:\Users\user\.m2\repository\`
Does the issue persist?
Delany

On Wed, 24 May 2023, 18:04 Garret Wilson,  wrote:

> I'm writing to this list on the advice of Andrzej Jarmoniuk on [Versions
> Maven Plugin Issue
> #959](https://github.com/mojohaus/versions/issues/959). I have also
> opened a [Stack Overflow question](https://stackoverflow.com/q/76307809)
> with a bounty, but so far there have been no responses.
>
> In short Maven Artifact Resolver on my machine seems to be stuck at some
> previous point in time; it does not see the latest versions on Maven
> Central when I am requested updated plugin versions using Versions Maven
> Plugin. It shows that there are newer versions available, but the ones
> it shows are not the latest available. Before deleting my entire
> `C:\Users\user\.m2\repository\` directory tree I would prefer to know
> what is caused this scenario so that it won't happen again in the
> future. But at the moment I don't even understand what condition (e.g.
> incorrect timestamps or whatever) is currently causing this behavior.
>
> I am using Maven 3.9.1 on Windows 10. I also use Eclipse EE 2023-03,
> which contains m2e (Eclipse's support for Maven). I start with [this
> `pom.xml`](
> https://github.com/globalmentor/globalmentor-root/blob/bce5bdbac7797b5b9114a72e5da2f4d76f3e24a7/pom.xml),
>
> which uses `org.codehaus.mojo:versions-maven-plugin:2.12.0`, which in
> turn (I am told) uses Maven Artifact Resolver. (Note that I've tried the
> latest `org.codehaus.mojo:versions-maven-plugin:2.15.0` as well, with
> the same results. I'm using this POM because it's available online and
> does not contain any version ignores to cause confusion.)
>
> I wanted to see what plugins were out of date, so I ran:
>
> ```bash
> mvn versions:display-plugin-updates
> ```
>
> It shows this:
>
> ```
> [INFO] The following plugin updates are available:
> [INFO]   maven-failsafe-plugin .. 2.22.2 ->
> 3.0.0-M7
> [INFO]   maven-release-plugin  2.5.3 ->
> 3.0.0-M6
> [INFO]   maven-site-plugin .. 3.12.1 ->
> 4.0.0-M3
> [INFO]   maven-surefire-plugin .. 2.22.2 ->
> 3.0.0-M7
> [INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 ->
> 3.0.5
> ```
>
> However in Versions Maven Plugin Issue #959 (see link above), Andrzej
> Jarmoniuk ran the same command and came up with different answers. Here
> are two examples:
>
> ```
> [INFO]   org.springframework.boot:spring-boot-maven-plugin .. 2.7.3 ->
> 3.1.0
> ```
>
> Note that my output is only showing v3.0.5 is available for
> `org.springframework.boot:spring-boot-maven-plugin`. Furthermore there
> are later versions available for some of the other plugins as well.
>
> ```
> [INFO] com.akathist.maven.plugins.launch4j:launch4j-maven-plugin  2.1.3
> -> 2.4.1
> ```
>
> My output doesn't even show
> `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`; apparently
> it thinks thje v2.1.3 listed in the POM is the latest available!
>
> It would appear that Maven Artifact Resolver is somehow "stuck" at some
> earlier point in time on my machine.
>
> I ran Maven with the `-X` option, and here is part of the output related
> to `com.akathist.maven.plugins.launch4j:launch4j-maven-plugin`:
>
> ```
> …
> [DEBUG] Checking
> com.akathist.maven.plugins.launch4j:launch4j-maven-plugin for updates
> newer than 2.1.3
> [DEBUG] Could not find metadata
> com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml
>
> in local (C:\Users\user\.m2\repository)
> [DEBUG] Skipped remote request for
> com.akathist.maven.plugins.launch4j:launch4j-maven-plugin/maven-metadata.xml,
>
> locally cached metadata up-to-date
> [DEBUG]
> [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].version=2.1.3
> [DEBUG]
>
> [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].artifactVersion=2.1.2
> [DEBUG]
>
> [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].effectiveVersion=2.1.3
> [DEBUG]
> [com.akathist.maven.plugins.launch4j:launch4j-maven-plugin].specified=true
> …
> ```
>
> This debug information seems to be saying that it can't find
> `C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata.xml`.
>
> And in fact that file does not exist! Instead I have
> `C:\Users\user\.m2\repository\com\akathist\maven\plugins\launch4j\launch4j-maven-plugin\maven-metadata-central.xml`.
>
> (I don't know what the differences are.)
>
> The more ominous line is this one:
&

Re: plugin of a plugin

[Delany]

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?

plugin of a plugin

[Delany]

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

Re: maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Delany]

mpl$AppInputStream.read
(SSLSocketImpl.java:1060)
01:14:56  at org.apache.http.impl.io.SessionInputBufferImpl.streamRead
(SessionInputBufferImpl.java:137)
01:14:56  at org.apache.http.impl.io.SessionInputBufferImpl.read
(SessionInputBufferImpl.java:197)
01:14:56  at org.apache.http.impl.io.ContentLengthInputStream.read
(ContentLengthInputStream.java:176)
01:14:56  at org.apache.http.conn.EofSensorInputStream.read
(EofSensorInputStream.java:135)
01:14:56  at org.apache.http.conn.EofSensorInputStream.read
(EofSensorInputStream.java:148)
01:14:56  at
org.eclipse.aether.spi.connector.transport.AbstractTransporter.copy
(AbstractTransporter.java:164)
01:14:56  at
org.eclipse.aether.spi.connector.transport.AbstractTransporter.utilGet
(AbstractTransporter.java:95)
01:14:56  at
org.eclipse.aether.transport.http.HttpTransporter.access$100
(HttpTransporter.java:89)
01:14:56  at
org.eclipse.aether.transport.http.HttpTransporter$EntityGetter.handle
(HttpTransporter.java:556)
01:14:56  at org.eclipse.aether.transport.http.HttpTransporter.execute
(HttpTransporter.java:323)
01:14:56  at org.eclipse.aether.transport.http.HttpTransporter.implGet
(HttpTransporter.java:272)
01:14:56  at
org.eclipse.aether.spi.connector.transport.AbstractTransporter.get
(AbstractTransporter.java:64)
01:14:56  at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask
(BasicRepositoryConnector.java:482)
01:14:56  at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run
(BasicRepositoryConnector.java:414)
01:14:56  at
org.eclipse.aether.connector.basic.BasicRepositoryConnector.get
(BasicRepositoryConnector.java:260)
01:14:56  at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
(DefaultArtifactResolver.java:536)
01:14:56  at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
(DefaultArtifactResolver.java:448)
01:14:56  at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:260)
01:14:56  at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
(DefaultRepositorySystem.java:352)
01:14:56  at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:182)
01:14:56  at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:224)
01:14:56  at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:136)
01:14:56  at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
(MojoExecutor.java:369)
01:14:56  at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:327)
01:14:56  at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
01:14:56  at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:175)
01:14:56  at
org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:76)
01:14:56  at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:163)
01:14:56  at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
01:14:56  at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:160)
01:14:56  at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
01:14:56  at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:193)
01:14:56  at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:180)
01:14:56  at java.util.concurrent.FutureTask.run (FutureTask.java:264)
01:14:56  at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:515)
01:14:56  at java.util.concurrent.FutureTask.run (FutureTask.java:264)
01:14:56  at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
01:14:56  at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
01:14:56  at java.lang.Thread.run (Thread.java:829)



On Fri, 24 Mar 2023 at 18:42, Tamás Cservenák  wrote:

> Delany,
>
> Had you chance to test it?
>
> T
>
> On Fri, Mar 24, 2023, 13:06 Delany  wrote:
>
> > Tamas, can I have a baked zip pls? I've hit this twice today, e.g.
> >
> > 12:12:48  [ERROR] Could not acquire write lock for
> > 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
> > 12:12:48  java.lang.IllegalStateException: Could not acquire write
> > lock for 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
> > 12:12:48  at
> >
> >
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapte

Re: maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Delany]

Thanks Tamas I got it and tested locally, but I had to role back the update
to wrapper-maven.properties because of
https://issues.apache.org/jira/browse/MWRAPPER-107
There so many ways to do this, so might get around to it this weekend.
Delany


On Fri, 24 Mar 2023 at 18:42, Tamás Cservenák  wrote:

> Delany,
>
> Had you chance to test it?
>
> T
>
> On Fri, Mar 24, 2023, 13:06 Delany  wrote:
>
> > Tamas, can I have a baked zip pls? I've hit this twice today, e.g.
> >
> > 12:12:48  [ERROR] Could not acquire write lock for
> > 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
> > 12:12:48  java.lang.IllegalStateException: Could not acquire write
> > lock for 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
> > 12:12:48  at
> >
> >
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> > (NamedLockFactoryAdapter.java:158)
> > 12:12:48  at
> > org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> > (DefaultArtifactResolver.java:259)
> > 12:12:48  at
> >
> >
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> > (DefaultRepositorySystem.java:352)
> > 12:12:48  at
> > org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
> > (DefaultProjectDependenciesResolver.java:182)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> > (LifecycleDependencyResolver.java:233)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> > (LifecycleDependencyResolver.java:145)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> > (MojoExecutor.java:369)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> > (MojoExecutor.java:327)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:213)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:175)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> > (MojoExecutor.java:76)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> > (MojoExecutor.java:163)
> > 12:12:48  at
> > org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> > (DefaultMojosExecutionStrategy.java:39)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute
> > (MojoExecutor.java:160)
> > 12:12:48  at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > (LifecycleModuleBuilder.java:105)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> > (MultiThreadedBuilder.java:193)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
> > (MultiThreadedBuilder.java:180)
> > 12:12:48  at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> > 12:12:48  at java.util.concurrent.Executors$RunnableAdapter.call
> > (Executors.java:515)
> > 12:12:48  at java.util.concurrent.FutureTask.run
> (FutureTask.java:264)
> > 12:12:48  at java.util.concurrent.ThreadPoolExecutor.runWorker
> > (ThreadPoolExecutor.java:1128)
> > 12:12:48  at java.util.concurrent.ThreadPoolExecutor$Worker.run
> > (ThreadPoolExecutor.java:628)
> > 12:12:48  at java.lang.Thread.run (Thread.java:829)
> > 12:12:48  [ERROR] java.lang.IllegalStateException: Could not acquire
> > write lock for 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
> > 12:12:48  java.util.concurrent.ExecutionException:
> > java.lang.IllegalStateException: Could not acquire write lock for
> > 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
> > 12:12:48  at java.util.concurrent.FutureTask.report
> > (FutureTask.java:122)
> > 12:12:48  at java.util.concurrent.FutureTask.get
> (FutureTask.java:191)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.multiThreadedProjectTaskSegmentBuild
> > (MultiThreadedBuilder.java:140)
> > 12:12:48  at
> >
> >
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.build
> > (MultiThreadedBuilder.java:101)
> > 12:12:48  at
> >

Re: maven-3.9.1 sees Could not acquire write lock for 'artifact:g:a:v

[Delany]

Tamas, can I have a baked zip pls? I've hit this twice today, e.g.

12:12:48  [ERROR] Could not acquire write lock for
'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
12:12:48  java.lang.IllegalStateException: Could not acquire write
lock for 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
12:12:48  at
org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
(NamedLockFactoryAdapter.java:158)
12:12:48  at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
(DefaultArtifactResolver.java:259)
12:12:48  at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
(DefaultRepositorySystem.java:352)
12:12:48  at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve
(DefaultProjectDependenciesResolver.java:182)
12:12:48  at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:233)
12:12:48  at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:145)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
(MojoExecutor.java:369)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:327)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:175)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:76)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:163)
12:12:48  at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
12:12:48  at
org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:160)
12:12:48  at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
12:12:48  at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:193)
12:12:48  at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call
(MultiThreadedBuilder.java:180)
12:12:48  at java.util.concurrent.FutureTask.run (FutureTask.java:264)
12:12:48  at java.util.concurrent.Executors$RunnableAdapter.call
(Executors.java:515)
12:12:48  at java.util.concurrent.FutureTask.run (FutureTask.java:264)
12:12:48  at java.util.concurrent.ThreadPoolExecutor.runWorker
(ThreadPoolExecutor.java:1128)
12:12:48  at java.util.concurrent.ThreadPoolExecutor$Worker.run
(ThreadPoolExecutor.java:628)
12:12:48  at java.lang.Thread.run (Thread.java:829)
12:12:48  [ERROR] java.lang.IllegalStateException: Could not acquire
write lock for 'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
12:12:48  java.util.concurrent.ExecutionException:
java.lang.IllegalStateException: Could not acquire write lock for
'artifact:net.bytebuddy:byte-buddy-agent:1.12.13'
12:12:48  at java.util.concurrent.FutureTask.report (FutureTask.java:122)
12:12:48  at java.util.concurrent.FutureTask.get (FutureTask.java:191)
12:12:48  at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.multiThreadedProjectTaskSegmentBuild
(MultiThreadedBuilder.java:140)
12:12:48  at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.build
(MultiThreadedBuilder.java:101)
12:12:48  at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
12:12:48  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
12:12:48  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
12:12:48  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
12:12:48  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:827)
12:12:48  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:272)
12:12:48  at org.apache.maven.cli.MavenCli.main (MavenCli.java:195)
12:12:48  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
12:12:48  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
12:12:48  at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
12:12:48  at java.lang.reflect.Method.invoke (Method.java:566)
12:12:48  at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
12:12:48  at
org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
12:12:48  at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
12:12:48  at
org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
12:12:48  Caused by: java.lang.IllegalStateException: Could not
acquire write 

Re: maven-surefire-plugin add artifact as additionalClasspathElement

[Delany]

Oh right, I thought he was going to fix something in surefire
There's also https://maven.apache.org/guides/mini/guide-attached-tests.html

-   
-   org.apache.maven.plugins
-   maven-surefire-plugin
-   ${surefire.version} 
-   
-   
-
com.myco.app:foo-core:test-jar:tests
-   
-   

Delany

On Thu, 16 Feb 2023 at 12:53, Olivier Lamy  wrote:

> On Thu, 16 Feb 2023 at 20:07, Delany  wrote:
> >
> > Hi Stephane,
> >
> > You can do like this
> >
> > 
> >   maven-surefire-plugin
> >   3.0.0-M9
> >   
> > 
> >   org.apache.commons
> >   commons-email
> >   1.5
> > 
> >   
> > 
>
> this will add dependencies to the surefire plugin itself.
> I guess Stephane wants to add to the jvm running the tests?
>
> additionalClasspathElement expect a full path to a directory or a file
> to be added to the classpath
>
> should work with something such but you need to assume commons-email
> has been resolved locally as a dependency.
>
> ${settings.localRepository}/org/apache/commons/commons-email/1.5/commons-email-1.5.jar
>
> another solution is to use dependency:copy to copy the commons-email
> dependency somewhere in ./target and use this path (see
>
> https://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
> )
>
> hth
> Olivier
>
> >
> > On Thu, 16 Feb 2023 at 11:25, Stephane Passignat 
> > wrote:
> >
> > > Hello,
> > >
> > > Is it possible to add a maven artifact as an
> additionalClasspathElement ?
> > >
> > > I tried this syntax, inspired by the exclusion mechanism, but it's not
> > > working.
> > >
> > > 
> > > 
> > >
> > >   org.apache.maven.plugins
> > >   maven-surefire-plugin
> > >   3.0.0-M9
> > >   
> > >  
> > >
> > >
> org.apache.commons:commons-email:1.5
> > >  
> > >   
> > >
> > > 
> > > 
> > >
> > >
> > > thank you
> > >
> > > Stéphane
> > >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven-surefire-plugin add artifact as additionalClasspathElement

[Delany]

Hi Stephane,

You can do like this


  maven-surefire-plugin
  3.0.0-M9
  

  org.apache.commons
  commons-email
  1.5

  


On Thu, 16 Feb 2023 at 11:25, Stephane Passignat 
wrote:

> Hello,
>
> Is it possible to add a maven artifact as an additionalClasspathElement ?
>
> I tried this syntax, inspired by the exclusion mechanism, but it's not
> working.
>
> 
> 
>
>   org.apache.maven.plugins
>   maven-surefire-plugin
>   3.0.0-M9
>   
>  
>
> org.apache.commons:commons-email:1.5
>  
>   
>
> 
> 
>
>
> thank you
>
> Stéphane
>

Re: Maven 3.9.0: Unable to parse maven.config file options: Unrecognized option: --settings .mvn/settings.xml

[Delany]

Why would you do that though, and not
--settings=.mvn/settings.xml

The intention is to disallow spaces. The fact that spaces are allowed on
command line is unfortunate.
Delany

On Mon, 6 Feb 2023 at 14:39, Nils Breunese  wrote:

> Thanks for the link. When I replace this:
>
> --errors
> --show-version
> -DinstallAtEnd=true
> -DdeployAtEnd=true
> --settings .mvn/settings.xml
>
> with this:
>
> --errors
> --show-version
> -DinstallAtEnd=true
> -DdeployAtEnd=true
> --settings
> .mvn/settings.xml
>
> in .mvn/maven.config then it indeed works, but I think this new format
> looks more confusing than the old one. And we have hundreds of projects
> that we’d need to make this change for…
>
> Nils.
>
> > Op 6 feb. 2023, om 13:32 heeft Tamás Cservenák 
> het volgende geschreven:
> >
> > Howdy Nils,
> >
> > something similar was discussed here:
> > https://lists.apache.org/thread/274g9dqj812rzs31q2xmj8tms0kv7wvk
> >
> > Yes, there was a change that seems to have made it a bit stricter than it
> > was before.
> >
> > Michael?
> >
> > HTH
> > Tamas
> >
> > On Mon, Feb 6, 2023 at 1:27 PM Nils Breunese  wrote:
> >
> >> Hello,
> >>
> >> I saw that Maven 3.9.0 was just released (congrats!) and I tried
> upgrading
> >> my projects. Sadly they failed with this error message:
> >>
> >> 
> >> Unable to parse maven.config file options: Unrecognised option:
> --settings
> >> .mvn/settings.xml
> >> 
> >>
> >> My projects indeed have a .mvn/maven.config file which contains (amongst
> >> other options) '--settings .mvn/settings.xml’ for project-specific
> settings.
> >>
> >> When I remove that line from .mvn/maven.config and supply it on the
> >> command line (e.g. ./mvnw --settings .mvn/settings.xml) then it works
> fine,
> >> but I wonder why it doesn’t work when I put this option in
> >> .mvn/maven.config. Is this an intentional change in Maven 3.9.0, should
> I
> >> do this differently or is this maybe a bug?
> >>
> >> Nils.
> >> -
> >> 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: Speed up build times in local and CI

[Delany]

Great suggestion splitting off the tests.
You could also use
https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/maven-extension/README.md
I create a var on Jenkins with
-Dotel.traces.exporter=otlp
-Dmaven.ext.class.path=c:/opt/opentelemetry-maven-extension-1.10.0-20220113.055723-2.jar
-Dotel.service.name=maven -Dotel.instrumentation.maven.mojo.enabled=false
and tack it onto my build commands.
There's an OpenTelemetry plugin for Jenkins so I can get to the results on
Jaeger for all past builds without having to retain the workspace.
Delany


On Fri, 3 Feb 2023 at 15:12, Dan Haywood 
wrote:

> You might want to check out maven-timeline plugin.  This seems
> semi-abandoned but nevertheless I found it really useful, especially the
> -SNAPSHOT version not yet published to maven central.
>
> I forked it here: https://github.com/danhaywood/maven-timeline, the README
> shows an image of the output it generates.
>
> As a result of using this tool, we ended up speeding up our build by
> manually separating many of our modules (we have 100+ in one app) so that,
> eg, the *customer* module has only *src/main/java* while a new
> *customer-tests* module has the corresponding *src/test/java*.  This allows
> the next downstream prod module, eg *orders* module, to start building even
> while the tests for *customer* are running.  Obviously, this only makes
> sense to do if you are running multithreadeded (usually simply -T1C for
> us), but presumably you are already doing that.
>
> HTH
> Dan
>
>
>
>
> On Fri, 3 Feb 2023 at 13:03, Javier Gómez 
> wrote:
>
> > Hello Maven community,
> >
> > We are trying to accelerate the build time in local and CI environments
> > (we use GitHub actions), in a large organization (+ 2000 Maven-Java
> > projects), and we have seen a couple of extensions that could be very
> > useful for us:
> >
> > - maven-build-cache-extension:
> > https://maven.apache.org/extensions/maven-build-cache-extension
> > - mvnd: https://github.com/apache/maven-mvnd
> >
> > Could anyone share their experiences with any of them, and what state
> > they are in?
> >
> > For example, `maven-build-cache-extension` we see is quite recent, and
> > relies on maven 3.9.0 or 4.0.0.0.0, unreleased, but initial results are
> > quite promising. I have been able to play with some project, and the
> > same `mvn clean verify` takes 10 times less, on some builds!
> >
> > `mvnd` we have not been able to find an official documentation site for
> > it, beyond the README in its repository. I understand that its primary
> > use is local environment, and currently in a CI environment it could
> > bring little improvement, at least as long as you don't connect remotely
> > to the daemon (https://github.com/apache/maven-mvnd/issues/665).
> >
> > Thank you very much.
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Cleaning the dependency-reduced-pom.xml ?

[Delany]

I used to remove it with a dedicated clean plugin execution, but that's
slow and noisy, so I moved it to
${project.build.directory}/.dependency-reduced-pom.xml
Delany


On Thu, 2 Feb 2023 at 10:54, Niels Basjes  wrote:

> Hi,
>
> When using the maven-shade-plugin there are configurations that also
> generate a dependency-reduced-pom.xml file.
>
> When doing a mvn clean this file is not removed.
>
> I'm wondering what the correct approach is in this to make this file vanish
> on mvn clean.
>
> I've already put it in my .gitignore to avoid committing it.
>
> My first question is really: Should this file be removed in all mvn clean
> situations?
> I think it should but I'm not 100% sure.
>
> If it should then how to ensure it is removed?
> I see two options right now:
>
>- I add a custom config for the maven-clean-plugin everytime I use the
>maven-shade-plugin.
>- The maven-shade-plugin is modified to remove
>the dependency-reduced-pom.xml on clean.
>
>
> Please advise.
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>

Re: MalformedInputException: Input length = 1

[Delany]

Hi Tom,
You can turn off filtering if you don't need it. The docs suggest having
separate folders for plaintext/binary resources
https://maven.apache.org/plugins/maven-resources-plugin/examples/filter.html

Re: Re: How to add a library to the classpath

[Delany]

The way to separate multiple classpaths is to have multiple poms. You can
make another child module (so that it inherits the base dependencies) and
add the extra dependencies and the exec:java to THAT module.
Delany

On Fri, 6 Jan 2023 at 18:55, Siddharth Jain  wrote:

> Hi All,
>
> Thanks for your help. To keep the discussion focused, the ask is how to add
> additional dependencies/jars to the classpath when running a program using
> mvn exec:java and from what i understand it is not possible.
>
> I am using mvn dependency:build-classpath to get the full CP and then
> augment it with additional jars and pass it to java (instead of
> maven exec:java) as workaround. but that is not the question being asked.
>
> Sid
>
> On Fri, Jan 6, 2023 at 5:19 AM Eric Bresie  wrote:
>
> >
> > Would using basic batch/shell specifying the dependencies with the Java
> > classpath argument (without maven run) and the main runtime class be the
> > alternative?
> >
> > Kind of a side question…when building with maven does it automate the
> > addition dependencies within the META-INF/MANIFEST.MF (1) embedded within
> > the jar?
> >
> > Eric Bresie
> > ebre...@gmail.com (mailto:ebre...@gmail.com)
> >
> > References (1)
> > https://stackoverflow.com/questions/70216/whats-the-purpose-of-meta-inf
> > > On January 6, 2023 at 2:35:16 AM CST, Mantas Gridinas <
> > mgridi...@gmail.com (mailto:mgridi...@gmail.com)> wrote:
> > > I'm confused. Why would your users write additional entries intk your
> > pom?
> > >
> > > On Fri, Jan 6, 2023, 10:33 (x-apple-data-detectors://4) Delany <
> > delany.middle...@gmail.com (mailto:delany.middle...@gmail.com)> wrote:
> > >
> > > > Could this help?
> > > >
> > > >
> >
> https://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html
> > > > Delany
> > > >
> > > > On Fri, 6 Jan 2023 at 05:30, Siddharth Jain  > (mailto:siddh...@gmail.com)> wrote:
> > > >
> > > > > thanks. unfortunately this is exactly what i don't want to do. i am
> > > > looking
> > > > > for a command line solution. i don't want my users to have to
> write a
> > > > > pom.xml to add additional dependencies to the classpath.
> > > > >
> > > > > On Thu, Jan 5, 2023 at 5:16 PM Greg Chabala <
> greg.chab...@gmail.com
> > (mailto:greg.chab...@gmail.com)>
> > > > > wrote:
> > > > >
> > > > > > Try searching for an example:
> > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://github.com/search?l=Maven+POM=additionalClasspathElements=Code
> > > > > >
> > > > > > On Thu, Jan 5, 2023 at 7:11 PM Siddharth Jain <
> siddh...@gmail.com
> > (mailto:siddh...@gmail.com)>
> > > > > wrote:
> > > > > >
> > > > > > > thanks. how do i separate multiple classpaths? tried : and ,
> and
> > none
> > > > > of
> > > > > > > them work.
> > > > > > >
> > > > > > > On Thu, Jan 5, 2023 at 3:58 PM Laird Nelson <
> ljnel...@gmail.com
> > (mailto:ljnel...@gmail.com)>
> > > > > wrote:
> > > > > > >
> > > > > > > > On Thu, Jan 5, 2023 at 3:20 PM Siddharth Jain <
> > siddh...@gmail.com (mailto:siddh...@gmail.com)>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I am using mvn exec:java to run a program. […] I want to
> add
> > some
> > > > > > more
> > > > > > > > > libraries that I have
> > > > > > > > > installed in M2 repository to the classpath at runtime and
> I
> > do
> > > > NOT
> > > > > > > want
> > > > > > > > to
> > > > > > > > > list them in the project's pom.xml. How can I do this? I
> > tried
> > > > > > > searching
> > > > > > > > > online but could not find an answer.
> > > > > > > > >
> > > > > > > >
> > > > > > > > The documentation for the exec-maven-plugin's java goal
> > contains
> > > > > this:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#additionalClasspathElements
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
>

Re: How to add a library to the classpath

[Delany]

Could this help?
https://maven.apache.org/plugins/maven-dependency-plugin/build-classpath-mojo.html
Delany

On Fri, 6 Jan 2023 at 05:30, Siddharth Jain  wrote:

> thanks. unfortunately this is exactly what i don't want to do. i am looking
> for a command line solution. i don't want my users to have to write a
> pom.xml to add additional dependencies to the classpath.
>
> On Thu, Jan 5, 2023 at 5:16 PM Greg Chabala 
> wrote:
>
> > Try searching for an example:
> >
> >
> https://github.com/search?l=Maven+POM=additionalClasspathElements=Code
> >
> > On Thu, Jan 5, 2023 at 7:11 PM Siddharth Jain 
> wrote:
> >
> > > thanks. how do i separate multiple classpaths? tried : and , and none
> of
> > > them work.
> > >
> > > On Thu, Jan 5, 2023 at 3:58 PM Laird Nelson 
> wrote:
> > >
> > > > On Thu, Jan 5, 2023 at 3:20 PM Siddharth Jain 
> > > wrote:
> > > >
> > > > > I am using mvn exec:java to run a program. […] I want to add some
> > more
> > > > > libraries that I have
> > > > > installed in M2 repository to the classpath at runtime and I do NOT
> > > want
> > > > to
> > > > > list them in the project's pom.xml. How can I do this? I tried
> > > searching
> > > > > online but could not find an answer.
> > > > >
> > > >
> > > > The documentation for the exec-maven-plugin's java goal contains
> this:
> > > >
> > > >
> > >
> >
> https://www.mojohaus.org/exec-maven-plugin/java-mojo.html#additionalClasspathElements
> > > >
> > >
> >
>

Re: Maven assembly plugin - Proxies not working with mirrors

[Delany]

Sorry not familiar with proxies. Make sure there isn't a bug at
https://issues.apache.org/jira/projects/MNG/issues/MNG-7642?filter=allopenissues
Delany


On Thu, 22 Dec 2022 at 15:34, Abhinav Sharma 
wrote:

> I have tried with maven 3.8.6 as well. Same error comes.
>
> On Thu, 22 Dec, 2022, 19:00 Delany,  wrote:
>
> > Use Maven v3.8.6 if you can Abhinav
> > Delany
> >
> >
> > On Thu, 22 Dec 2022 at 14:17, Abhinav Sharma 
> > wrote:
> >
> > > Hi,
> > > I am using maven 3.8.2 with java 11 in my system, with remotes
> configured
> > > for jfrog artifactory.
> > >
> > > With both mirror and proxy added, mvn is ignoring the proxies and
> failing
> > > to resolve any dependency. How do I set proxies for maven mirrors as
> > well?
> > >
> > > Without a mirror, the maven assembly plugin is not looking in the
> > > configured jfrog repositories for the dependencies. It starts looking
> at
> > > some random repo.
> > >
> > > [INFO] maven-assembly-plugin:3.3.0:single (make-assembly)sample-project
> > ---
> > > Downloading from jvnet-nexus-staging:
> > > http://maven.java.net/content/repositories/staging/
> > > <
> > >
> >
> http://maven.java.net/content/repositories/staging/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >com/example/sample-project/0.0.1-SNAPSHOT
> > > <
> > >
> >
> http://maven.java.net/content/repositories/snapshots/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >/maven-metadata.xml
> > > <
> > >
> >
> http://maven.java.net/content/repositories/staging/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >
> > > Downloading from releases.java.net:
> > > http://maven.java.net/content/repositories/releases/
> > > <
> > >
> >
> http://maven.java.net/content/repositories/releases/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >com/example/sample-project/0.0.1-SNAPSHOT
> > > <
> > >
> >
> http://maven.java.net/content/repositories/snapshots/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >/maven-metadata.xml
> > > <
> > >
> >
> http://maven.java.net/content/repositories/releases/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >
> > > Downloading from shapshots.java.net:
> > >
> > >
> >
> http://maven.java.net/content/repositories/snapshots/com/example/sample-project/0.0.1-SNAPSHOT/maven-metadata.xml
> > > <
> > >
> >
> http://maven.java.net/content/repositories/snapshots/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> > > >
> > >
> > >
> > > I am expecting to access jfrog maven virtual repo with mirror enabled
> > > behind the company proxy, or force assembly plugin to look into the
> > > repositories defined in settings.xml.
> > >
> > > I am using settings.xml file similar to this:
> > >
> > > 
> > > http://maven.apache.org/SETTINGS/1.2.0
> > > http://maven.apache.org/xsd/settings-1.2.0.xsd; xmlns="
> > > http://maven.apache.org/SETTINGS/1.2.0;
> > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> > >   
> > > 
> > >   username
> > >   password
> > >   central
> > > 
> > > 
> > >   username
> > >   password
> > >   snapshots
> > > 
> > >   
> > >   
> > > 
> > >   *
> > >   project-repo
> > >   https://company.jfrog.io/artifactory/project-repo
> > >   project-repo
> > > 
> > >   
> > >   
> > > 
> > >   
> > > 
> > >   
> > > false
> > >   
> > >   central
> > >   project-repo
> > >   https://company.jfrog.io/artifactory/project-repo
> > > 
> > > 
> > >   
> > >   snapshots
> > >   project-repo
> > >   https://company.jfrog.io/artifactory/project-repo
> > > 
> > >   
> > >   
> > > 
> > >   
> > > false
> > >   
> > >   central
> > >   project-repo
> > >   https://company.jfrog.io/artifactory/project-repo
> > > 
> > > 
> > >   
> > >   snapshots
> > >   project-repo
> > >   https://company.jfrog.io/artifactory/project-repo
> > > 
> > >   
> > >   artifactory
> > > 
> > >   
> > >   
> > > artifactory
> > >   
> > >  
> > > 
> > > jfrog-proxy
> > > true
> > > https
> > > proxyhost
> > > proxyport
> > >   
> > > 
> > > 
> > >
> >
>

Re: Maven assembly plugin - Proxies not working with mirrors

[Delany]

Use Maven v3.8.6 if you can Abhinav
Delany


On Thu, 22 Dec 2022 at 14:17, Abhinav Sharma 
wrote:

> Hi,
> I am using maven 3.8.2 with java 11 in my system, with remotes configured
> for jfrog artifactory.
>
> With both mirror and proxy added, mvn is ignoring the proxies and failing
> to resolve any dependency. How do I set proxies for maven mirrors as well?
>
> Without a mirror, the maven assembly plugin is not looking in the
> configured jfrog repositories for the dependencies. It starts looking at
> some random repo.
>
> [INFO] maven-assembly-plugin:3.3.0:single (make-assembly)sample-project ---
> Downloading from jvnet-nexus-staging:
> http://maven.java.net/content/repositories/staging/
> <
> http://maven.java.net/content/repositories/staging/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >com/example/sample-project/0.0.1-SNAPSHOT
> <
> http://maven.java.net/content/repositories/snapshots/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >/maven-metadata.xml
> <
> http://maven.java.net/content/repositories/staging/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >
> Downloading from releases.java.net:
> http://maven.java.net/content/repositories/releases/
> <
> http://maven.java.net/content/repositories/releases/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >com/example/sample-project/0.0.1-SNAPSHOT
> <
> http://maven.java.net/content/repositories/snapshots/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >/maven-metadata.xml
> <
> http://maven.java.net/content/repositories/releases/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >
> Downloading from shapshots.java.net:
>
> http://maven.java.net/content/repositories/snapshots/com/example/sample-project/0.0.1-SNAPSHOT/maven-metadata.xml
> <
> http://maven.java.net/content/repositories/snapshots/com/infosys/fbp/platform/fbp-parent-pom/1.5-SNAPSHOT/maven-metadata.xml
> >
>
>
> I am expecting to access jfrog maven virtual repo with mirror enabled
> behind the company proxy, or force assembly plugin to look into the
> repositories defined in settings.xml.
>
> I am using settings.xml file similar to this:
>
> 
> http://maven.apache.org/SETTINGS/1.2.0
> http://maven.apache.org/xsd/settings-1.2.0.xsd; xmlns="
> http://maven.apache.org/SETTINGS/1.2.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
>   
> 
>   username
>   password
>   central
> 
> 
>   username
>   password
>   snapshots
> 
>   
>   
> 
>   *
>   project-repo
>   https://company.jfrog.io/artifactory/project-repo
>   project-repo
> 
>   
>   
> 
>   
> 
>   
> false
>   
>   central
>   project-repo
>   https://company.jfrog.io/artifactory/project-repo
> 
> 
>   
>   snapshots
>   project-repo
>   https://company.jfrog.io/artifactory/project-repo
> 
>   
>   
> 
>   
> false
>   
>   central
>   project-repo
>   https://company.jfrog.io/artifactory/project-repo
> 
> 
>   
>   snapshots
>   project-repo
>   https://company.jfrog.io/artifactory/project-repo
> 
>   
>   artifactory
> 
>   
>   
> artifactory
>   
>  
> 
> jfrog-proxy
> true
> https
> proxyhost
> proxyport
>   
> 
> 
>

preferred garbage collector

[Delany]

What is the best garbage collector to use for Maven, with a large project
that can ensure no OOM?
I'm looking for reliability over speed.

For the past year or two my machine has locked up in a build
intermittently, requiring a power cycle. I was sure it was a hardware issue
until I bought another machine and the same thing happened.
So I doubled the memory. It was much better, but still problems.
When it started to stutter it got a SIGKILL, but the new machine never
froze up completely.
I didnt think software could bring the machine to its knees, but clearly it
can and I need to make sure Maven doesn't do this.

I was playing with jconsole and found that heap requirements just kept
going up (to around 6Gb for my build without tests). I had to manually
force a GC to release some memory.
The default GC interval in JDK6 was 60 secs. I believe with JDK11 its 60
min, so no full GC in a build.
None of the GCs I looked at allow configuring the interval (unless using
RMI apparently?)

I changed the GC to Shenandoah since it seems to have some intelligence
around when an OOM might occur.
Can someone please comment on my jvm.config?

-enableassertions
-Djava.awt.headless=true
-Xlog:all=warning:stdout:uptime,tags
-XX:TieredStopAtLevel=1
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./mvn_java_heapdump.hprof
-XX:+UseShenandoahGC
-XX:ShenandoahGCHeuristics=compact
-XX:+UseStringDeduplication
-XX:+UseCodeCacheFlushing
-XX:InitialCodeCacheSize=128m
-XX:ReservedCodeCacheSize=256m
--add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED
--add-exports jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED
--add-opens jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED
--add-opens jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED

Here is my prof script someone might find it useful

#!/bin/sh -m
"$@" & sh -c 'jconsole -interval=1 "$@" &' _ "$!"; fg

Then invoke a build with
./prof mvn verify

Kind regards,
Delany

Re: PluginManager.verifyReportPlugin NoSuchMethod

[Delany]

Try d...@maven.apache.org

On Thu, 24 Nov 2022 at 15:01, Alex O'Ree  wrote:

> Hello
>
> I was rummaging around in the maven pdf plugin internals which used to have
> the ability to append maven site reporting plugin content into PDFs. I
> noticed it was calling the following:
>
> return (PluginDescriptor) pluginManager.verifyReportPlugin( reportPlugin,
> project, session );
> which throws a NoSuchMethod
>
> which logs the following message
> Ignoring api call removed in maven 3, no reports are generated!"
>
> Question: is there an alternative API that I can run to get the
> PluginDescriptor from the ReportPlugin object?
>

Re: Polyglot usage of components/Dependency graph API

[Delany]

Try d...@maven.apache.org


On Tue, 22 Nov 2022 at 16:23, Patrick Plenefisch 
wrote:

> Hi,
> How can I query a specific dependency's *resolved* transitive dependencies
> inside a class executed by a mojo? I have access to session and project,
> and that's it.
> I looked at DependencyGraphBuilder and the underlying
> ProjectDependenciesResolver, but those seem to be injected. While I can
> generate a class at runtime, I don't see how to access the injector even if
> I have a class
>
> The environment I'm running inside is JRuby inside
>
> https://github.com/takari/polyglot-maven/blob/master/polyglot-maven-plugin/src/main/java/org/sonatype/maven/polyglot/plugin/ExecuteMojo.java
> which is why I can't just use an @Inject annotation. But, being JRuby, I
> can easily generate classes at runtime if necessary.
>
> How can I go about this?
>
> Thanks,
>
> Patrick
>

Re: Mvn install fails

[Delany]

It always is :)

On Tue, 15 Nov 2022 at 09:24, Raivo Rebane  wrote:

> Hi
>
> Thank for help. I succseed. I was bored by Ubuntu and don't mention
> Chabalas letter. It's really simple
>
> Regards
>
> Raivo
>
> On 14.11.22 19:30, Arnaud bourree wrote:
> > Hi,
> >
> > Did you read Maven documentations, books about it?
> > It looks you don't understand the philosophy.
> > Why don't you follow suggestion from Greg Chabala to depend on jabx-api
> or
> > jakarta xml-bind-api artifact?
> > Keep It Simple
> >
> > Arnaud
> >
> > Le lun. 14 nov. 2022, 18:07, Raivo Rebane  a écrit :
> >
> >> Hi
> >> It takes me days to put things work with Ubuntu.
> >> Now I trie with Windows 10.
> >> I have successfully deployied needed jar into local repository.
> >> And did addings into pom.xml file
> >>
> >>
> >>   
> >>   project.local
> >>   project
> >>   file:${project.basedir}/repo
> >>   
> >>   
> >>
> >>   
> >>   lib
> >>   bind
> >>   1.0
> >>   
> >>
> >> And repo looks like :
> >>
> >> $ dir -la repo/lib/bind/1.0/*
> >> -rw-r--r-- 1 Raivo 197121 103515 Nov 14 18:47
> >> repo/lib/bind/1.0/bind-1.0.jar
> >> -rw-r--r-- 1 Raivo 197121 32 Nov 14 18:47
> >> repo/lib/bind/1.0/bind-1.0.jar.md5
> >> -rw-r--r-- 1 Raivo 197121 40 Nov 14 18:47
> >> repo/lib/bind/1.0/bind-1.0.jar.sha1
> >> -rw-r--r-- 1 Raivo 197121379 Nov 14 18:47
> >> repo/lib/bind/1.0/bind-1.0.pom
> >> -rw-r--r-- 1 Raivo 197121 32 Nov 14 18:47
> >> repo/lib/bind/1.0/bind-1.0.pom.md5
> >> -rw-r--r-- 1 Raivo 197121 40 Nov 14 18:47
> >> repo/lib/bind/1.0/bind-1.0.pom.sha1
> >>
> >> But mvn install doesn't find needed jar
> >>
> >> Deploy is done as follows and was successfull :
> >>
> >> mvn deploy:deploy-file -Durl=file://repo -Dfile=javax.xml.bind.jar
> >> -DgroupId=lib -DartifactId=bind -Dpackaging=jar -Dversion=1.0
> >>
> >> What's wrong and what I have to do ?
> >>
> >> Redards
> >>
> >> Raivo
> >>
> >>
> >> -
> >> 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: Maven Deploy fails

[Delany]

Not a Maven issue, but if you didn't install the JDK then you'll have to
add it with `sudo update-alternatives --install`
If the JAVA_HOME env var is set Maven will use that instead.
Delany

On Mon, 14 Nov 2022 at 09:29, Raivo Rebane  wrote:

> Hi
>
> raivo@Hydra:~/teamengine$ sudo update-alternatives --list java
> /usr/lib/jvm/java-11-openjdk-amd64/bin/java
>
> So, it gives only one alternative
>
> But :
> raivo@Hydra:~/teamengine$ ll /usr/java
> total 16
> drwxr-xr-x  4 root root 4096 nov8 17:25 ./
> drwxr-xr-x 15 root root 4096 aug   16  2020 ../
> drwxr-xr-x  9 root root 4096 nov8 18:25 jdk1.8.0_261-amd64/
> drwxr-xr-x  7 root root 4096 nov8 18:26 jre1.8.0_351/
>
> ANd why sudo apt install gives error in any case ?
>
> Regards
> Raivo
>
> On 14.11.22 07:36, Arnaud bourree wrote:
> > Sorry, the exact command name is update-alternatives
> > See
> >
> https://manpages.ubuntu.com/manpages/trusty/man8/update-alternatives.8.html
> >
> > Le dim. 13 nov. 2022, 19:08, Raivo Rebane  a écrit :
> >
> > Hi
> >
> > I did
> >
> > raivo@Hydra:$ sudo update-alternative --list java
> > [sudo] password for raivo:
> > sudo: update-alternative: command not found
> >
> > And got error
> >
> > Raivo
> >
> > On 13.11.22 18:21, Arnaud bourree wrote:
> > > sudo upgrade-alternative --config
> >

Re: jar aggregator projects

[Delany]

Oh, make no mistake I use aggregator POMs for that reason. But I ALSO have
many aggregators that are just containers with .
They need their own artifactId, and their own directory (technically not a
requirement, but in practice no-one wants 2 poms in one directory).
Delany

On Tue, 8 Nov 2022 at 15:23, Mantas Gridinas  wrote:

> I think the reasoning makes sense. I would rather have a strong primitive
> using which I could build my own process, rather than fight an exact
> implementation. Current structure of an aggregator being its own packaging
> type is that primitive.
>
> Why do you consider having "glue boilerplate" bad, delany? I think its a
> great place to put all thr project's verbose declarations, such as
> dependency management, repository, plugin management blocks without
> litering the actual working modules.
>
> On Tue, Nov 8, 2022, 14:00 Łukasz Dywicki  wrote:
>
> > Hello Delany,
> > Number of combinations in which people would like to assembly their
> > software is larger than hours maven maintainers can provide to support
> > all of them equally well. I remember that a lot of initial "hate" maven
> > received was caused by assembly plugin which was not covering all edge
> > cases people had.
> > Probably there are more reasons which come from initial assumptions made
> > when designing Maven, thus maybe someone closer to the core will explain
> > why its not possible.
> >
> > Best,
> > Łukasz
> >
> > On 7.11.2022 18:52, Delany wrote:
> > > Let me answer that with another question. How often does a project
> > include
> > > a core component/module with a bunch of other components that depend on
> > it?
> > > I would guess quite often.
> > > So why cant I have a directory structure that looks like:
> > >
> > > webserver
> > > ├── feature-a
> > > ├── feature-b
> > > ├── skin-1
> > > └── skin-2
> > >
> > > Instead I have to come up with an aggregation project to ties them all
> > > together
> > >
> > > aggregation-webserver
> > > ├── actual-webserver
> > > ├── feature-a
> > > ├── feature-b
> > > ├── skin-1
> > > └── skin-2
> > >
> > > This aggregation project is just extra glue that must be built,
> deployed,
> > > downloaded.
> > >
> > > What about the declaration of the webserver dependency. In the first
> case
> > > it could be an implicit effect of having  type jar, but in the
> > > second I have to write it out in the aggregation-webserver.
> > >
> > > I just don't see the point. Why have 6 projects when 5 will do?
> > >
> > > I do see the point of aggregation poms if it was 5 unrelated
> components,
> > > but there is an obvious hierarchy here.
> > > I also see the potential pitfall of plugin configuration meant only for
> > the
> > > webserver being inherited by its children. But if I make customizations
> > > inappropriate for the children then I'll abstract them into an
> > aggregation
> > > pom when the need arises. Most plugin configuration I have applies to
> all
> > > my modules.
> > >
> > > Kind regards,
> > > Delany
> > >
> > >
> > > On Fri, 4 Nov 2022 at 16:08, Thai Le  wrote:
> > >
> > >> I'm curious about the usecase of this.
> > >>
> > >> Thai Le
> > >>
> > >> On Fri, Nov 4, 2022, 09:30 Delany  wrote:
> > >>
> > >>> Hi. Why can I only have pom aggregator projects and not jar
> aggregator
> > >>> projects?
> > >>> Is this still the case in Maven 4?
> > >>>
> > >>> Thanks,
> > >>> Delany
> > >>>
> > >>
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: jar aggregator projects

[Delany]

Let me answer that with another question. How often does a project include
a core component/module with a bunch of other components that depend on it?
I would guess quite often.
So why cant I have a directory structure that looks like:

webserver
├── feature-a
├── feature-b
├── skin-1
└── skin-2

Instead I have to come up with an aggregation project to ties them all
together

aggregation-webserver
├── actual-webserver
├── feature-a
├── feature-b
├── skin-1
└── skin-2

This aggregation project is just extra glue that must be built, deployed,
downloaded.

What about the declaration of the webserver dependency. In the first case
it could be an implicit effect of having  type jar, but in the
second I have to write it out in the aggregation-webserver.

I just don't see the point. Why have 6 projects when 5 will do?

I do see the point of aggregation poms if it was 5 unrelated components,
but there is an obvious hierarchy here.
I also see the potential pitfall of plugin configuration meant only for the
webserver being inherited by its children. But if I make customizations
inappropriate for the children then I'll abstract them into an aggregation
pom when the need arises. Most plugin configuration I have applies to all
my modules.

Kind regards,
Delany


On Fri, 4 Nov 2022 at 16:08, Thai Le  wrote:

> I'm curious about the usecase of this.
>
> Thai Le
>
> On Fri, Nov 4, 2022, 09:30 Delany  wrote:
>
> > Hi. Why can I only have pom aggregator projects and not jar aggregator
> > projects?
> > Is this still the case in Maven 4?
> >
> > Thanks,
> > Delany
> >
>

jar aggregator projects

[Delany]

Hi. Why can I only have pom aggregator projects and not jar aggregator
projects?
Is this still the case in Maven 4?

Thanks,
Delany

Re: How to share the same modules between different profiles

[Delany]

Shouldn't matter. Please give full pom.
Delany

On Wed, 28 Sep 2022, 23:15 Thai Le,  wrote:

> Thanks for your input. That's the first thing I tried. Unfortunately, if I
> do that none of the modules recognized the profiles.
>
> On Wed, Sep 28, 2022, 17:08 Delany  wrote:
>
> > Why did you duplicate modules in the profiles? Just leave them under
> > project.
> > Delany
> >
> >
> > On Wed, 28 Sep 2022, 21:32 Thai Le,  wrote:
> >
> > > Hello,
> > >
> > > I have an aggregator pom with 70 modules to be built.
> > > 
> > >   4.0.0
> > >   company
> > >   packaging-pom
> > >   1
> > >   pom
> > >70 modules listed here 
> > > 
> > > Recently we are introducing pact testing into our build pipeline so I
> > made
> > > 2 profiles. One is for running pact consumer test which excludes all
> the
> > > unit tests ending with *Test and only includes the consumer test. The
> > other
> > > one is for running pact provider tests which excludes all unit tests
> and
> > > pact consumer tests so that only pact provider tests can run. The 2
> > > profiles should be applied to all the 70 modules. One way to do that is
> > to
> > > put the modules inside each profile thus the modules are duplicated.
> > > 
> > >   4.0.0
> > >   company
> > >   packaging-pom
> > >   1
> > >   pom
> > >
> > >   
> > > 
> > >   consumer-pact-test
> > >   * 70 modules listed here *
> > >   ...
> > > 
> > >
> > > 
> > >   provider-pact-test
> > >   * 70 modules listed here *
> > >   ...
> > > 
> > >
> > >   
> > > 
> > > Imagine if I had to add 10 more profiles. Is there other ways to share
> > the
> > > same modules between multiple profiles without duplicating them ?
> > >
> > > Regards
> > >
> > > Thai Le
> > >
> >
>

Re: How to share the same modules between different profiles

[Delany]

Why did you duplicate modules in the profiles? Just leave them under
project.
Delany


On Wed, 28 Sep 2022, 21:32 Thai Le,  wrote:

> Hello,
>
> I have an aggregator pom with 70 modules to be built.
> 
>   4.0.0
>   company
>   packaging-pom
>   1
>   pom
>70 modules listed here 
> 
> Recently we are introducing pact testing into our build pipeline so I made
> 2 profiles. One is for running pact consumer test which excludes all the
> unit tests ending with *Test and only includes the consumer test. The other
> one is for running pact provider tests which excludes all unit tests and
> pact consumer tests so that only pact provider tests can run. The 2
> profiles should be applied to all the 70 modules. One way to do that is to
> put the modules inside each profile thus the modules are duplicated.
> 
>   4.0.0
>   company
>   packaging-pom
>   1
>   pom
>
>   
> 
>   consumer-pact-test
>   * 70 modules listed here *
>   ...
> 
>
> 
>   provider-pact-test
>   * 70 modules listed here *
>   ...
> 
>
>   
> 
> Imagine if I had to add 10 more profiles. Is there other ways to share the
> same modules between multiple profiles without duplicating them ?
>
> Regards
>
> Thai Le
>

Re: Dependencies - need help/advice: Getting the latest version of a specific (not all) dependencies

[Delany]

> Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
app1-0.0.1-SNAPSHOT.jar file.

What does this mean?


On Sat, 24 Sept 2022 at 00:05, Bruno Melloni  wrote:

> First, you are right... I misread.  When I look at the maven plugins in
> pluginManagement I see v2 and v3:  clean=3.1.0, compiler=3.8.1,
> surefire=2.22.1, jar=3.0.2, install=2.5.2, deploy=2.8.2, site=3.7.1,
> project-info-reports=3.0.0.  Still, it is > 2.0 so LATEST is no longer
> supported as a version tag.
>
> Let's see if I can explain it better:
>
> - I emptied the local maven repository of every single one of my
> projects, literally went in the folder net/myorg and deleted everything
> from there.
>
> - Then I rebuilt in order.  This included app1 and app2 (that has app1
> as one of its dependencies) which showed up in the local repository
> folder.  Obviously, both generated snapshot jars had a timestamp of
> yesterday.
>
> - Finally I opened app2-0.0.1-SNAPSHOT.jar and looked for the included
> app1-0.0.1-SNAPSHOT.jar file.  I expected to see yesterday's timestamp
> on the JAR file since I had just done a maven clean install.  Nope, it
> had a January timestamp, and the contents were old.
>
> So, it is clear that:
>
> (1) IntelliJ is caching the JARs it uses for a project somewhere.  And
> giving it the commands to reload dependencies or the POM fail if the
> version number has not changed... since I am seeing a file from
> January.  Also, the IntelliJ setting "Always update snapshots" fails as
> well.  This may be an Maven issue or it might be a quirk of IntelliJ, my
> suspicion is that IntelliJ relied on the old 2.x maven behavior for that
> setting.  Sadly I am not knowledgeable enough to know.
>
> (2) Looking for an alternative all I found for 3.0 and above Maven was
> the use of version ranges in the dependency entry of the app2 POM.  That
> would require updating the version after even a tiny change in app1, but
> at least it would not require updating the version in the the pom of the
> myriad of "app2"s that we have, unless we wanted to.  I suspect this is
> what versions-maven-plugin does but that I botched it when I tried to
> use it, as its documentation is very confusing for a beginner and they
> don't provide a single complete example of a POM that uses it.  The
> symptom was an error popping up in the POM itself, long before trying to
> do a build.  I think the error was either the "[0.0.1,
> 0.0.999)-SNAPSHOT" tag, or my missing something in plugin
> management.
>
> Conclusion:
>
> It seems that the cleanest way to solve this is to use the
> versions-maven-plugin, but I am not using it right.  Any help on this
> would be great.  A simple working example of a POM that uses
> version-maven-plugin with a version range would be ideal.
>
>
> On 9/23/2022 1:25 PM, Nils Breunese wrote:
> > Hi Bruno,
> >
> > It’s not completely clear to me what your issue is exactly. Is ’the old
> cached version from January’ that you refer to an artifact with a snapshot
> version or a release version? If it is a snapshot version, it depends on
> the update policy whether Maven will use a locally cached snapshot or
> whether it will try to fetch an update from the the configured repository.
> If there is no explicit update policy configured, I believe the default is
> to look for updates once a day. You can force Maven to update snapshots by
> using the -U (or --update-snapshots) flag. If your dependency is a release
> version, then there can be only one artifact for that version and if you
> have it cached locally, it should be identical to that version of the
> artifact on the repository server.
> >
> > Maven 4 has not been released yet, are you sure you are (and should be)
> using that version? Version 3.8.6 is the current latest release [0].
> >
> > To avoid having to manually update dependencies my team has a scheduled
> task to run Renovate [1] in our applications' CI pipelines to check for
> dependency updates. Renovate automatically creates a branch and a merge
> request whenever a dependency update is found. There are more tools like
> Renovate. For instance GitHub also provides Dependabot [2]. Maven Versions
> Plugin [3] can also be used to update dependencies.
> >
> > Nils.
> >
> > [0] https://maven.apache.org/download.cgi
> > [1] https://github.com/renovatebot/renovate
> > [2] https://docs.github.com/en/code-security/dependabot
> > [3] https://www.mojohaus.org/versions-maven-plugin/
> >
> >> Op 23 sep. 2022, om 14:58 heeft Bruno  het
> volgende geschreven:
> >>
> >> I apologize for the length of this email, I could not think of a
> shorter way to present the issue/questions that is clear enough.
> >>
> >> ---
> >>
> >> My environment involves the usual many open source dependencies (which
> I control by specifying the versions to use in a master POM), but also a
> large number of frequently changing internally built dependencies and a
> huge number of applications that rely on these dependencies.
> >>
> >> Changes 

Re: Maven Wrapper: Using it with override settings.xml

[Delany]

There's also a --global-setting parameter, so you could specify the
repository in one and the server details in the other. Their content is
merged with the user settings taking precedence.
Delany


On Tue, 13 Sept 2022 at 13:30, Sverre Moe  wrote:

> That means you have to check in the settings.xml into git.
> I am not comfortable doing this, considering the server config in
> settings.xml has the deployment password, although being obfuscated.
>
> /Sverre
>
> tir. 13. sep. 2022 kl. 12:00 skrev Slawomir Jaranowski <
> s.jaranow...@gmail.com>:
>
> > Hi,
> >
> > You can create file: .mvn/maven.config [1] with content
> >
> > --settings ./settings.xml
> >
> > [1] https://maven.apache.org/configure.html#mvn-maven-config-file
> >
> > wt., 13 wrz 2022 o 11:46 Delany  napisał(a):
> >
> > > I used to place them in /.mvn/settings.xml but khmarbaise
> > advised
> > > against, so I inject the settings.xml file in via a Jenkins plugin
> > > Delany
> > >
> > > On Tue, 13 Sept 2022 at 11:33, Sverre Moe 
> wrote:
> > >
> > > > But I still need to provide the settings.xml on all servers, and to
> all
> > > > users from somewhere.
> > > > Is there any way to repackage the maven distribution to include our
> > > > settings.xml like we do for the Gradle distribution?
> > > >
> > > > It would help if we could refer to an URL and not file. However then
> > all
> > > > who use the Maven Wrapper need to write a very long command line.
> > > > ./mvnw --settings
> > > > https://nexus.company.com:8443/repository/java/maven/settings.xml
> > clean
> > > > install
> > > >
> > > > tir. 13. sep. 2022 kl. 10:16 skrev Mantas Gridinas <
> > mgridi...@gmail.com
> > > >:
> > > >
> > > > > You can override which settings file is used with --settings flag.
> > > > >
> > > > > On Tue, Sep 13, 2022, 11:08 Sverre Moe 
> wrote:
> > > > >
> > > > > > I have been looking into the Maven Wrapper. We have mostly been
> > using
> > > > > > Gradle for new projects, but I was thinking of taking the Maven
> > > Wrapper
> > > > > in
> > > > > > use for our legacy projects that still use Maven.
> > > > > >
> > > > > > With Gradle we can create a custom gradle distribution that has
> all
> > > > > common
> > > > > > settings and properties needed by projects built by gradle.
> > > > > >
> > > > > > How can we do the same with Maven?
> > > > > >
> > > > > > Now we have the files settings.xml and settings-security.xml
> stored
> > > in
> > > > > > ~/.m2, which must be copied by all users into their own user home
> > > > > > directory.
> > > > > >
> > > > > > Running mvn wrapper:wrapper gave me this maven-wrapper.properties
> > > > > >
> > > > > > distributionUrl=
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://nexus.company.com:8443/repository/maven-public//org/apache/maven/apache-maven/3.8.4/apache-maven-3.8.4-bin.zip
> > > > > > wrapperUrl=
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://nexus.company.com:8443/repository/maven-public//org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar
> > > > > >
> > > > > > Even though the Maven Wrapper is downloaded from our Nexus, the
> > > > > > dependencies are not, until I provide the settings.xml.
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sławomir Jaranowski
> >
>

Re: Maven Wrapper: Using it with override settings.xml

[Delany]

I used to place them in /.mvn/settings.xml but khmarbaise advised
against, so I inject the settings.xml file in via a Jenkins plugin
Delany

On Tue, 13 Sept 2022 at 11:33, Sverre Moe  wrote:

> But I still need to provide the settings.xml on all servers, and to all
> users from somewhere.
> Is there any way to repackage the maven distribution to include our
> settings.xml like we do for the Gradle distribution?
>
> It would help if we could refer to an URL and not file. However then all
> who use the Maven Wrapper need to write a very long command line.
> ./mvnw --settings
> https://nexus.company.com:8443/repository/java/maven/settings.xml clean
> install
>
> tir. 13. sep. 2022 kl. 10:16 skrev Mantas Gridinas :
>
> > You can override which settings file is used with --settings flag.
> >
> > On Tue, Sep 13, 2022, 11:08 Sverre Moe  wrote:
> >
> > > I have been looking into the Maven Wrapper. We have mostly been using
> > > Gradle for new projects, but I was thinking of taking the Maven Wrapper
> > in
> > > use for our legacy projects that still use Maven.
> > >
> > > With Gradle we can create a custom gradle distribution that has all
> > common
> > > settings and properties needed by projects built by gradle.
> > >
> > > How can we do the same with Maven?
> > >
> > > Now we have the files settings.xml and settings-security.xml stored in
> > > ~/.m2, which must be copied by all users into their own user home
> > > directory.
> > >
> > > Running mvn wrapper:wrapper gave me this maven-wrapper.properties
> > >
> > > distributionUrl=
> > >
> > >
> >
> https://nexus.company.com:8443/repository/maven-public//org/apache/maven/apache-maven/3.8.4/apache-maven-3.8.4-bin.zip
> > > wrapperUrl=
> > >
> > >
> >
> https://nexus.company.com:8443/repository/maven-public//org/apache/maven/wrapper/maven-wrapper/3.1.1/maven-wrapper-3.1.1.jar
> > >
> > > Even though the Maven Wrapper is downloaded from our Nexus, the
> > > dependencies are not, until I provide the settings.xml.
> > >
> >
>

Re: maven-shade-plugin: excluding transitive dependencies from shade jar but having them appear in the pom.xml for the shade jar?

[Delany]

hi PJ. You can do like this:

true

  
org.apache.avro:avro
  


Kind regards,
Delany


On Sun, 4 Sept 2022 at 19:05, PJ Fanning 
wrote:

> Hi everyone,
> Apologies if this has been answered before but I searched around and
> couldn't find an answer.
> For Apache Hadoop, I'm looking to shade Apache Avro jar, relocating the
> avro classes to a new package name.
> This new jar would be published to Maven Central and used by Hadoop.
> The aim is not to include Jackson and other classes from transitive
> dependencies of Avro but that the pom file for the new jar would include
> the transitive dependencies from Avro.
>
> My PR is at https://github.com/apache/hadoop-thirdparty/pull/21
>
> Neither the pom.xml nor the dependency-reduced-pom.xml have the transitive
> dependencies listed.
>
> Would anyone be able to suggest how the dependencies excluded from the
> shade jar can be exposed as dependencies in the pom.xml?
>
> Regards,
> PJ
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Side effects of import scope?

[Delany]

Hi Herve,

The bom flattenMode in
https://www.mojohaus.org/flatten-maven-plugin/flatten-mojo.html
is "Like ossrh but additionally keeps dependencyManagement and properties"

If the properties are not going to be available to the importing project,
why not resolve them in dependencyManagement and leave them out of the bom?
Alternatively, if dependencyManagement should remain unresolved, why not
import the properties, allowing them to be overwritten by the importing
project?

Regards,
Delany

On Mon, 22 Aug 2022 at 14:28,  wrote:

> saying "publish these properties in a bom?" is confusing: properties from
> the BOM are not published
>
> the BOM is written using a property, for simplicity for example of
> defining a version that is used by many dependencies
>
> but that's to ease BOM writer maintenance: it does not publish anything to
> BOM consumer
>
> Regards,
>
> Hervé
>
> - Mail original -
> De: "Delany" 
> À: "Maven Users List" 
> Envoyé: Vendredi 19 Août 2022 12:43:55
> Objet: Re: Side effects of import scope?
>
> >> I don't see how any property from the imported model could affect the
> >> importing model
> >>
>
> > OK, good to know.
>
> It also can't be overwritten from the importing model, so what purpose does
> it serve to publish these properties in a bom?
>
> Regards,
> Delany
>
> On Thu, 18 Aug 2022 at 20:56, Laird Nelson  wrote:
>
> > On Wed, Aug 17, 2022 at 11:33 PM Herve Boutemy 
> > wrote:
> >
> > > I see one clarification to add to your "by value" explanation: what is
> > > imported is the dependencyManagement content from the *effective*
> > imported
> > > model, ie with its interpolation  (properties substitution) already
> done
> > >
> >
> > That's helpful; thanks.
> >
> >
> > > I don't see how any property from the imported model could affect the
> > > importing model
> > >
> >
> > OK, good to know.
> >
> >
> > > A few reference to source code:
> > > - the importer:
> > >
> > >
> >
> https://maven.apache.org/ref/3.8.6/maven-model-builder/xref/org/apache/maven/model/composition/DefaultDependencyManagementImporter.html
> > > - and the effective model resolution that happens before:
> > >
> > >
> >
> https://maven.apache.org/ref/3.8.6/maven-model-builder/xref/org/apache/maven/model/building/DefaultModelBuilder.html#L1236
> > >
> > > Hope this helps
> > >
> >
> > Very much, thanks.
> >
> > L
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Side effects of import scope?

[Delany]

>> I don't see how any property from the imported model could affect the
>> importing model
>>

> OK, good to know.

It also can't be overwritten from the importing model, so what purpose does
it serve to publish these properties in a bom?

Regards,
Delany

On Thu, 18 Aug 2022 at 20:56, Laird Nelson  wrote:

> On Wed, Aug 17, 2022 at 11:33 PM Herve Boutemy 
> wrote:
>
> > I see one clarification to add to your "by value" explanation: what is
> > imported is the dependencyManagement content from the *effective*
> imported
> > model, ie with its interpolation  (properties substitution) already done
> >
>
> That's helpful; thanks.
>
>
> > I don't see how any property from the imported model could affect the
> > importing model
> >
>
> OK, good to know.
>
>
> > A few reference to source code:
> > - the importer:
> >
> >
> https://maven.apache.org/ref/3.8.6/maven-model-builder/xref/org/apache/maven/model/composition/DefaultDependencyManagementImporter.html
> > - and the effective model resolution that happens before:
> >
> >
> https://maven.apache.org/ref/3.8.6/maven-model-builder/xref/org/apache/maven/model/building/DefaultModelBuilder.html#L1236
> >
> > Hope this helps
> >
>
> Very much, thanks.
>
> L
>

Re: Class defined on module path not found when running integration tests

[Delany]

Can you try running it directly without maven/failsafe
Use
https://maven.apache.org/plugins/maven-dependency-plugin/usage.html#dependency:build-classpath
Delany

On Sun, 31 Jul 2022 at 08:11, Ryan Lubke  wrote:

> Hey Folks,
>
> I’ve been looking into this issue for a couple of days now and have run
> out of ideas.
>
> Maven Version:3.8.5
> Maven Failsafe Version: 3.0.0-M7
> Java Version:17.0.4
> OS: MacOS   12.5/Apple Silicon
>
> The test compiles fine using the module path.
> When running my test, however, I receive a failure stating that class
> jakarta.annotation.Priority is not found.
>
> However, looking at the dependencies:
>
> <~/f/c/d/p/j/p/t/f/rest>-> mvn dependency:list -o | ag annotation
> [INFO]jakarta.annotation:jakarta.annotation-api:jar:2.0.0:compile
>
> The jar is certainly there.  If I look at the failsafe generated XML, the
> jar is present on the module path from the test run:
>
>  value=“...:/Users/me/.m2/repository/jakarta/annotation/jakarta.annotation-api/2.0.0/jakarta.annotation-api-2.0.0.jar:…”/>
>
> Looking at the JAR itself, the class there"
>
> <~/f/c/d/p/j/p/t/f/r/t/failsafe-reports>-> jar tvf
> /Users/me/.m2/repository/jakarta/annotation/jakarta.annotation-api/2.0.0/jakarta.annotation-api-2.0.0.jar
> | ag Priority
>457 Mon Oct 12 14:06:30 PDT 2020 jakarta/annotation/Priority.class
> <~/f/c/d/p/j/p/t/f/r/t/failsafe-reports>->
>
> As the dependency is transitive, I’ve also tried adding a direct
> dependency within the test module instead, but the result is the same.
>
> Not sure how to debug this further, thus my asking here.
>
> Any suggestions?
>
> Thanks,
> -rl
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: how to get latest plugin-version using mvn versions:display-plugin-updates?

[Delany]

What version of Maven are you running, and, more importantly, what version
of the versions-maven-plugin?
Are you invoking it like this:
mvn org.codehaus.mojo:versions-maven-plugin:2.11.0:display-plugin-updates -U
Delany


On Wed, 27 Jul 2022 at 15:59, Stephan Wissel  wrote:

> AFAIK -U updates Snapshot releases. It doesn't update or display newer
> plugin releases
>
> Create a nice day!
> Stephan H. Wissel
>
> Phone: +65 96673269
> Blog <https://www.wissel.net/blog> Twitter <http://twitter.com/notessensei
> >
> LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> <https://www.xing.com/profile/StephanH_Wissel>
>
>
> On Tue, Jul 26, 2022 at 10:44 AM Delany 
> wrote:
>
> > Always force an update with the -U switch.
> > Delany
> >
> > On Tue, 26 Jul 2022, 06:55 Stephan Wissel,  wrote:
> >
> > > When I run
> > >
> > > mvn versions:display-plugin-updates
> > >
> > > on my project, I get the result:
> > >
> > > [*INFO*] All plugins with a version specified are using the latest
> > > versions.
> > >
> > > [*INFO*]
> > >
> > > [*INFO*] All plugins have a version specified.
> > >
> > > [*INFO*]
> > >
> > > [*INFO*] Project requires minimum Maven version for build of: 3.8.1
> > >
> > > [*INFO*] Plugins require minimum Maven version of: null
> > >
> > > [*INFO*]
> > >
> > > [*INFO*] No plugins require a newer version of Maven than specified by
> > the
> > > pom.
> > >
> > > However when checking maven central, I find newer versions of the
> plugins
> > > used.
> > > (e.g. spotless-maven-plugin -> 2.22.8 -> 2.23.0)
> > > What do I miss?
> > >
> > > Create a nice day!
> > > Stephan H. Wissel
> > >
> > > Blog <https://www.wissel.net/blog> Twitter <
> > http://twitter.com/notessensei
> > > >
> > > LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> > > <https://www.xing.com/profile/StephanH_Wissel>
> > >
> >
>

Re: how to get latest plugin-version using mvn versions:display-plugin-updates?

[Delany]

Always force an update with the -U switch.
Delany

On Tue, 26 Jul 2022, 06:55 Stephan Wissel,  wrote:

> When I run
>
> mvn versions:display-plugin-updates
>
> on my project, I get the result:
>
> [*INFO*] All plugins with a version specified are using the latest
> versions.
>
> [*INFO*]
>
> [*INFO*] All plugins have a version specified.
>
> [*INFO*]
>
> [*INFO*] Project requires minimum Maven version for build of: 3.8.1
>
> [*INFO*] Plugins require minimum Maven version of: null
>
> [*INFO*]
>
> [*INFO*] No plugins require a newer version of Maven than specified by the
> pom.
>
> However when checking maven central, I find newer versions of the plugins
> used.
> (e.g. spotless-maven-plugin -> 2.22.8 -> 2.23.0)
> What do I miss?
>
> Create a nice day!
> Stephan H. Wissel
>
> Blog <https://www.wissel.net/blog> Twitter <http://twitter.com/notessensei
> >
> LinkedIn <http://sg.linkedin.com/in/notessensei> Xing
> <https://www.xing.com/profile/StephanH_Wissel>
>

Re: require dependency declaration

[Delany]

Ok, sure that's one approach. It does kinda offset the caching benefit of
having a local repo.
But more seriously for me it prevents partial builds, which is the same as
enforcing
https://maven.apache.org/enforcer/enforcer-rules/reactorModuleConvergence.html

I wondering why this is permitted? The dependency is not part of the model,
so why is it available?
The impact of turning this off in the next Maven is that incorrectly
configured projects might fail to build.
Far reaching consequences, but completely just and reasonable and forward
thinking.

Delany

On Wed, 13 Jul 2022 at 15:21, Mantas Gridinas  wrote:

> I circumvented that by setting custom repository directory every time via
> maven.repo.local
>
> Seems that you can configure your repository in settings.xml to use update
> policy "always" for releases to make sure that its always downloaded. I
> cannot comment on how that would work if artifact is already present and
> download fails though.
>
> On Wed, Jul 13, 2022, 16:15 Delany  wrote:
>
> > Hi Maven,
> >
> > A project was missing a dependency junit:junit and would fail to build on
> > Jenkins, where the .m2/repository is removed for each build.
> > On my machine this dependency happens to be in .m2/repository and the
> > project would build fine.
> >
> > How can I make it not fine? I don't want my projects taking whatever they
> > need from maven local repository without a 
> >
> > Thanks
> > Delany
> >
>

require dependency declaration

[Delany]

Hi Maven,

A project was missing a dependency junit:junit and would fail to build on
Jenkins, where the .m2/repository is removed for each build.
On my machine this dependency happens to be in .m2/repository and the
project would build fine.

How can I make it not fine? I don't want my projects taking whatever they
need from maven local repository without a 

Thanks
Delany

Re: Maven Wrapper merge issues during release

[Delany]

Are u running Windows? Use another mvn to perform the update.
Delany

On Mon, 27 Jun 2022, 22:31 John Patrick,  wrote:

> Anyone having issues with maven wrapper, when you upgrade the jar as part
> of a release?
>
> i.e.
> develop branch
> .mvn/wrapper/maven-wrapper.jar is 3.1.1
>
> main branch
> .mvn/wrapper/maven-wrapper.jar is 3.1.0
>
> I'm using gitflow-maven-plugin (
> https://github.com/aleksandr-m/gitflow-maven-plugin) but the merge fails
> as
> the jar is being locked by the running process...
>
> The solution i've got is to do manual commit to main with updated
> maven-wrapper.jar, then try the release again.
>
> Anyone else seen this issue or got a better work around?
>
> John
>

passing properties to junit

[Delany]

Hi there,

JUnit5.9.0-M1 was released that allows to conditionally cleanup the files
created using @TempDir

Problem Im having is how to configure junit properties through surefire.
My attempts at the bottom of:
https://github.com/junit-team/junit5/issues/2159


  
junit.jupiter.tempdir.cleanup.mode.default=on_success

org.apache.logging.log4j.simplelog.StatusLogger.level=info



With -X I can see this leaves the default mode "unmodified". There is no
mention of the junit directory in the logs.

Thanks,
Delany

Re: How to retrieve target folder or jar paths from multi-module Maven project

[Delany]

That's what he wants.
The surest way is just to build the thing and `find */target -iname "*.jar"`
Need more info why its needed.

On Fri, 10 Jun 2022 at 08:40, Mantas Gridinas  wrote:

> Wouldn't the help plugin get executed for every module in the reactor and
> in turn output multiple build directories?
>
> On Fri, Jun 10, 2022, 09:04 Delany  wrote:
>
> > Building on this, you could try this bash script. It is very slow
> >
> > while read -r pom; do mvn help:evaluate
> > -Dexpression=project.build.directory -q -DforceStdout -f $pom && echo;
> done
> > < <(find . -iname pom.xml)
> >
> >
> > On Thu, 9 Jun 2022 at 21:20, Bernd Eckenfels 
> > wrote:
> >
> > > The Maven Help Plugin has some functions, including printing evaluated
> > > project parameters.
> > >
> > >
> > > RESULT=$(mvn help:evaluate -Dexpression=project.version -q
> -DforceStdout)
> > >
> > > https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html
> > >
> > >
> > > --
> > > http://bernd.eckenfels.net
> > > 
> > > Von: Laurian Angelescu 
> > > Gesendet: Tuesday, June 7, 2022 5:43:26 PM
> > > An: users@maven.apache.org 
> > > Betreff: How to retrieve target folder or jar paths from multi-module
> > > Maven project
> > >
> > > Is it possible to invoke *mvn* on the command line to output either 1)
> > the
> > > paths to all target folders where jars get packaged or 2) the file
> paths
> > of
> > > the jars themselves?
> > >
> > > For example, in a multi-module project like
> > > https://github.com/apache/httpcomponents-core.git, I would like to
> > invoke:
> > >
> > > *mvn *
> > >
> > > and have output to standard out:
> > >
> > > //httpcore5/target/httpcore5-5.2-beta1.jar
> > > //httpcore5-h2/target/httpcore5-h2-5.2-beta1.jar
> > > ...
> > > etc.
> > >
> > > I want to essentially be able to get a list of the JARs created in *any
> > > *Maven
> > > multimodule project.
> > >
> >
>

Re: How to retrieve target folder or jar paths from multi-module Maven project

[Delany]

Building on this, you could try this bash script. It is very slow

while read -r pom; do mvn help:evaluate
-Dexpression=project.build.directory -q -DforceStdout -f $pom && echo; done
< <(find . -iname pom.xml)


On Thu, 9 Jun 2022 at 21:20, Bernd Eckenfels  wrote:

> The Maven Help Plugin has some functions, including printing evaluated
> project parameters.
>
>
> RESULT=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)
>
> https://maven.apache.org/plugins/maven-help-plugin/evaluate-mojo.html
>
>
> --
> http://bernd.eckenfels.net
> 
> Von: Laurian Angelescu 
> Gesendet: Tuesday, June 7, 2022 5:43:26 PM
> An: users@maven.apache.org 
> Betreff: How to retrieve target folder or jar paths from multi-module
> Maven project
>
> Is it possible to invoke *mvn* on the command line to output either 1) the
> paths to all target folders where jars get packaged or 2) the file paths of
> the jars themselves?
>
> For example, in a multi-module project like
> https://github.com/apache/httpcomponents-core.git, I would like to invoke:
>
> *mvn *
>
> and have output to standard out:
>
> //httpcore5/target/httpcore5-5.2-beta1.jar
> //httpcore5-h2/target/httpcore5-h2-5.2-beta1.jar
> ...
> etc.
>
> I want to essentially be able to get a list of the JARs created in *any
> *Maven
> multimodule project.
>

long running threads from shade-plugin recently updated dep jdom2

[Delany]

Hi

My build was taking unusually long (28m vs 9m) and it seemed to stall
installing all artefacts at the end, so I pressed ctrl+\ to create a JVM
profile and I noticed this long running thread.
Any comments?

"mvn-builder-artifactcommandline" #25 prio=5 os_prio=0 cpu=1302760.01ms
elapsed=1412.09s tid=0x7f75e0345800 nid=0x1243e1 runnable
 [0x7f75a86c7000]
   java.lang.Thread.State: RUNNABLE
at
org.apache.maven.plugins.shade.pom.MavenJDOMWriter.insertAtPreferredLocation(MavenJDOMWriter.java:282)
at
org.apache.maven.plugins.shade.pom.MavenJDOMWriter.iterateExclusion(MavenJDOMWriter.java:498)
at
org.apache.maven.plugins.shade.pom.MavenJDOMWriter.updateDependency(MavenJDOMWriter.java:1343)
at
org.apache.maven.plugins.shade.pom.MavenJDOMWriter.iterateDependency(MavenJDOMWriter.java:396)
at
org.apache.maven.plugins.shade.pom.MavenJDOMWriter.updateModel(MavenJDOMWriter.java:1632)
at
org.apache.maven.plugins.shade.pom.MavenJDOMWriter.write(MavenJDOMWriter.java:2168)
at
org.apache.maven.plugins.shade.pom.PomWriter.write(PomWriter.java:75)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.rewriteDependencyReducedPomIfWeHaveReduction(ShadeMojo.java:1201)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.createDependencyReducedPom(ShadeMojo.java:1130)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:486)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:301)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:210)

at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:195)

at java.util.concurrent.FutureTask.run(
java.base@11.0.14.1/FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call(
java.base@11.0.14.1/Executors.java:515)
at java.util.concurrent.FutureTask.run(
java.base@11.0.14.1/FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker(
java.base@11.0.14.1/ThreadPoolExecutor.java:1128)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(
java.base@11.0.14.1/ThreadPoolExecutor.java:628)
at java.lang.Thread.run(java.base@11.0.14.1/Thread.java:829)

Thanks
Delany

Re: Shading, relocation and modules?

[Delany]

Hi Niels,

I don't see an existing resource transformer for module-info
https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html

Did you see this?
https://stackoverflow.com/a/58097561/2746335

Delany

On Tue, 12 Apr 2022 at 11:16, Niels Basjes  wrote:

> Thanks.
>
> I was hoping for a "native" Java solution instead of an (apparently
> necessary) external plugin that hacks this in.
>
> Niels
>
> On Mon, Apr 11, 2022 at 11:32 PM Daniel B. Widdis 
> wrote:
>
> > > My question is what is the correct/preferred/recommended way to do
> this?
> >
> > Not combine shading and JPMS! :-)
> >
> > But seriously.  Have a look at Moditect.  It has the capability of
> adding a
> > module-descriptor to a JAR after the fact, and may suit your needs.  I
> > honestly can't think of any other sane way to go about this.
> >
> > moditect/moditect: Tooling for the Java Module System (github.com)
> > <https://github.com/moditect/moditect>
> >
> >
> >
> >
> > On Mon, Apr 11, 2022 at 1:29 PM Niels Basjes  wrote:
> >
> > > Hi,
> > >
> > > I have a project ( https://yauaa.basjes.nl/ ) which is a library that
> is
> > > used by others as a dependency.
> > > My project uses (among other things) Antlr4 as a building block.
> > > Antlr4 is a code generator that is (rightfully) very strict about the
> > > Antlr4-runtime version available at runtime: they must be identical
> > > versions.
> > >
> > > I do not want to impose "my" Antlr4 version onto the users of my
> library
> > so
> > > I have shaded and relocated the correct Antlr4 version into my final
> jar.
> > > Now anyone can use it next to a different Antrl4 version in the same
> > > application without any conflicts.
> > >
> > > Entering JPMS...
> > >
> > > I'm trying to make my library as "JPMS" as possible.
> > >
> > > From what I understand at this time: when I shade some dependencies
> into
> > my
> > > final jar the modules-info is removed by the maven-shade-plugin as this
> > > would break everything.
> > >
> > > In general I agree with this; yet in my case all of the shaded
> > > dependencies:
> > > 1) Have been relocated to a new package that does not exist anywhere
> > else (
> > > nl.basjes.shaded. ).
> > > 2) None of these should be visible outside the module.
> > >
> > > So in my mind these classes are modified to become "my" classes as they
> > are
> > > moved to my namespace and I expect them to fall under similar rules as
> > the
> > > classes I have created.
> > >
> > > Yet I have not yet been successful in making all of this work.
> > >
> > > My question is what is the correct/preferred/recommended way to do
> this?
> > >
> > > --
> > > Best regards / Met vriendelijke groeten,
> > >
> > > Niels Basjes
> > >
> >
> >
> > --
> > Dan Widdis
> >
>
>
> --
> Best regards / Met vriendelijke groeten,
>
> Niels Basjes
>

forking plugins

[Delany]

Hi all

I've been having some issues with plugins that run out of lifecycle, or
fork the lifecycle. For example

mvn org.openrewrite.maven:rewrite-maven-plugin:4.22.2:run
-Drewrite.activeRecipes=org.openrewrite.java.cleanup.NoPrimitiveWrappersForToStringOrCompareTo

This fails on one of my modules that depend on a previous module having
progressed to the "prepare-package" phase.
I've always assumed that having a dependency on another module means
requiring that the module reach the "package" phase, if it's in the same
reactor, or the "install" phase if it's not.

Question 1: Is this an unreasonable assumption? Is there a convention to be
followed here?

Another older project that seems to have stumbled over legal issues is the
macker-maven-plugin. It allows you to shape your package architecture with
rules about who can import what.
The last work on this project was a pull request to not fork

https://github.com/andrena/macker-maven-plugin/pull/6

I didn't used to have trouble with forking plugins, but recently I
implemented https://mapstruct.org/
Mapstruct is an annotation processor for mapping objects.
It seems annotation processors may only run once so as to guarantee the
reliability of their outputs? With a forking plugin this rule is broken.
I have to skip over my mapstruct project when running either
rewrite-maven-plugin or macker-maven-plugin.

Question 2: Is this a problem with my project structure, with the plugins
Im trying to run, with the mapstruct project itself, or with Maven?

Thanks,
Delany

Re: Remove SNAPSHOT from all sub-modules, but honor version

[Delany]

Hi Mike,

The convention to keep modules versions the same can be enforced
https://maven.apache.org/enforcer/enforcer-rules/reactorModuleConvergence.html

When they're the same you can drop the version tag and let children inherit
that from the parent.

But you'll still need to edit the parent/version.
SNAPSHOT is part of the version number, not a classifier, so
version-maven-plugin is evidently filtering the projects before
transforming the version number.

I set my ${changelist} property to "-SNAPSHOT" to manage this, i.e.
3.3.0${changelist}

If you dont want to do that and its still too much work to manually edit
version you can try an xslt transform

  sudo apt install libsaxonb-java xmlstartlet sponge
  while read pom; do saxonb-xslt -s:$pom -xsl:/tmp/remove-snapshot.xslt |
xmlstarlet fo | sponge $pom; done < <(find . -iname pom.xml)

Delany

/tmp/remove-snapshot.xslt
http://www.w3.org/1999/XSL/Transform;>
  

  

  

  

  

  

  

  





On Sat, 2 Apr 2022 at 10:32, Mike Deitrick  wrote:

> Any guidance on this matter?
>
> On Fri, Mar 4, 2022, 7:53 AM Mike Deitrick 
> wrote:
>
> > Hello,
> >
> > A couple days ago I submitted a question on Stack Overflow about this
> > topic. It can be found here
> > <
> https://stackoverflow.com/questions/71329400/remove-snapshot-from-all-maven-sub-modules-but-honor-version
> >.
> > For the purposes of preserving this conversation, I will also provide my
> > question below, along with some things I've found along the way. The
> > commenter mentioned that the version of all modules within a multi-module
> > project should be the same to drop -SNAPSHOT with the mvn versions:set
> command.
> > Furthermore, a section in the POM file title Aggregation (or
> Multi-Module)
> > <https://maven.apache.org/pom.html#aggregation-or-multi-module> seems to
> > provide some insight into what's going on, but my inferences might be
> > incorrect about versions needing to be consistent based on the content in
> > that section.
> >
> > So, what is the official practice for versions of sub-modules in a
> > multi-module project? Should all versions be the same as the version in
> the
> > parent POM? If it's acceptable for sub-module versions to be different,
> how
> > does one accomplish stripping -SNAPSHOT from all modules (preferably
> with a
> > Maven plugin versus running commands to iterate over all sub-directories
> to
> > find child POMs and drop -SNAPSHOT from each)?
> >
> > Thank you.
> > Mike
> >
> > ---
> >
> > I am working on a multi-module project. For the purposes of this exercise
> > we can assume there are two sub-modules. The articles Maven Simple
> > Project Archetype
> > <https://maven.apache.org/archetypes/maven-archetype-simple/> and Create
> > an archetype from a multi-module project
> > <
> https://maven.apache.org/archetype/maven-archetype-plugin/examples/create-multi-module-project.html>
> can
> > be referenced to follow along.
> >
> > Parent - 1.0.0-SNAPSHOT
> > ChildA - 1.2.3-SNAPSHOT
> > ChildB - 1.0.0-SNAPSHOT
> >
> > When I run mvn versions:set -D removeSnapshot -D processAllModules I
> > expect the versions to change as indicated below.
> >
> > Parent - 1.0.0
> > ChildA - 1.2.3
> > ChildB - 1.0.0
> >
> > But, it seems -SNAPSHOT is stripped from all versions except the children
> > that have a different version from the parent.
> >
> > Parent - 1.0.0
> > ChildA - 1.2.3-SNAPSHOT
> > ChildB - 1.0.0
> >
> > Is there any way to run the mvn versions:set command to honor the version
> > number, while stripping the -SNAPSHOT postfix?
> > --
> >
> > *UPDATE #1*
> >
> > Running mvn versions:set -D removeSnapshot=true yields the same results
> > as running mvn versions:set -D removeSnapshot -D processAllModules.
> >
> > Parent - 1.0.0
> > ChildA - 1.2.3-SNAPSHOT
> > ChildB - 1.0.0
> >
> >
>

Re: My maven failed to download the plug-in

[Delany]

"Clean up the broken artifacts data and reload the project" is not an error
Maven will give.
What program are you using? It sounds like an IDE of some sort.

In addition to explaining your problem you need to paste the commands you
ran and the errors you got.
Links to screenshots could also help. Images are removed on this mailing
list.

Regards,
Delany


On Thu, 17 Mar 2022 at 09:13, 2313835217 <2313835...@qq.com.invalid> wrote:

> I had an error downloading the plugin while using Maven
>
> The error is Clean up the broken artifacts data and reload the project.
>
>
>
>
>
> 2313835217
> 2313835...@qq.com
>
>
>
> 

ci properties not working

[Delany]

Hi. I tried making the version numbers dynamic with CI friendly properties
on

https://github.com/delanym/maven/commit/92b524a74f084b5def2fd807793b0e74d1ec02ed

When I build I get

[FATAL] Non-resolvable parent POM for
org.apache.maven:maven-plugin-api:4.0.0-alpha-1-SNAPSHOT: Could not find
artifact org.apache.maven:maven:pom:4.0.0-alpha-1-SNAPSHOT and
'parent.relativePath' points at wrong
 local POM @ line 25, column 11

I use CI friendly properties without a problem in my own project. What am I
missing?

Thanks,
Delany

Re: Run all tests (also in dependent modules), fail build at end

[Delany]

I understand your use case Alex, just not your process. As this is the
users list Im not about to solve the issue of a missing --fail-all-at-end
switch, but I could try to think of workarounds.
Delany


On Sat, 26 Feb 2022 at 09:32, Alexander Kriegisch 
wrote:

> Delany,
>
> you are completely misunderstanding my use case. I am building with
> every push, that is the pain, because I have a choice to
>
>   -- either see all test results with '-fn' but get a wrong build result
>  (passed)
>
>   -- or fewer test results with '-fae' and a correct build result
>  (failed).
>
> I do *not* wish to run tests in a later phase. I have no idea where you
> got that idea from. I simply want the build to continue for modules
> dependent on ones with failing tests, so I can find out if they build
> successfully and whether or not they also have failing tests. Then in
> the end, after all modules have been built and all tests run (for those
> modules which could actually be built without compile errors, of
> course), I want to see an overall test result and a properly failed
> build. In plain English: I want what '-fae' always should have done to
> begin with. I really don't know what is so difficult to understand about
> this simple requirement: build as much as possible, test as much as
> possible, then report the correct result at the end. I want failed tests
> to fail the build in the end, but I do not want them to keep dependent
> modules from being built and tested.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Delany schrieb am 26.02.2022 14:17 (GMT +07:00):
>
> > Oh its not, im just being thorough.
> > It just seems like your build iteration isn't frequent enough. If you're
> > not building on every MR/PR or with every push, maybe you need a separate
> > test build. Or maybe your reactor is too large and you need to split it
> > into separate projects. You could also leave the reactor but build via a
> > script that looks for pom files and tests them one at a time. Ugly, but
> > effective.
> > Bottom line is that install and deploy phases don't create dependencies
> > within a reactor, so its no biggy that they delay their execution until
> > after. Anything that happens before then does, and its not unreasonable
> to
> > expect development to work within that constraint.
> > Delany
> >
> >
> > On Fri, 25 Feb 2022 at 19:40, Alexander Kriegisch <
> alexan...@kriegisch.name>
> > wrote:
> >
> >> Thanks for digging, Delany. However, I am failing to see how this is
> >> meant to solve my problem. Could you elaborate, please?
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >>
> >>
> >> Delany schrieb am 25.02.2022 18:05 (GMT +07:00):
> >>
> >> > Alexander, here it is: https://github.com/raydac/mvn-finisher
> >> > Delany
> >> >
> >> > On Mon, 7 Feb 2022 at 08:17, Delany 
> wrote:
> >> >
> >> >> Someone already wrote an "at end maven plugin". I used it for a while
> >> but
> >> >> removed it. Can't for the life of me find it in
> >> >> github/google/confluence/git log. Sorry!
> >> >> Delany
> >> >>
> >> >>
> >> >> On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch <
> >> alexan...@kriegisch.name>
> >> >> wrote:
> >> >>
> >> >>> >> In case you are ready to make you own plugin, it is relatively
> easy.
> >> >>>
> >> >>> I am not, Lasse. I also want this to work on the command line and
> not
> >> >>> depend on CI-system-specific workarounds. But thank you for your
> >> >>> insightful ideas, I really appreciate them.
> >> >>>
> >> >>> Tibor, actually I wanted to avoid a potentially lengthy debate on
> basic
> >> >>> principles, but I agree on having one, if you feel it is necessary.
> I
> >> >>> owe you that much, because it tells me that you are not taking
> design
> >> >>> decisions lightly. So if I can contribute to your decision-making
> >> >>> process, I shall humbly do so. Not being a Maven (plugin) developer
> >> >>> myself, but rather a just user with a bit of background knowledge,
> I in
> >> >>> fact did previously in this thread comment on the two famous
> '*AtEnd'
> >> >>> precedence cases already:
> >> >>>
> >> >>> >>>> Install and

Re: Run all tests (also in dependent modules), fail build at end

[Delany]

Oh its not, im just being thorough.
It just seems like your build iteration isn't frequent enough. If you're
not building on every MR/PR or with every push, maybe you need a separate
test build. Or maybe your reactor is too large and you need to split it
into separate projects. You could also leave the reactor but build via a
script that looks for pom files and tests them one at a time. Ugly, but
effective.
Bottom line is that install and deploy phases don't create dependencies
within a reactor, so its no biggy that they delay their execution until
after. Anything that happens before then does, and its not unreasonable to
expect development to work within that constraint.
Delany


On Fri, 25 Feb 2022 at 19:40, Alexander Kriegisch 
wrote:

> Thanks for digging, Delany. However, I am failing to see how this is
> meant to solve my problem. Could you elaborate, please?
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Delany schrieb am 25.02.2022 18:05 (GMT +07:00):
>
> > Alexander, here it is: https://github.com/raydac/mvn-finisher
> > Delany
> >
> > On Mon, 7 Feb 2022 at 08:17, Delany  wrote:
> >
> >> Someone already wrote an "at end maven plugin". I used it for a while
> but
> >> removed it. Can't for the life of me find it in
> >> github/google/confluence/git log. Sorry!
> >> Delany
> >>
> >>
> >> On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch <
> alexan...@kriegisch.name>
> >> wrote:
> >>
> >>> >> In case you are ready to make you own plugin, it is relatively easy.
> >>>
> >>> I am not, Lasse. I also want this to work on the command line and not
> >>> depend on CI-system-specific workarounds. But thank you for your
> >>> insightful ideas, I really appreciate them.
> >>>
> >>> Tibor, actually I wanted to avoid a potentially lengthy debate on basic
> >>> principles, but I agree on having one, if you feel it is necessary. I
> >>> owe you that much, because it tells me that you are not taking design
> >>> decisions lightly. So if I can contribute to your decision-making
> >>> process, I shall humbly do so. Not being a Maven (plugin) developer
> >>> myself, but rather a just user with a bit of background knowledge, I in
> >>> fact did previously in this thread comment on the two famous '*AtEnd'
> >>> precedence cases already:
> >>>
> >>> >>>> Install and Deploy plugins (...): 'installAtEnd' and 'deployAtEnd'
> >>> >>>> are blessings IMO, and they are cornerstones of my work, because
> >>> >>>> they help to avoid half-installed and - even worse - half-deployed
> >>> >>>> multi-module projects which would lead to inconsistencies in
> >>> >>>> repositories and might be hard to rectify in remote repositories,
> >>> >>>> "burning" release numbers unnecessarily.
> >>>
> >>> The gist is: Those '*AtEnd' features have user value. If you say that
> >>> they might be difficult to maintain and shield against side effects, I
> >>> have to take your word for it. So we have a trade-off situation here,
> >>> chances vs risks. As the person requesting such a feature, of course I
> >>> have a chances bias. As a plugin maintainer, of course you take a more
> >>> conservative or defensive stance. I understand that. In the end, it is
> >>> your decision. Hopefully others here can contribute more substantially
> >>> to the discussion than I can.
> >>>
> >>> --
> >>> Alexander Kriegisch
> >>> https://scrum-master.de
> >>>
> >>> -
> >>> 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: Run all tests (also in dependent modules), fail build at end

[Delany]

Alexander, here it is: https://github.com/raydac/mvn-finisher
Delany

On Mon, 7 Feb 2022 at 08:17, Delany  wrote:

> Someone already wrote an "at end maven plugin". I used it for a while but
> removed it. Can't for the life of me find it in
> github/google/confluence/git log. Sorry!
> Delany
>
>
> On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch 
> wrote:
>
>> >> In case you are ready to make you own plugin, it is relatively easy.
>>
>> I am not, Lasse. I also want this to work on the command line and not
>> depend on CI-system-specific workarounds. But thank you for your
>> insightful ideas, I really appreciate them.
>>
>> Tibor, actually I wanted to avoid a potentially lengthy debate on basic
>> principles, but I agree on having one, if you feel it is necessary. I
>> owe you that much, because it tells me that you are not taking design
>> decisions lightly. So if I can contribute to your decision-making
>> process, I shall humbly do so. Not being a Maven (plugin) developer
>> myself, but rather a just user with a bit of background knowledge, I in
>> fact did previously in this thread comment on the two famous '*AtEnd'
>> precedence cases already:
>>
>> >>>> Install and Deploy plugins (...): 'installAtEnd' and 'deployAtEnd'
>> >>>> are blessings IMO, and they are cornerstones of my work, because
>> >>>> they help to avoid half-installed and - even worse - half-deployed
>> >>>> multi-module projects which would lead to inconsistencies in
>> >>>> repositories and might be hard to rectify in remote repositories,
>> >>>> "burning" release numbers unnecessarily.
>>
>> The gist is: Those '*AtEnd' features have user value. If you say that
>> they might be difficult to maintain and shield against side effects, I
>> have to take your word for it. So we have a trade-off situation here,
>> chances vs risks. As the person requesting such a feature, of course I
>> have a chances bias. As a plugin maintainer, of course you take a more
>> conservative or defensive stance. I understand that. In the end, it is
>> your decision. Hopefully others here can contribute more substantially
>> to the discussion than I can.
>>
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: martifact won't inherit project.build.outputTimestamp

[Delany]

Thanks I'll send PR.
Since you ask, I think Maven should allow silencing any warning for any
plugin, but that's for another day.

I'm not able to compare builds. I run `mvn clean install`, and `mvn clean
package artifact:compare` and I get an error "could not find repository
with id = central"
If I set referenceRepo to  it still
complains "could not find repository with id = central"
If I set referenceRepo to a custom repository and it predictably can't
download the .buildinfo file, it gives a NPE
What should I do?

I checked out maven source code (which doesn't use maven-artifact-plugin).
I added the plugin buildinfo goal, rebuilt, and did a comparison. It says

[INFO] --- maven-artifact-plugin:3.2.0:compare (default-cli) @ apache-maven
---

[WARNING] SCM source tag in buildinfo source.scm.tag=maven-3.8.3 does not
permit rebuilders reproducible source checkout

[INFO] Saved aggregate info on build to
/git/maven/apache-maven/target/apache-maven-3.8.4-SNAPSHOT.buildinfo

[INFO] Aggregate buildinfo copied to
/git/maven/target/maven-3.8.4-SNAPSHOT.buildinfo


[INFO] Checking against reference build from central-mirror...

[INFO] Reference buildinfo file found, copied to
/git/maven/target/reference/apache-maven-3.8.4-SNAPSHOT.buildinfo

[INFO] Reproducible Build output summary: 32 files ok


[INFO] Reproducible Build output comparison saved to
/git/maven/apache-maven/target/apache-maven-3.8.4-SNAPSHOT.buildcompare

[INFO] Aggregate buildcompare copied to
/git/maven/target/maven-3.8.4-SNAPSHOT.buildcompare

Is there really an "apache-maven-3.8.4-SNAPSHOT.buildinfo" available at
Central?

Regards,
Delany

On Thu, 10 Feb 2022 at 04:46, Hervé BOUTEMY  wrote:

> Le mercredi 9 février 2022, 09:31:00 CET Delany a écrit :
> > Hi Herve,
> >
> > I see you already check that the project.parent was part of the reactor
> and
> > you don't issue the warning if it is.
> > An edge case is the -rf switch. Even though you have the opportunity to
> > change files, the sense is that it is the same build being resumed, so I
> > would also not warn in this case.
> PRs welcome
> and eventually an evaluation of "is this purely theory or really a use
> case
> I'll face?" aspect: I honestly don't see why I would do a reproducibility
> check with "-pr", or if it while making precisely one module reproducible,
> the
> message is not ideal but not really harmful
>
> >
> > The word parent can have two meanings here so rather avoid it in the
> > message. If the project.parent is not part of the build, then can you
> warn
> > 'outputTimestamp is inherited from groupId:artifactId but it is not
> > included in the build'.
> message is coded here
> https://github.com/apache/maven-artifact-plugin/blob/
> master/src/main/java/org/apache/maven/plugins/artifact/buildinfo/
> AbstractBuildinfoMojo.java#L158
> <https://github.com/apache/maven-artifact-plugin/blob/master/src/main/java/org/apache/maven/plugins/artifact/buildinfo/AbstractBuildinfoMojo.java#L158>
>
> gives at runtime:
>
> [WARNING] project.build.outputTimestamp property should not be inherited
> but
> defined in parent POM from reactor /home/me/project/pom.xml
>
> please propose rephrasing
>
> > If you make this warning configurable then a more in-depth explanation
> > could be included in that documentation.
> what do you think should be configurable?
>
> >
> > BTW the build commands you gave suggest that artifact:compare will use
> the
> > local Maven repository as its reference repo. Isn't this a more sensible
> > default?
> I gave commands to locally test during SNAPSHOT development, to detect and
> fix
> if there are issues: then yes, in that case, comparison is done between 2
> local builds, that's why the first command need to be install
>
> If it's about a release that has been published (eventually by someone
> else),
> "of course" you should do the first "install" run but only the second
> "package
> artifact:compare", and you'll see that by default it compares against
> central
> Just try to rebuild an artifact that was published by someone else = the
> ultimate goal, to check that you can rebuild what you are downloading
>
> and FYI, the Reproducible Central project is about rebuilding and checking
> such artifacts from central:
> https://github.com/jvm-repo-rebuild/reproducible-central
>
> Regards,
>
> Hervé
>
> >
> > Thanks,
> > Delany
> >
> > On Wed, 9 Feb 2022 at 09:25, Hervé BOUTEMY 
> wrote:
> > > Hi Delany,
> > >
> > > Good question: let's see if we can improve the message that I added in
> > > MARTIFACT-28 [1]
> > >
> > > First, rem

Re: martifact won't inherit project.build.outputTimestamp

[Delany]

Hi Herve,

I see you already check that the project.parent was part of the reactor and
you don't issue the warning if it is.
An edge case is the -rf switch. Even though you have the opportunity to
change files, the sense is that it is the same build being resumed, so I
would also not warn in this case.

The word parent can have two meanings here so rather avoid it in the
message. If the project.parent is not part of the build, then can you warn
'outputTimestamp is inherited from groupId:artifactId but it is not
included in the build'.
If you make this warning configurable then a more in-depth explanation
could be included in that documentation.

BTW the build commands you gave suggest that artifact:compare will use the
local Maven repository as its reference repo. Isn't this a more sensible
default?

Thanks,
Delany


On Wed, 9 Feb 2022 at 09:25, Hervé BOUTEMY  wrote:

> Hi Delany,
>
> Good question: let's see if we can improve the message that I added in
> MARTIFACT-28 [1]
>
> First, remember that it's all about Reproducible Builds [2].
> As described in the MARTIFACT-28 issue, inheriting the parent pom release
> timestamp technically works (it gives a reproducible value to your current
> build), but does not match the current release/build timestamp: you
> probably
> prefer to have a timestamp defined in your reactor
> = that is the message that we need to make as clear as possible
>
> Don't hesitate to propose an updated message that fits inclusion in a
> plugin
> output...
>
>
> Notice that I'm surprised of your choice to set the outputTimestamp to $
> {maven.build.timestamp}, given this value is not reproducible (if you
> build 2
> time the same code, you'll get 2 different values), choosing this value
> defeats
> the whole purpose of the configuration.
> Remember, it's all about Reproducible Builds, and your objective is to run
> the
> build 2 times and check you get the same binary output:
>
> mvn clean install
> mvn clean package artifact:compare
>
> Regards,
>
> Hervé
>
> [1] https://issues.apache.org/jira/browse/MARTIFACT-28
>
> [2] https://maven.apache.org/guides/mini/guide-reproducible-builds.html
>
> Le mardi 8 février 2022, 11:04:33 CET Delany a écrit :
> > Hi. Why does maven-artifact-plugin complain
> >
> >   [WARNING] project.build.outputTimestamp property should not be
> inherited
> > but defined in parent POM from reactor
> >
> > I never had a plugin complain about utilizing inheritance. Why does it
> care?
> > When I add the line to the project the warning disappears
> >
> >
> >
> ${maven.build.timestamp} > tTimestamp>
> >
> > Thanks,
> > Delany
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

martifact won't inherit project.build.outputTimestamp

[Delany]

Hi. Why does maven-artifact-plugin complain

  [WARNING] project.build.outputTimestamp property should not be inherited
but defined in parent POM from reactor

I never had a plugin complain about utilizing inheritance. Why does it care?
When I add the line to the project the warning disappears


${maven.build.timestamp}

Thanks,
Delany

Re: Run all tests (also in dependent modules), fail build at end

[Delany]

Someone already wrote an "at end maven plugin". I used it for a while but
removed it. Can't for the life of me find it in
github/google/confluence/git log. Sorry!
Delany


On Mon, 7 Feb 2022 at 04:38, Alexander Kriegisch 
wrote:

> >> In case you are ready to make you own plugin, it is relatively easy.
>
> I am not, Lasse. I also want this to work on the command line and not
> depend on CI-system-specific workarounds. But thank you for your
> insightful ideas, I really appreciate them.
>
> Tibor, actually I wanted to avoid a potentially lengthy debate on basic
> principles, but I agree on having one, if you feel it is necessary. I
> owe you that much, because it tells me that you are not taking design
> decisions lightly. So if I can contribute to your decision-making
> process, I shall humbly do so. Not being a Maven (plugin) developer
> myself, but rather a just user with a bit of background knowledge, I in
> fact did previously in this thread comment on the two famous '*AtEnd'
> precedence cases already:
>
> >>>> Install and Deploy plugins (...): 'installAtEnd' and 'deployAtEnd'
> >>>> are blessings IMO, and they are cornerstones of my work, because
> >>>> they help to avoid half-installed and - even worse - half-deployed
> >>>> multi-module projects which would lead to inconsistencies in
> >>>> repositories and might be hard to rectify in remote repositories,
> >>>> "burning" release numbers unnecessarily.
>
> The gist is: Those '*AtEnd' features have user value. If you say that
> they might be difficult to maintain and shield against side effects, I
> have to take your word for it. So we have a trade-off situation here,
> chances vs risks. As the person requesting such a feature, of course I
> have a chances bias. As a plugin maintainer, of course you take a more
> conservative or defensive stance. I understand that. In the end, it is
> your decision. Hopefully others here can contribute more substantially
> to the discussion than I can.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: aggregator project types

[Delany]

Hi Mantas,

The children are dependents, not dependencies - as in human relations. This
isn't really an issue since the three aspects of project aggregation,
configuration inheritance, and dependency management are separate. I hope
you no longer think there's a problem with build order?

I want my projects to look like this

- mineral (jar)
  - pyrite (jar)
  - gypsum (jar)
  - sandstone (jar)

When I build the mineral project, I want the other projects to build -
currently not possible
Id also like the pyrite/gypsum/sandstone projects to inherit configuration
from the mineral project. This should be as easy as setting the parent tag
- currently not possible
A nice to have would be where the child projects inherit an implicit
dependency on the parent. It seems this is actually the case with pom
parents, but it doesn't result in a compile dependency in the resulting
pom. When the parent is a type jar lets say that it should.

I can imagine this would play out as various tickets
- allow project type jar to act as an aggregator
- allow project type jar to act as a parent
- infer a dependency on the project acting as the parent and introduce a
scope tag to make this configurable

I might be talking about changes already considered/implemented in Maven 4
in which case apologies for the noise. But in Maven 3 I have to arrange my
projects like so

- aggregator (pom)
  - mineral (pom)
- pyrite (jar)
- gypsum (jar)
- sandstone (jar)
  - mineral (jar)

The aggregator is necessary to build the mineral and its dependents AND
have a dependency on the mineral project inherited by the three other
projects. Its ugly as heck.
>From a users point of view, the fact that a project is type pom vs jar is
simply a matter of the lifecycle invoked for the build. And if it's not,
don't you agree that it should be?

Regards,
Delany


On Tue, 1 Feb 2022 at 08:19, Mantas Gridinas  wrote:

> Seems reasonable to be honest. I would make a guess that aggregators with
> their own sources would need to decide what to do with their children:
> should they be treated as additional dependencies, what should be the build
> order of such module. But if you treat children as dependencies then you
> introduce circle in dependency graph because children already inherit the
> parent, so should they become pseudo fat jars where they contain the
> binaries of a parent?
>
> Im all up for what ever decision streamlines the process so that there
> would be less "thinking" (read: guessing) whats going to happen under such
> configuration and that is especially important when you're using an
> implicit tool like maven.
>
> At least this is my speculative take.
>
> On Tue, Feb 1, 2022, 07:56 Delany  wrote:
>
> > Yes but why? Why should I have to make separate projects just for the
> > purpose of aggregating other projects? This isn't the case in g*.
> > Delany
> >
> >
> > On Tue, 1 Feb 2022 at 00:47, Nils Breunese  wrote:
> >
> > > You can create a multi-module project, with one of the modules using
> its
> > > sibling modules as dependencies. The parent pom.xml would be of type
> > ‘pom’
> > > and contain the list of all modules in the project of type ‘jar’.
> > >
> > > Nils.
> > >
> > > > Op 31 jan. 2022 om 13:58 heeft Delany 
> het
> > > volgende geschreven:
> > > >
> > > > Can someone remind me why a type JAR project can't have modules?
> > > > Is it unreasonable to expect a JAR project to produce its own JAR
> > > artifact,
> > > > and then act as an aggregator of other projects?
> > > >
> > > > Thanks,
> > > > Delany
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>

Re: aggregator project types

[Delany]

Yes but why? Why should I have to make separate projects just for the
purpose of aggregating other projects? This isn't the case in g*.
Delany


On Tue, 1 Feb 2022 at 00:47, Nils Breunese  wrote:

> You can create a multi-module project, with one of the modules using its
> sibling modules as dependencies. The parent pom.xml would be of type ‘pom’
> and contain the list of all modules in the project of type ‘jar’.
>
> Nils.
>
> > Op 31 jan. 2022 om 13:58 heeft Delany  het
> volgende geschreven:
> >
> > Can someone remind me why a type JAR project can't have modules?
> > Is it unreasonable to expect a JAR project to produce its own JAR
> artifact,
> > and then act as an aggregator of other projects?
> >
> > Thanks,
> > Delany
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

aggregator project types

[Delany]

Can someone remind me why a type JAR project can't have modules?
Is it unreasonable to expect a JAR project to produce its own JAR artifact,
and then act as an aggregator of other projects?

Thanks,
Delany

Re: Maven Book recommendation

[Delany]

Hi Bruno. The online Maven documentation is excellent - took me a while to
get comfortable navigating it though.
What I'd like from Maven for myself and people learning is to maintain a
curated list of open source projects that use Maven. I've learnt a lot from
other github projects.
Delany


On Fri, 28 Jan 2022 at 00:24, Bruno Melloni  wrote:

> It became very clear to me that my current approach of googling
> tutorials, guides and solutions is a wildly inadequate approach to learn
> Maven.  Mainly because all of those are either far too basic for "real
> life" projects, or because they assume prior knowledge that I don't yet
> have.
>
> So, I am looking to buy a good book to methodically learn all I need
> about Maven.
>
> Because of how I learn best I would like to find a book that uses the
> following as its presentation approach:
>
>   * It must be gradual, starting from the assumption that I know nothing
> and only learn what is taught in the book.
>   * New concepts must include sample code that I can type and test,
> either complete code or as an extension to a previous example.
> Absolutely no "loose snippets" that assume prior knowledge (for
> example this is what makes most formal Spring documentation
> completely useless to me, as I often can't follow it to a complete
> functioning solution, and I had similar but not as severe issues
> with the formal Apache Maven documentation).
>   * The end of each chapter must have exercises that I can code and run
> to test my understanding, with the ability to download the solution
> from a website in those cases when my code fails to function correctly.
>   * Not essential but it would be ideal if the book was available in
> electronic form and readable through an ebook reader that functions
> on a Microsoft Surface tablet (Windows 10/11) and remembers the last
> page I read (even better if position syncs between the tablet and my
> desktop so that I can continue reading on either).
>
> If _you learned Maven from a book that matches at least the first 3
> criteria_, please recommend it.  I'd greatly appreciate it.
>

Re: [ANN] Versions Maven Plugin 2.9.0 Released

[Delany]

Hi. I still can't display plugin updates with the latest version of the
plugin (2.9.0)

`./mvnw -N versions:display-plugin-updates -DgenerateBackupPoms=false -X`

In the output I see

[DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository).

[DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
snapshots (http://snapshots.maven.codehaus.org/maven2).

[DEBUG] Using mirror presto-central (
http://presto:8081/repository/maven-central/) for central (
http://repo1.maven.org/maven2).

[DEBUG] Using mirror maven-default-http-blocker (http://0.0.0.0/) for
apache.snapshots (http://people.apache.org/maven-snapshot-repository).

Presto is mine, but what are these other repositories?

And further down

[DEBUG] super-pom version map


org.apache.maven.plugins:maven-clean-plugin:2.5


org.apache.maven.plugins:maven-install-plugin:2.4


org.apache.maven.plugins:maven-deploy-plugin:2.7


org.apache.maven.plugins:maven-site-plugin:3.3


org.apache.maven.plugins:maven-antrun-plugin:1.3


org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5


org.apache.maven.plugins:maven-dependency-plugin:2.8


org.apache.maven.plugins:maven-release-plugin:2.5.3


org.apache.maven.plugins:maven-source-plugin:null


org.apache.maven.plugins:maven-javadoc-plugin:null


[DEBUG] parent version map


[DEBUG] aggregate version map


org.apache.maven.plugins:maven-clean-plugin:2.5


org.apache.maven.plugins:maven-release-plugin:2.5.3


org.apache.maven.plugins:maven-install-plugin:2.4


org.apache.maven.plugins:maven-dependency-plugin:2.8


org.apache.maven.plugins:maven-site-plugin:3.3


org.apache.maven.plugins:maven-source-plugin:null


org.apache.maven.plugins:maven-javadoc-plugin:null


org.apache.maven.plugins:maven-assembly-plugin:2.2-beta-5


org.apache.maven.plugins:maven-deploy-plugin:2.7


org.apache.maven.plugins:maven-antrun-plugin:1.3


[DEBUG] final aggregate version map


org.apache.maven.plugins:maven-release-plugin:2.5.3


org.apache.maven.plugins:maven-javadoc-plugin:null

at which point it hangs using all of a CPU core and no network. What's up
here?

Thanks,
Delany


On Fri, 21 Jan 2022 at 12:05, Stefan Seifert
 wrote:

> Hi,
>
> The Mojo team is pleased to announce the release of the Versions Maven
> Plugin version 2.9.0.
>
> The Versions Plugin is used when you want to manage the versions of
> artifacts in a project's POM.
>
> https://www.mojohaus.org/versions-maven-plugin/
>
> To get this update, simply specify the version in your project's plugin
> configuration:
>
> 
>   org.codehaus.mojo
>   versions-maven-plugin
>   2.9.0
> 
>
> Release Notes
>
> https://github.com/mojohaus/versions-maven-plugin/releases/tag/versions-maven-plugin-2.9.0
>
> Enjoy,
>
> The Mojo team.
>
> stefan
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Build fails due to dependency not found (removed) even if a most recent one is available...

[Delany]

Hi Robert,

You're assuming later versions are backward compatible. That's a dangerous
assumption. If there are conflicting transitive dependencies in your
dependency tree, you should sort them out.
Would you rather have a ClassNotFoundException at runtime, or a build
error? If L requires version 1.0.0 of Z then that is the artifact it
requires. By using 2.0.0 you're essentially substituting a different
artifact in its place.

I'm not clear on the internals, but when you download a JAR, you get the
corresponding pom (often also in the JAR itself). It's not unreasonable for
Maven to require the dependency before it knows what the transitive
dependencies are. How else would it know?

So why are you removing old dependencies? It sounds like a naive attempt at
gaining some efficiency.
If you don't care to use excludes, you could alternatively setup your own
Maven repository and upload the JAR to it with a simplified pom (one with
reduced or no dependencies)

Regards,
Delany

On Wed, 12 Jan 2022 at 16:18, Roberto Simoni  wrote:

> Thanks Delany, but just for my knowledge, why maven is not able to
> determine that because you are using the newer library, you can avoid
> failure?
> Is it because maven has to download all dependencies before applying the
> resolution of the most recent version?
> Can we then say that "removing old dependencies" should be avoided in order
> to allow maven to work properly?
> Regards
>   R
>
> Il giorno mar 11 gen 2022 alle ore 19:30 Delany <
> delany.middle...@gmail.com>
> ha scritto:
>
> > Hi Robert. Further down that page you can read about exclusions.
> > So you can make X depend on L but with an exclusion:
> >
> > 
> >   Z
> >   2.0.0
> > 
> > 
> >   L
> >   
> > 
> >   Z
> > 
> >   
> > 
> >
> > Delany
> >
> >
> > On Tue, 11 Jan 2022 at 19:40, Roberto Simoni 
> > wrote:
> >
> > > Hi everyone, I have a question for you.
> > > In my company, a team decided to remove periodically versions of a
> > > library/application-framework.
> > > So what happens is that every n months we have to update all softwares
> to
> > > the newer versions.
> > >
> > > There is an aspect that I do not understand and I'd like to ask you my
> > > question making an example.
> > > Imagine that the library where versions are removed is called Z.
> > > You have a project X depending on a library L that is using Z, but
> also X
> > > is using Z.
> > > In X we update the version of Z to 2.0.0
> > > In X, the version of L is still using Z 1.0.0 which is removed.
> > >
> > > I though that you could build X anyway, because the most recent version
> > of
> > > Z (while building X) is the 2.0.0, instead it fails because it tries to
> > > resolve Z 1.0.0 while compiling X when it finds that X is using Z 1.0.0
> > >
> > > Is there any reason behind this decision?
> > > Looking at the this page
> > > <
> > >
> >
> https://maven.apache.org/pom.html#dependency-version-requirement-specification
> > > >
> > > page, I though that it was not required to update every lib if it find
> a
> > > most recent version of it.
> > >
> > > Regards
> > >   R
> > >
> >
>

Re: Ambari 2.7.6 build questions

[Delany]

Maven profiles are not active by default. Run "mvn validate -Psources" and
check again for the source-maven-plugin.
Rather don't edit files in Maven local repository. If you must add them,
use the dependency plugin like so
`mvn dependency:get
-Dartifact=org.apache.maven:sources-maven-plugin:3.2.1:jar -N`
Educated guess is that m2e-lastUpdated is generated by the Eclipse m2e
plugin. As you will see in the _remote.repositories files, these are
generated by the Maven resolver. Both can be deleted safely.
Delany

On Wed, 12 Jan 2022 at 13:02, Marc Hoppins  wrote:

> Thanks.  You are clearly helpful.
>
> If I may prod you regarding manual download/install of items in .m2
>
> When I originally initiated the project (following ambari docs) and used:
>
> mvn versions:set -DnewVersion=2.7.6.0.0
>
> and again for ambari-metrics
>
> a bunch of things got downloaded. When I ran clean/test/compile builds
> more items were downloaded and dropped into my local .m2
>
> What did NOT get downloaded were two items. One of which is
> maven-source-plugin. MVNRepository shows (for 3.2.1)
>
> 
> 
> org.apache.maven.plugins
> maven-source-plugin
> 3.2.1
> 
>
> Which matches other org.apache.maven plugins such as shade and surefire
> and these WERE downloaded.  Is there some reason these missing two were
> left out?
>
> Importantly, if I go to
> https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-source-plugin/3.2.1/
> ../
> maven-source-plugin-3.2.1-javadoc.jar 2019-12-16 18:21
>  69893
> maven-source-plugin-3.2.1-javadoc.jar.asc 2019-12-16 18:21
>  488
> maven-source-plugin-3.2.1-javadoc.jar.md5 2019-12-16 18:21
> 32
> maven-source-plugin-3.2.1-javadoc.jar.sha12019-12-16 18:21
> 40
> maven-source-plugin-3.2.1-source-release.zip  2019-12-16 18:21
> 204286
> maven-source-plugin-3.2.1-source-release.zip  2019-12-16 18:21
>  488
> maven-source-plugin-3.2.1-source-release.zip  2019-12-16 18:21
> 32
> maven-source-plugin-3.2.1-source-release.zip  2019-12-16 18:21
> 40
> maven-source-plugin-3.2.1-sources.jar 2019-12-16 18:21
>  23814
> maven-source-plugin-3.2.1-sources.jar.asc 2019-12-16 18:21
>  488
> maven-source-plugin-3.2.1-sources.jar.md5 2019-12-16 18:21
> 32
> maven-source-plugin-3.2.1-sources.jar.sha12019-12-16 18:21
> 40
> maven-source-plugin-3.2.1.jar 2019-12-16 18:21
>  32159
> maven-source-plugin-3.2.1.jar.asc 2019-12-16 18:21
>  488
> maven-source-plugin-3.2.1.jar.md5 2019-12-16 18:21
> 32
> maven-source-plugin-3.2.1.jar.sha12019-12-16 18:21
> 40
> maven-source-plugin-3.2.1.pom 2019-12-16 18:21
> 6924
> maven-source-plugin-3.2.1.pom.asc 2019-12-16 18:21
>  488
> maven-source-plugin-3.2.1.pom.md5 2019-12-16 18:21
> 32
> maven-source-plugin-3.2.1.pom.sha12019-12-16 18:21
> 40
>
> Could I just grab the jar, pom and sha1, copy these to my .m2 repo and
> they would get picked up by the build?
>
> I notice that the local repo versions of things have extra items such as :
> several m2e-lastUpdated and _remote.repositories  I understand these may
> only be relative to ECLIPSE.
>
> -Original Message-
> From: Delany 
> Sent: Wednesday, January 12, 2022 11:30 AM
> To: Maven Users List 
> Subject: Re: Ambari 2.7.6 build questions
>
> EXTERNAL
>
> Hi Marc,
> The "2.1.4" line should be left out. Clearly the
> authors are not following standard practice for managing dependencies, so
> do not assume that they know what they're doing.
> Change the version in the dependencyManagement section if you need it to
> be v2.1.4.
> Delany
>
>
> On Wed, 12 Jan 2022 at 12:13, Marc Hoppins  wrote:
>
> > HI all,
> >
> > I get a ‘overriding managed version 2.0.1 for rpm-maven.plugin’
> > message and I see two plugin definitions for this artifact, with two
> > versions, in the same ‘build’ block in the top-level
> > (ambari-2.7.6.0.0) POM. From what I see, does this mean that the plugin
> must be declared in both places:
> >
> > build>pluginManagement>plugins>plugin>rpm-maven-plugin
> > and
> > build>plugins>plugin>rpm-maven-plugin?
> >
> > In any case, why is the version different for these declarations?
> >
> >   
> > 
> >   
> > 
> >   org.apache.rat
> >   apache-rat-plugin
> >   0.12
> > 
> > 
> >   org.a

Re: Ambari 2.7.6 build questions

[Delany]

Hi Marc,
The "2.1.4" line should be left out. Clearly the authors
are not following standard practice for managing dependencies, so do not
assume that they know what they're doing.
Change the version in the dependencyManagement section if you need it to be
v2.1.4.
Delany


On Wed, 12 Jan 2022 at 12:13, Marc Hoppins  wrote:

> HI all,
>
> I get a ‘overriding managed version 2.0.1 for rpm-maven.plugin’ message
> and I see two plugin definitions for this artifact, with two versions, in
> the same ‘build’ block in the top-level (ambari-2.7.6.0.0) POM. From what I
> see, does this mean that the plugin must be declared in both places:
>
> build>pluginManagement>plugins>plugin>rpm-maven-plugin
> and
> build>plugins>plugin>rpm-maven-plugin?
>
> In any case, why is the version different for these declarations?
>
>   
> 
>   
> 
>   org.apache.rat
>   apache-rat-plugin
>   0.12
> 
> 
>   org.apache.maven.plugins
>   maven-surefire-plugin
>   2.20
> 
> 
>   org.codehaus.mojo
>   rpm-maven-plugin
>   2.0.1
> 
> 
>   org.vafer
>   jdeb
>   1.8
> 
> 
>   org.apache.maven.plugins
>   maven-clean-plugin
>   2.5
> 
> 
>   maven-assembly-plugin
>   2.2-beta-5
> 
>   
> 
> 
>   
> org.codehaus.mojo
> build-helper-maven-plugin
> 1.8
> 
>   
> parse-package-version
> 
>   regex-property
> 
> 
>   package-version
>   ${project.version}
>
> ^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)((\.|-).*)?
>   $1.$2.$3.$4
>   true
> 
>   
>   
> parse-package-release
> 
>   regex-property
> 
> 
>   package-release
>   ${project.version}
>
> ^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)((\.|-)(([0-9]+)|(SNAPSHOT)|(techwin)).*)?
>   $7
>   true
> 
>   
> 
>   
>   
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.2
> 
>   1.8
>   1.8
> 
>   
>   
> maven-assembly-plugin
> 
>   
>
> ${ambari.dir}/ambari-project/src/main/assemblies/empty.xml
>   
> 
> 
>   
> make-assembly
> package
> 
>   single
> 
>   
> 
>   
>   
> org.codehaus.mojo
> rpm-maven-plugin
> 2.1.4
> 
>   
> 
> none
> 
>   attached-rpm
> 
>   
> 
> 
>   2012, Apache Software Foundation
>   Development
>   Maven Recipe: RPM Package.
>   ${package-release}
>   ${package-version}
>   
> 
>   
>

Re: Build fails due to dependency not found (removed) even if a most recent one is available...

[Delany]

Hi Robert. Further down that page you can read about exclusions.
So you can make X depend on L but with an exclusion:


  Z
  2.0.0


  L
  

  Z

  


Delany


On Tue, 11 Jan 2022 at 19:40, Roberto Simoni  wrote:

> Hi everyone, I have a question for you.
> In my company, a team decided to remove periodically versions of a
> library/application-framework.
> So what happens is that every n months we have to update all softwares to
> the newer versions.
>
> There is an aspect that I do not understand and I'd like to ask you my
> question making an example.
> Imagine that the library where versions are removed is called Z.
> You have a project X depending on a library L that is using Z, but also X
> is using Z.
> In X we update the version of Z to 2.0.0
> In X, the version of L is still using Z 1.0.0 which is removed.
>
> I though that you could build X anyway, because the most recent version of
> Z (while building X) is the 2.0.0, instead it fails because it tries to
> resolve Z 1.0.0 while compiling X when it finds that X is using Z 1.0.0
>
> Is there any reason behind this decision?
> Looking at the this page
> <
> https://maven.apache.org/pom.html#dependency-version-requirement-specification
> >
> page, I though that it was not required to update every lib if it find a
> most recent version of it.
>
> Regards
>   R
>

Re: Ambari build

[Delany]

Hi Marc
-DskipTests is case sensitive. You can also skip compilation of tests with
-Dmaven.test.skip
Eclipse is probably using a bundled JDK - version 11+ since you're getting
javax errors.
Intellij is using a bundled Maven since its complaining about https repos.
Check Intellij's Maven configuration page.
Delany


On Fri, 7 Jan 2022 at 14:16, Marc Hoppins  wrote:

> Hi all,
>
> This is a stock ambari 2.7.6 build attempt on Ubuntu 18.04.  I am not a
> java entity but I am interested in understanding how these tools operate
> with a view to getting away from Cloudera. We currently run with CDH 6.3,
> the free/express version and this leaves us stuck with Centos7, or
> Ubuntu18, both of which are EOL, or fast approaching.  Given the exorbitant
> pricing per node for ANY version of Cloudera, it is prohibitive to justify
> the cost when making money off data is not a thing we could possibly
> contemplate.
>
> Aside from the obvious fact that every build produces errors which seem to
> have been ignored by whoever created this,  I am mystified as to why the
> errors are different depending on how I run a build.
>
> I have OpenJDK 8 installed, as well as the general pre-requisites
> according to the Ambari documentation.
>
> Maven 3.6.0
> Eclipse 2021-12 (4.22.0)
> IntelliJ IDEA 2021.3.1 (Community)
>
> Below are the output errors from OS CLI, Eclipse and IntelliJ. All three
> produce DIFFERENT errors and this is confusing as I thought they all used
> Maven.  I run an INSTALL build with rat.skip as RAT seems to produce
> thousands of licence errors for every item in the project.  If RAT is so
> important, why have these errors not been sorted?
>
> Also, if I have -Dskiptests, why do tests still get run?
>
> I am sure that there are folk who have successfully built Ambari but
> useful and successful attempts have not been published for any recent
> version.
>
> Any information would be helpful.
>
> Thanks.
>
> Marc
>
> ** When run from CLI **
>
> mvn install -Drat.skip=true -Dskiptests=true -X
> [INFO] Running
> org.apache.ambari.server.metric.system.impl.MetricsServiceTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.359 s - in org.apache.ambari.server.metric.system.impl.MetricsServiceTest
> [INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 30.001 s - in
> org.apache.ambari.server.checks.AmbariMetricsHadoopSinkVersionCheckTest
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 6.232 s - in org.apache.ambari.server.upgrade.SchemaUpgradeHelperTest
> [WARNING] Tests run: 6, Failures: 0, Errors: 0, Skipped: 1, Time elapsed:
> 5.677 s - in org.apache.ambari.server.metric.system.impl.MetricsSourceTest
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR]   ExecutionCommandWrapperTest.testGetExecutionCommand:247
> [ERROR]   AmbariErrorHandlerTest.testHandleInternalServerError:119 Nothing
> captured yet
> [ERROR] Errors:
> [ERROR]
>  
> RootServiceComponentConfigurationResourceProviderTest.shouldUpdatePasswordInCredentialStoreIfSecurityPasswordEncryptionIsEnabled:534
> > ConstructorNotFound
> [ERROR]
>  
> PasswordUtilsTest.shouldReadPasswordFromCredentialStoreOfAnAlias:67->setupBasicCredentialProviderExpectations:127
> > ConstructorNotFound
> [ERROR]
>  
> PasswordUtilsTest.shouldResolveEncryptedPaswordIfWeStoreTheAliasInPasswordFile:103->setupBasicCredentialProviderExpectations:127
> > ConstructorNotFound
> [INFO]
> [ERROR] Tests run: 5271, Failures: 2, Errors: 3, Skipped: 60
> [INFO]
> [INFO]
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Ambari Main 2.7.6.0.0 .. SUCCESS [
> 0.651 s]
> [INFO] Apache Ambari Project POM 2.7.6.0.0  SUCCESS [
> 0.009 s]
> [INFO] Ambari Web 2.7.6.0.0 ... SUCCESS [01:20
> min]
> [INFO] Ambari Views 2.7.6.0.0 . SUCCESS [
> 1.149 s]
> [INFO] Ambari Admin View 2.7.6.0.0  SUCCESS [
> 26.216 s]
> [INFO] ambari-utility 1.0.0.0-SNAPSHOT  SUCCESS [
> 2.062 s]
> [INFO] ambari-metrics 2.7.6.0.0 ... SUCCESS [
> 0.109 s]
> [INFO] Ambari Metrics Common 2.7.6.0.0  SUCCESS [
> 37.461 s]
> [INFO] Ambari Metrics Hadoop Sink 2.7.6.0.0 ... SUCCESS [
> 6.900 s]
> [INFO] Ambari Metrics Flume Sink 2.7.6.0.0  SUCCESS [
> 4.742 s]
> [INFO] Ambari Metrics Kafka Sink 2.7.6.0.0  SUCCESS [
> 3.439 s]
> [INFO] Ambari Metrics Storm Sink 2.7.6.0.0  SUCCESS [
> 1.970 s]
> [INFO

jxr fast aggregate

[Delany]

Hi. I'm implementing maven-surefire-reports-plugin, and I need the
maven-jxr-plugin to produce code for XRefs.
With jxr plugin v2.3 I can run

./mvnw jxr:test-aggregate surefire-report:report-only

and I'll get a report in 10s. But when I update to jxr plugin v3.1.1 it
takes forever invoking separate lifecycles as described in
https://maven.apache.org/jxr/maven-jxr-plugin/examples/nofork.html

The last sentence on that page "Note: These reports may not be used for
aggregate reports."

But this is exactly what I want. So is there a roadmap for implementing
this or do I stay on version 2.3?

Thanks,
Delany

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Delany]

Hi Tamas,

I've been trying the Redisson approach for the last 7 weeks, but my machine
locks up every second or third build for long periods of time 5-20min.
I'm on Ubuntu running the Redis 6.2.6 snap using the Maven 3.8.3 and 3.8.4
wrapper. I followed these instructions to setup

Edit the file *${maven.home}/bin/m2.conf* and after *${maven.conf}/logging*
add *load ${maven.home}/lib/ext/redisson/*.jar*

Create the folder *${maven.home}/lib/ext/redisson/* and populate with
https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-named-locks-redisson/1.7.2/maven-resolver-named-locks-redisson-1.7.2.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.12.1/jackson-annotations-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.12.1/jackson-core-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.12.1/jackson-databind-2.12.1.jar
https://repo1.maven.org/maven2/com/fasterxml/jackson/dataformat/jackson-dataformat-yaml/2.12.1/jackson-dataformat-yaml-2.12.1.jar
https://repo1.maven.org/maven2/org/jboss/marshalling/jboss-marshalling/2.0.11.Final/jboss-marshalling-2.0.11.Final.jar
https://repo1.maven.org/maven2/org/jboss/marshalling/jboss-marshalling-river/2.0.11.Final/jboss-marshalling-river-2.0.11.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-buffer/4.1.65.Final/netty-buffer-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-codec/4.1.65.Final/netty-codec-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-codec-dns/4.1.65.Final/netty-codec-dns-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-common/4.1.65.Final/netty-common-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-handler/4.1.65.Final/netty-handler-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-resolver/4.1.65.Final/netty-resolver-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-resolver-dns/4.1.65.Final/netty-resolver-dns-4.1.65.Final.jar
https://repo1.maven.org/maven2/io/netty/netty-transport/4.1.65.Final/netty-transport-4.1.65.Final.jar
https://repo1.maven.org/maven2/org/redisson/redisson/3.15.6/redisson-3.15.6.jar
https://repo1.maven.org/maven2/org/yaml/snakeyaml/1.27/snakeyaml-1.27.jar
Delany

On Fri, 8 Oct 2021 at 10:05, Delany  wrote:

> Thanks Tamás.
> Since I use the wrapper, I was thinking there's a case for Maven wrapper
> variants. But I guess this is what containers are all about anyway.
> Delany
>
> On Thu, 7 Oct 2021 at 11:32, Tamás Cservenák  wrote:
>
>> Hi Delany,
>>
>> from Sisu website: "Sisu is a modular JSR330-based container that
>> supports *classpath
>> scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses
>> Google-Guice to perform dependency injection and provide the core JSR330
>> support, but removes the need to write explicit bindings in Guice
>> modules.".
>>
>> Simply, SISU will scan your classpath for components and dynamically pick
>> them up and wire them up.
>>
>> For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a
>> Sisu feature).
>>
>> ServiceLocator is deprecated, leave it out (but same thing stands: is
>> "static").
>>
>> ===
>>
>> More simpler: with Sisu, just throw a component onto classpath, and Sisu
>> will "automagically" pick it up, no code change needed. This is how
>> extensions and other things work in Maven for example (just copy a JAR
>> with
>> components to classpath and they are discovered).
>>
>> Locking implementations like Redisson and Hazelcast are "opt-in", they are
>> not bundled with Maven (to not bloat distro). They work only after you
>> "install" them (provide JARs with their components and all component
>> dependencies to Maven classpath, as explained in the Install step on that
>> page).
>>
>> This remark you quoted is geared more toward "resolver integrators", for
>> those using Resolver into some other project than Maven. If you integrate
>> Resolver, then:
>> - if you use Sisu, you have nothing to do :)
>> - if you use vanilla Guice, then in your integration you have to provide
>> the things you want on classpath and explicitly bind them
>> - if you use ServiceLocator, move away from it (will be soon dropped),
>> simplest is to "roll your own" bootstrap class (that does same as
>> ServiceLocator was doing, statically wiring things up), and again, you
>> should upfront provide whatever you need on classpath and instantiate them
>> using your own "bootstrap" class.
>>
>> If you just want to use it with Maven, nothing to be done for you, just
>> Install it as per page.
>&g

Re: resume from

[Delany]

Hi Martin,

I set my wrapper to use
distributionUrl=
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/apache-maven/4.0.0-alpha-1-SNAPSHOT/apache-maven-4.0.0-alpha-1-20211125.103820-218-bin.zip

but it died with
Unable to parse maven.config: Unrecognized option: --threads 1C

I changed it to "-T 1C" and it works.

But then it died with
'repositories.repository.[thirdparty].url' contains an expression but
should be a constant

Probably because I construct the url using a property provided by the
properties-maven-extension
I'm heavily dependent on this extension.

Thanks,


On Thu, 25 Nov 2021 at 16:07, Martin Kanters 
wrote:

> Hello,
>
> Strange behavior indeed. I can remember having solved this issue for Maven
> 4 (which is not yet released).
> If you want you can try the bleeding edge Maven 4 version. That also helps
> us find and fix potential bugs before Maven 4 is released. You can install
> it easily using Brew [1] or Chocolatey [2].
>
> Using 4 you can also use --resume / -r, which does not take flags and will
> remember what module failed and thus which one to resume from.
>
> Please share your feedback if you are using it.
> Martin
>
> [1] https://github.com/mthmulders/homebrew-maven-snapshot
> [2] https://community.chocolatey.org/packages/maven-snapshot
>
> Op do 25 nov. 2021 om 13:42 schreef Delany :
>
> > Thanks Mantas, I think I figured it out. There's nothing wrong with the
> > structure of my reactor.
> >
> > If I build a reactor with 1 thread, the projects are built in order from
> A
> > to Z and there's no way a project could not get built.
> >
> > Now suppose I introduce some bugs into the code and build again with 3
> > threads (no pom files have changed). The build fails on project M, and
> the
> > message says to rerun and resume from project M. I do that, and then it
> > fails again on project X. If I resume from project X, the build might end
> > with Z successfully. But it's possible that project P was never built. I
> > suspect this is what is happening.
> >
> > It seems when --resume-from is used together with --threads, there can be
> > some confusion as to what is built. This isn't mentioned in
> > http://maven.apache.org/guides/mini/guide-multiple-modules.html or
> > http://maven.apache.org/guides/mini/guide-multiple-modules-4.html
> >
> > Delany
> >
> >
> > On Thu, 25 Nov 2021 at 11:36, Mantas Gridinas 
> wrote:
> >
> > > If you're working with maven 3 you can check the miniguide "Guide to
> > > Woeking with multiple modules". Reactor should sort out your modules in
> > > such way that dependency modules are built earlier in the reactor but
> in
> > my
> > > experience they would get skipped if you use resume flag. The guide
> > > suggests that you could try including also-make and
> also-make-dependents
> > to
> > > ensure that modules get rebuilt both ways when you rebuild a particular
> > > module.
> > >
> > > My advice is to look through your module declaration order and fix your
> > > poms to not depend on modules that appear later in the build process.
> > That
> > > way you won't depend on reactor figuring out the order for you and
> reduce
> > > possible headaches in the future.
> > >
> > > On Thu, Nov 25, 2021, 11:22 Delany  wrote:
> > >
> > > > Hi. How does --resume-from actually work? Is there any information
> > cached
> > > > between builds somewhere?
> > > > I made some sweeping changes to a 500+ modules reactor. As I fix the
> > > build
> > > > errors in each project, I use -rf to continue without restarting each
> > > time.
> > > > I finally get to the end of the build thinking I've fixed all the
> > errors,
> > > > but when I run the build again from the beginning new ones pop up.
> > > >
> > > > Thanks,
> > > >
> > >
> >
>

Re: resume from

[Delany]

Thanks Mantas, I think I figured it out. There's nothing wrong with the
structure of my reactor.

If I build a reactor with 1 thread, the projects are built in order from A
to Z and there's no way a project could not get built.

Now suppose I introduce some bugs into the code and build again with 3
threads (no pom files have changed). The build fails on project M, and the
message says to rerun and resume from project M. I do that, and then it
fails again on project X. If I resume from project X, the build might end
with Z successfully. But it's possible that project P was never built. I
suspect this is what is happening.

It seems when --resume-from is used together with --threads, there can be
some confusion as to what is built. This isn't mentioned in
http://maven.apache.org/guides/mini/guide-multiple-modules.html or
http://maven.apache.org/guides/mini/guide-multiple-modules-4.html

Delany


On Thu, 25 Nov 2021 at 11:36, Mantas Gridinas  wrote:

> If you're working with maven 3 you can check the miniguide "Guide to
> Woeking with multiple modules". Reactor should sort out your modules in
> such way that dependency modules are built earlier in the reactor but in my
> experience they would get skipped if you use resume flag. The guide
> suggests that you could try including also-make and also-make-dependents to
> ensure that modules get rebuilt both ways when you rebuild a particular
> module.
>
> My advice is to look through your module declaration order and fix your
> poms to not depend on modules that appear later in the build process. That
> way you won't depend on reactor figuring out the order for you and reduce
> possible headaches in the future.
>
> On Thu, Nov 25, 2021, 11:22 Delany  wrote:
>
> > Hi. How does --resume-from actually work? Is there any information cached
> > between builds somewhere?
> > I made some sweeping changes to a 500+ modules reactor. As I fix the
> build
> > errors in each project, I use -rf to continue without restarting each
> time.
> > I finally get to the end of the build thinking I've fixed all the errors,
> > but when I run the build again from the beginning new ones pop up.
> >
> > Thanks,
> >
>

resume from

[Delany]

Hi. How does --resume-from actually work? Is there any information cached
between builds somewhere?
I made some sweeping changes to a 500+ modules reactor. As I fix the build
errors in each project, I use -rf to continue without restarting each time.
I finally get to the end of the build thinking I've fixed all the errors,
but when I run the build again from the beginning new ones pop up.

Thanks,

WSDL @XmlRootElement annotation from jaxws-maven-plugin

[Delany]

hi. Im cleaning up some old projects and I seem to have an issue with the
jaxws-maven-plugin.
To produce working code the wsimport goal must be followed by
maven-jaxb2-plugin with forceRegenerate=true.
It seems jaxws-maven-plugin can't annotate classes with @XmlRootElement and
that's why maven-jaxb2-plugin must be run.
Googling WSDL root xml element doesn't reveal much.
Does this sound familiar?

Thanks,
Delany

https://github.com/mojohaus/jaxws-maven-plugin/issues
https://www.mojohaus.org/jaxws-maven-plugin/index.html

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Delany]

Thanks Tamás.
Since I use the wrapper, I was thinking there's a case for Maven wrapper
variants. But I guess this is what containers are all about anyway.
Delany

On Thu, 7 Oct 2021 at 11:32, Tamás Cservenák  wrote:

> Hi Delany,
>
> from Sisu website: "Sisu is a modular JSR330-based container that
> supports *classpath
> scanning*, *auto-binding*, and *dynamic auto-wiring*. Sisu uses
> Google-Guice to perform dependency injection and provide the core JSR330
> support, but removes the need to write explicit bindings in Guice
> modules.".
>
> Simply, SISU will scan your classpath for components and dynamically pick
> them up and wire them up.
>
> For Guice, you need to _explicitly add_ bindings (as this "dynamism" is a
> Sisu feature).
>
> ServiceLocator is deprecated, leave it out (but same thing stands: is
> "static").
>
> ===
>
> More simpler: with Sisu, just throw a component onto classpath, and Sisu
> will "automagically" pick it up, no code change needed. This is how
> extensions and other things work in Maven for example (just copy a JAR with
> components to classpath and they are discovered).
>
> Locking implementations like Redisson and Hazelcast are "opt-in", they are
> not bundled with Maven (to not bloat distro). They work only after you
> "install" them (provide JARs with their components and all component
> dependencies to Maven classpath, as explained in the Install step on that
> page).
>
> This remark you quoted is geared more toward "resolver integrators", for
> those using Resolver into some other project than Maven. If you integrate
> Resolver, then:
> - if you use Sisu, you have nothing to do :)
> - if you use vanilla Guice, then in your integration you have to provide
> the things you want on classpath and explicitly bind them
> - if you use ServiceLocator, move away from it (will be soon dropped),
> simplest is to "roll your own" bootstrap class (that does same as
> ServiceLocator was doing, statically wiring things up), and again, you
> should upfront provide whatever you need on classpath and instantiate them
> using your own "bootstrap" class.
>
> If you just want to use it with Maven, nothing to be done for you, just
> Install it as per page.
>
> ===
>
> HTH
> Tamas
>
> On Thu, Oct 7, 2021 at 10:07 AM Delany  wrote:
>
> > Michael, could you clarify this line pls: "It only works when Sisu DI is
> > used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu
> > dependency injection)."
> >
> >
> https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html
> >
> > What should I do about this issue?
> >
> > Thanks,
> > Delany
> >
> >
> > On Wed, 6 Oct 2021 at 22:18, Michael Osipov  wrote:
> >
> > > Am 2021-10-06 um 21:05 schrieb Francois Marot:
> > > > Michael, I do not agree. As a user and maintainer of the build chain
> in
> > > my
> > > > company, I think Maven would really benefit from an out of the box
> > > > solution. I think any user is susceptible to the bug by launching
> > > multiple
> > > > Maven instances at the same time on his computer. Bugs then
> encountered
> > > are
> > > > really a bad sign sent to users, and requiring each dev to setup a
> > > database
> > > > (even simple) is cumbersome.
> > >
> > > I agree with you, but we are developers after all, I can expect people
> > > to set up something if necessary.
> > > At the end you need to consider that file based locking has issues, it
> > > does not work everywhere, it is advisory at best, it protects you only
> > > from multiprocess access, multithreaded requires an extra layer of
> > > in-JVM locks. Given that we are all volunteers and the pain for the
> > > community isn't big enough to contribute something valuable, I won't.
> > > Especially that Tamás and me invested almost year developing the named
> > > locks approach with pluggable providers is more than enough to solve
> any
> > > type of build setup on any FS and OS.
> > >
> > > I'd like to quote Marshall Kirk McKusick: Why write something good if
> > > you can steal something better? (trade file locks with Redis).
> > >
> > > A more lightweight approach would be something like POSIX semaphores
> > > available everywhere, but Windows. Requires likely native code or JNR
> > > and time. Out of personal interest I'd peek at it next year.
> > >
> > > M
> > >
> 

Re: Local repository accessed by multiple Maven instances - how is it solved ?

[Delany]

Michael, could you clarify this line pls: "It only works when Sisu DI is
used and not the bundled AetherModule or ServiceLocator (Maven uses Sisu
dependency injection)."
https://maven.apache.org/resolver/maven-resolver-named-locks-redisson/index.html

What should I do about this issue?

Thanks,
Delany


On Wed, 6 Oct 2021 at 22:18, Michael Osipov  wrote:

> Am 2021-10-06 um 21:05 schrieb Francois Marot:
> > Michael, I do not agree. As a user and maintainer of the build chain in
> my
> > company, I think Maven would really benefit from an out of the box
> > solution. I think any user is susceptible to the bug by launching
> multiple
> > Maven instances at the same time on his computer. Bugs then encountered
> are
> > really a bad sign sent to users, and requiring each dev to setup a
> database
> > (even simple) is cumbersome.
>
> I agree with you, but we are developers after all, I can expect people
> to set up something if necessary.
> At the end you need to consider that file based locking has issues, it
> does not work everywhere, it is advisory at best, it protects you only
> from multiprocess access, multithreaded requires an extra layer of
> in-JVM locks. Given that we are all volunteers and the pain for the
> community isn't big enough to contribute something valuable, I won't.
> Especially that Tamás and me invested almost year developing the named
> locks approach with pluggable providers is more than enough to solve any
> type of build setup on any FS and OS.
>
> I'd like to quote Marshall Kirk McKusick: Why write something good if
> you can steal something better? (trade file locks with Redis).
>
> A more lightweight approach would be something like POSIX semaphores
> available everywhere, but Windows. Requires likely native code or JNR
> and time. Out of personal interest I'd peek at it next year.
>
> M
>
> > Le lun. 4 oct. 2021 à 22:13, Michael Osipov  a
> écrit :
> >
> >> Tamás,
> >>
> >> Redis is so easy to install and get going in 5 minutes that I would
> >> rather see your energy go into areas which need more attention.
> >>
> >> M
> >>
> >> Am 2021-10-04 um 22:02 schrieb Tamás Cservenák:
> >>> Hi Bernd,
> >>>
> >>> nothing is wrong with advisory file locking, as long as you don't store
> >>> local repo on NFS ;)
> >>> Will re-add file locking once I get there, as in my opinion it is the
> >> most
> >>> "lightweight" MP (multi process) solution on a single host.
> >>> Redis and Hazelcast are more for "farms", where several hosts with many
> >>> processes (and each with many threads) is bashing local repo (that MAY
> be
> >>> on NFS as well).
> >>>
> >>> Thanks
> >>> Tamas
> >>>
> >>> On Mon, Oct 4, 2021 at 9:37 PM Bernd Eckenfels  >
> >>> wrote:
> >>>
> >>>> What’s the problem with adivisory locking, as long as Maven honors the
> >>>> advice it is the same as it’s a redis lock? (But much less footprint).
> >> In
> >>>> fact on the same machine it should even work without locking as Long
> as
> >> you
> >>>> use pidfiles?
> >>>>
> >>>> Gruss
> >>>> Bernd
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >> -
> >> 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: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Delany]

It's here
https://maven.apache.org/examples/maven-3-lifecycle-extensions.html
Delany

On Thu, 30 Sep 2021, 16:56 Austin Witt,  wrote:

> > /usr/share/maven/lib/ext
>
> That would be perfect! Is that documented somewhere? I never saw mention of
> that before today!
>
> What is the earliest version of Maven that supports that extension folder?
>
> On Thu, Sep 30, 2021 at 1:19 AM Delany  wrote:
>
> > Hi Austin,
> >
> > I think those Takari projects aren't maintained anymore. The issue was
> > recently fixed in Maven 3.8.2 with
> > https://issues.apache.org/jira/browse/MNG-4706
> >
> > You can use the command line -Dmaven.ext.class.path to include the
> > extension. The strange wording is perhaps because there is an idea in the
> > Maven community that command line arguments are second-class citizens to
> > configuration written into the pom files, and conversely that you can
> throw
> > whatever arguments in and it will not interfere with existing
> > configuration. There is some truth to this, as arguments to config a
> plugin
> > are honoured, but not if the same config has been configured in a pom.
> >
> > You can also add the extensions for the system to
> /usr/share/maven/lib/ext
> >
> > Thanks,
> > Delany
> >
> >
> >
> > On Thu, 30 Sept 2021 at 07:45, Austin Witt 
> wrote:
> >
> > > I wish to install a Maven extension - Takari's Concurrent Safe Local
> > > Repository extension (
> > >
> >
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> > > )
> > > - on a system such that it's picked up by all Maven runs.
> > >
> > > Individual projects should not have to put it in their pom.xml; I do
> not
> > > want projects to be able to opt-out of this extension, and I do not
> want
> > > them to have to opt-in.
> > > Individual projects should not have to put it in their
> > > basedir/.mvn/extensions.xml; I do not want projects to be able to
> opt-out
> > > of this extension, and I do not want them to have to opt-in.
> > >
> > > However...
> > >
> > > This is a CICD system where builds run in Docker containers, and each
> get
> > > their *own* ~/.m2 directory (complete with their own self-specified
> > > settings.xml), which the builds themselves set up *if they need it* at
> > > build-time. So, there isn't a ~/.m2/lib/ext that I can drop the
> extension
> > > JAR into "ahead-of-time" before Maven runs - to put it there, I'd have
> to
> > > modify each project's pipeline to drop the JAR in before kicking off
> any
> > > Maven processes.
> > >
> > > I am looking for a way to provide the extension as default
> functionality
> > > for *all* Maven processes on a system, without requiring an individual
> > > "maven project in a git repo" to be aware of it.
> > >
> > > I am not entirely sure I understand how the final Extension
> > > mechanism, -Dmaven.ext.class.path, works. It *seems like* I could add
> > that
> > > via environment variables as a global maven option, and point at a JAR
> > > somewhere *else *on the system. However, the documentation I could find
> > on
> > > it cautions:
> > >
> > > -Dmaven.ext.class.path=[path to files] is a little bit more flexible,
> but
> > > remains not configured into the build, which is not suitable to ensure
> an
> > > extension is available at build time.
> > > -- https://maven.apache.org/studies/extension-demo/
> > >
> > >
> > > What does "not configured into the build, which is not suitable to
> ensure
> > > an extension is available at build time" *mean* ? Is it just saying
> that
> > > it's not loaded before the project is parsed and so is unsuitable for
> > > extensions that require that, as identified in the line about pom.xml
> > > extension configuration? All documentation I can find about
> > > -Dmaven.ext.class.path talks about EventSpy implementations - does it
> > > *only* work
> > > for those? Or can I load other extensions via that mechanism?
> > >
> > > If -Dmaven.ext.class.path works with all extension types *and* loads
> > > in-time for Takari's extension, I can probably use that.
> > >
> > > If not, is there a way to change the Maven extension directory with a
> > > property? E.g. mvn -Dext.dir=/opt/some/dir and have that used, instead
> of
> > > the user-local ~/.m2/lib/ext?
> > >
> > > Thank you for your time,
> > >   Austin
> > >
> >
>

Re: Global pre-installation of Maven extensions w/out ~/.m2/lib/ext

[Delany]

Hi Austin,

I think those Takari projects aren't maintained anymore. The issue was
recently fixed in Maven 3.8.2 with
https://issues.apache.org/jira/browse/MNG-4706

You can use the command line -Dmaven.ext.class.path to include the
extension. The strange wording is perhaps because there is an idea in the
Maven community that command line arguments are second-class citizens to
configuration written into the pom files, and conversely that you can throw
whatever arguments in and it will not interfere with existing
configuration. There is some truth to this, as arguments to config a plugin
are honoured, but not if the same config has been configured in a pom.

You can also add the extensions for the system to /usr/share/maven/lib/ext

Thanks,
Delany



On Thu, 30 Sept 2021 at 07:45, Austin Witt  wrote:

> I wish to install a Maven extension - Takari's Concurrent Safe Local
> Repository extension (
> http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository
> )
> - on a system such that it's picked up by all Maven runs.
>
> Individual projects should not have to put it in their pom.xml; I do not
> want projects to be able to opt-out of this extension, and I do not want
> them to have to opt-in.
> Individual projects should not have to put it in their
> basedir/.mvn/extensions.xml; I do not want projects to be able to opt-out
> of this extension, and I do not want them to have to opt-in.
>
> However...
>
> This is a CICD system where builds run in Docker containers, and each get
> their *own* ~/.m2 directory (complete with their own self-specified
> settings.xml), which the builds themselves set up *if they need it* at
> build-time. So, there isn't a ~/.m2/lib/ext that I can drop the extension
> JAR into "ahead-of-time" before Maven runs - to put it there, I'd have to
> modify each project's pipeline to drop the JAR in before kicking off any
> Maven processes.
>
> I am looking for a way to provide the extension as default functionality
> for *all* Maven processes on a system, without requiring an individual
> "maven project in a git repo" to be aware of it.
>
> I am not entirely sure I understand how the final Extension
> mechanism, -Dmaven.ext.class.path, works. It *seems like* I could add that
> via environment variables as a global maven option, and point at a JAR
> somewhere *else *on the system. However, the documentation I could find on
> it cautions:
>
> -Dmaven.ext.class.path=[path to files] is a little bit more flexible, but
> remains not configured into the build, which is not suitable to ensure an
> extension is available at build time.
> -- https://maven.apache.org/studies/extension-demo/
>
>
> What does "not configured into the build, which is not suitable to ensure
> an extension is available at build time" *mean* ? Is it just saying that
> it's not loaded before the project is parsed and so is unsuitable for
> extensions that require that, as identified in the line about pom.xml
> extension configuration? All documentation I can find about
> -Dmaven.ext.class.path talks about EventSpy implementations - does it
> *only* work
> for those? Or can I load other extensions via that mechanism?
>
> If -Dmaven.ext.class.path works with all extension types *and* loads
> in-time for Takari's extension, I can probably use that.
>
> If not, is there a way to change the Maven extension directory with a
> property? E.g. mvn -Dext.dir=/opt/some/dir and have that used, instead of
> the user-local ~/.m2/lib/ext?
>
> Thank you for your time,
>   Austin
>

Re: Best practice to update dependency versions for *many* projects to the current version

[Delany]

Mantas, why dont you use properties for versions? I found that some plugins
don't pick up artifact versions from dependencyManagement, breaking the
uniformity that depmng supposedly offers. Properties ensure a single source
of truth.
Delany

On Thu, 2 Sept 2021 at 17:35, Mantas Gridinas  wrote:

> You might be interested in running the POM per application rather than
> some global singular POM, since you should retain the ability to
> update a single application's dependencies without breaking other
> applications' behavior. I agree that this approach is the more time
> consuming than having some company wide common dependency list, but it
> all boils down to if you have an extensive test suite and if you are
> willing to redeploy all the applications when that super-pom (or BOM)
> is changed.
>
> "Maven dependency mechanism" is a good read in general. The only thing
> I disagree with is using properties for versions of artifacts.
>
> Since you're also migrating existing applications, I suppose you have
> some JAR folder that you (or it was done for you) copy over by hand.
> To prevent breakage when using external versions of said JARs you
> might want to use install plugin's install-file
> (
> https://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
> )
> goal to copy those files over into the common .m2 repository and then
> isolate your builds from network by either using private nexus or
> using offline mode.
>
> On Thu, Sep 2, 2021 at 6:07 PM Nils Breunese  wrote:
> >
> > Another option is creating an artifact of type ‘pom’ that consists of
> just a pom.xml with a  section and optionally
> properties for the versions (so they can easily be overridden when needed),
> and importing this BOM (bill of materials) artifact in your applications.
> >
> > See spring-boot-dependencies for an example:
> https://search.maven.org/artifact/org.springframework.boot/spring-boot-dependencies/2.5.4/pom
> >
> > You can use such an artifact as the parent of your applications
> (especially handy if you also want to centralize plugin configurations,
> etc.), or import its dependency management like this:
> >
> > 
> >   
> > 
> >   com.example
> >   example-dependencies
> >   1.0.0
> >   pom
> >   import
> > 
> >   
> > 
> > 
> >   
> > com.example
> > example-artifact
> >     
> >   
> > 
> >
> > See
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> for more information about BOM POMs.
> >
> > Nils.
> >
> > > Op 2 sep. 2021, om 16:52 heeft Delany 
> het volgende geschreven:
> > >
> > > Hi Bruno,
> > >
> > > You can define a property in a project all projects inherit from
> > >
> > > 
> > >  3.2.4
> > >
> > > Then add a dependencyManagement section that sections the version
> > >
> > >  
> > >
> > >  
> > >cglib
> > >cglib
> > >${dep.cglib.cglib}
> > >
> > > And use this plugin to check for updates etc
> > > https://www.mojohaus.org/versions-maven-plugin/
> > >
> > > Delany
> > >
> > > On Thu, 2 Sept 2021 at 16:40, Bruno  wrote:
> > >
> > >> I have been developing in Java almost from the beginning, but have not
> > >> used Maven for much more than a few personal test apps. I am now about
> > >> to migrate nearly 100 applications to Maven and I am a bit concerned
> > >> about how to manage dependency versions across that many projects in
> the
> > >> future.
> > >>
> > >> For a single app it is simple, go into the POM, modify the version of
> > >> the dependency, then verify that nothing broke due to newly
> unsupported
> > >> methods and fix the issues.
> > >>
> > >> But if you have a lot of applications, the above method becomes very
> > >> time consuming and manual.
> > >>
> > >> QUESTION:  Is there a best practice (or perhaps tools that help) for
> how
> > >> to handle updating the dependency versions for that many applications?
> > >>
> > >>
> > >>
> > >> -
> > >> 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
> >
>
>
> --
> // Mantas
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Best practice to update dependency versions for *many* projects to the current version

[Delany]

Hi Bruno,

You can define a property in a project all projects inherit from


  3.2.4

Then add a dependencyManagement section that sections the version

  

  
cglib
cglib
${dep.cglib.cglib}

And use this plugin to check for updates etc
https://www.mojohaus.org/versions-maven-plugin/

Delany

On Thu, 2 Sept 2021 at 16:40, Bruno  wrote:

> I have been developing in Java almost from the beginning, but have not
> used Maven for much more than a few personal test apps. I am now about
> to migrate nearly 100 applications to Maven and I am a bit concerned
> about how to manage dependency versions across that many projects in the
> future.
>
> For a single app it is simple, go into the POM, modify the version of
> the dependency, then verify that nothing broke due to newly unsupported
> methods and fix the issues.
>
> But if you have a lot of applications, the above method becomes very
> time consuming and manual.
>
> QUESTION:  Is there a best practice (or perhaps tools that help) for how
> to handle updating the dependency versions for that many applications?
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Maven enforcer plugin regarding child module's groupId

[Delany]

Instead of policing deviations with a rule, why not make this possible at
the outset?

${project.parent.groupId}.${project.parent.artifactId}

Delany


On Tue, 31 Aug 2021 at 16:29, David Hoffer  wrote:

> I'd love to see that added to the included rules in the enforcer plugin.
>
> -Dave
>
> On Tue, Aug 31, 2021 at 6:53 AM Matt Benson  wrote:
>
> > On Tue, Aug 31, 2021, 3:28 AM Delany  wrote:
> >
> > > Good question. There seems no way to do this dynamically in Maven 3.x
> > > Delany
> > >
> > > On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:
> > >
> > > > How to enforce that child modules append to the parent groupId per
> the
> > > > Maven
> > > > Guide to Naming Conventions
> > > > <http://maven.apache.org/guides/mini/guide-naming-conventions.html>
> ?
> > > >
> > >
> >
> > It would seem that writing a custom enforcer rule to do this would be
> > trivial.
> >
> > Matt
> >
> >
> > > -Dave
> > > >
> > >
> >
>

Re: Maven enforcer plugin regarding child module's groupId

[Delany]

Good question. There seems no way to do this dynamically in Maven 3.x
Delany

On Mon, 30 Aug 2021 at 20:45, David Hoffer  wrote:

> How to enforce that child modules append to the parent groupId per the
> Maven
> Guide to Naming Conventions
> <http://maven.apache.org/guides/mini/guide-naming-conventions.html>  ?
>
> -Dave
>

maven-jdeps-plugin multirelease impossible

[Delany]

Hi. I'm trying to find split packages using this plugin/goal:
https://maven.apache.org/plugins/maven-jdeps-plugin/test-jdkinternals-mojo.html

If add the plugin config as per
https://maven.apache.org/plugins/maven-jdeps-plugin/usage.html

it fails saying
> Error: junit-platform-commons-1.8.0-M1.jar is a multi-release jar file
but --multi-release option is not set

Then if I add 9 and rerun, I get
> Error: maven-artifact-3.6.3.jar is not a multi-release jar file but
--multi-release option is set

It looks like as long as there is a multi-release dependency on my project,
using the jdeps plugin is impossible?

Thanks,
Delany

NB way to end a friday I know, but at least it is written

Re: maven-surefire-plugin jdkToolchain meets forkCount

[Delany]

Yes it looks that way. I changed the system jdk to 16 and now I can pick a
jdk with the toolchains plugin and without any surefire config.
Its basically https://issues.apache.org/jira/browse/MTOOLCHAINS-28 all over
again but with surefire-plugin
Want a ticket?
Delany


On Thu, 26 Aug 2021 at 17:50, Thomas Broyer  wrote:

> IIUC, with forkCount=0, you're disabling forking, so everything happens in
> the Maven process itself and won't use the configured toolchain. If you're
> running Maven with a JDK < 9 then you'd have that
> UnsupportedClassVersionError.
>
> For the first case, with forkCount being its default value (forkCount=1) I
> suppose, can you share the stacktrace?
> It might be (I haven't checked) that the plugin looks at (loads) the
> compiled classes to determine how to actually fork/run the tests (e.g.
> determine if a given class is a test class, by looking at the @Test
> annotations with JUnit 4 for instance). If that's the case then it means
> you have to run Maven with a JDK version greater than the one you'd want to
> use as a toolchain. In other words you can run Maven with JDK 11 to run
> your tests with JDK 8, but not run Maven with JDK 8 to run tests with JDK
> 11.
>
> On Thu, Aug 26, 2021 at 3:32 PM Delany  wrote:
>
> > Hi. Im having trouble with the jdkToolchain feature of
> > maven-surefire-plugin
> >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html
> > This is my working build tag
> >
> > 
> > 
> >   
> > 
> >   maven-compiler-plugin
> >   
> > 8
> > 8
> >   
> > 
> > 
> >   maven-surefire-plugin
> >   
> > 
> >   9
> > 
> >   
> > 
> >   
> > 
> > 
> >   
> > maven-toolchains-plugin
> > 
> >   
> > 
> >   
> > 
> >   9
> > 
> >   
> > 
> >   
> > 
> >   
> > 
> >   
> >
> > I can build with the above config no problem, but if I configure the
> > compile plugin with 9, surefire throws
> >
> > > Execution default-test of goal
> > org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> > java.lang.UnsupportedClassVersionError:
> > com/etc/common/crypto/clientreference/TestClientToken has been compiled
> by
> > a more recent version of the Java Runtime (class file version 53.0), this
> > version of the Java Runtime only recognizes class file versions up to
> 52.0
> >
> > In either case I can see the toolchain being configured in the build log
> >
> > [INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile)
> @
> > cryptocommon ---
> > [INFO] Toolchain in maven-compiler-plugin: JDK[/usr/lib/jvm/zulu-9-amd64]
> > [INFO] Changes detected - recompiling the module!
> > [INFO] Compiling 7 source files to
> > /git/tep22x/common_cryptocommon/target/test-classes
> > [INFO]
> > [INFO] --- maven-surefire-plugin:3.0.0-M5:test (default-test) @
> > cryptocommon ---
> > [INFO] Toolchain in maven-surefire-plugin: JDK[/usr/lib/jvm/zulu-9-amd64]
> >
> > Now, if on top of my changes thus far I go and configure surefire-plugin
> > with 1, it's back to a successful build.
> >
> > But, if I follow the advice of
> >
> >
> https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html
> > and rather set 0, I get this
> >
> > [ERROR] Exception in provider
> > [ERROR] org.apache.maven.surefire.booter.SurefireExecutionException:
> > Exception in provider
> > [ERROR] at
> >
> >
> org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:91)
> > [ERROR] at
> >
> >
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1295)
> > [ERROR] at
> >
> >
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
> > [ERROR] at
> >
> >
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.j

maven-surefire-plugin jdkToolchain meets forkCount

[Delany]

ROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
[ERROR] at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
[ERROR] at
org.apache.maven.surefire.booter.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:100)
[ERROR] at
org.apache.maven.surefire.api.util.DefaultScanResult.loadClass(DefaultScanResult.java:136)
[ERROR] at
org.apache.maven.surefire.api.util.DefaultScanResult.applyFilter(DefaultScanResult.java:100)
[ERROR] at
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.scanClasspath(JUnitPlatformProvider.java:147)
[ERROR] at
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:128)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
[ERROR] at
org.apache.maven.surefire.api.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:167)
[ERROR] at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:161)
[ERROR] at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:84)
[ERROR] at
org.apache.maven.plugin.surefire.InPluginVMSurefireStarter.runSuitesInProcess(InPluginVMSurefireStarter.java:87)
[ERROR] ... 16 more

I don't like guessing what is going on here, but i'm not in a position to
go that extra mile and "Run Maven with -Dmaven.surefire.debug, and attach
to the running process with a debugger."

In a nutshell my question is "how can I build with a JDK 9 or above using a
toolchain and without being limited to a single test fork?"

Thanks,
Delany