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

[Jim N]

mvn versions:use-latest-versions

this plugin does what it says, but also supports overriding specific ranges
in specific scopes




On Fri, Sep 3, 2021 at 4:05 PM Mantas Gridinas  wrote:

> It's a matter of preference, really. But I'd like to avoid anything
> that I can override via command-line unless it is documented as a
> plugin property. We have profiles for that.
>
> On Thu, Sep 2, 2021 at 10:52 PM Delany  wrote:
> >
> > 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, 

Re: Why does Maven Shade relocate modify unrelated classes?

[Jim N]

im not sure whether the prior response fully bounced, so forgive the
duplication:

This is the maven users list not the shade issues tracker.  expect
helpful suggestions that don't share your viewpoints or goals.

I'd suggest you find the shade plugin source code and resist the urge
to mix words like "horrible" with responses that lack grattitude.

Once again, Good luck

FYI To unsubscribe, e-mail: users-unsubscr...@maven.apache.org

On Sun, May 16, 2021 at 6:55 PM Alexander Kriegisch
 wrote:
>
> I have no idea what you are talking about and how your answer concerning
> "non-relocating options" is relevant to my question about the opposite.
> I also did not report any surprises during my deployments or runtime
> behaviour of relocated classes. Thanks for your feedback anyway. Next
> time, maybe try to contribute a constructive answer instead of a
> destructive comment, or refrain from replying at all. I would be much
> obliged. The way you replied sounds just enigmatic at best, lecturing
> trying to make me feel stupid otherwise. Not helpful!
>
>
> > You might want to examine the "horrible" Non relocating options
> > previously outlined if you want a fast resolution to unsurprising
> > deployments.
> >
> >
> > On Sun, May 16, 2021, 10:41 AM Alexander Kriegisch wrote:
> >
> >> When running Maven Shade with relocation, it works nicely. When
> >> comparing JARs before and after relocation, I was surprised to see
> >> that Shade not just modifies the relocated classes and classes
> >> referencing them, but also a bunch of IMO completely unrelated
> >> classes. In my case I am transforming an uber JAR containing ASM, and
> >> I selectively relocate the ASM classes, intending to leave all others
> >> untouched. I know that ASM classes are referred to by some of the
> >> other classes, but by no means as many as are being modified. The
> >> byte code is slightly different, probably still does the same thing,
> >> but it makes comparisons and sanity checks or automatic verification
> >> steps harder than necessary. BTW, the same Shade execution also
> >> relocates the sources and really only changes source files
> >> referencing ASM, just like I would have expected.
>
> -
> 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: Why does Maven Shade relocate modify unrelated classes?

[Jim N]

You might want to examine the "horrible" Non relocating options previously
outlined if you want a fast resolution to unsurprising deployments.

On Sun, May 16, 2021, 10:41 AM Alexander Kriegisch 
wrote:

> When running Maven Shade with relocation, it works nicely. When
> comparing JARs before and after relocation, I was surprised to see that
> Shade not just modifies the relocated classes and classes referencing
> them, but also a bunch of IMO completely unrelated classes. In my case I
> am transforming an uber JAR containing ASM, and I selectively relocate
> the ASM classes, intending to leave all others untouched. I know that
> ASM classes are referred to by some of the other classes, but by no
> means as many as are being modified. The byte code is slightly
> different, probably still does the same thing, but it makes comparisons
> and sanity checks or automatic verification steps harder than necessary.
> BTW, the same Shade execution also relocates the sources and really only
> changes source files referencing ASM, just like I would have expected.
>
> Looking forward to your insights
> --
> 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: Attaching dependency-reduced POM to build using Maven Assembly or Shade

[Jim N]

> With all due respect, this is horrible. It is not just a scripted build


I respectfully shared a pragmatic and to paraphrase myself "easily made
into a windows- specific powershell or cmd file" approach after having
written off shade and assembly plugins.  whatever your personal views on
purity and standards may be, they're behind me.  good luck tho

Re: Attaching dependency-reduced POM to build using Maven Assembly or Shade

[Jim N]

there's nothing that really painlessly replaced the first
maven fatjar since it became outmoded.

that said, i use dependency plugin to dump a lib/ dir even for reactor
builds, and then a shell script that uses that classpath syntax to load a
directory at a time.

this happens with maven exec anyways, just less fragile.

sometimes shade chokes on a manifest glitch and in practice fixing that is
less efficient than a robust lib/ dir

in the parent-most pom if the levels go deeper, verbatim from the
dependency plugin docs, is
```!xml


maven-dependency-plugin


install

copy-dependencies



${project.build.directory}/lib




```
in bin/ of the top level i have the tiniest specific bash runner, easily
ported to windows as well.

```!bash
#!/usr/bin/env bash

set -fx
JDIR=$(dirname $0)/../apprunner
exec java  -classpath "$JDIR/target/*:$JDIR/target/lib/*"
 ${EXECMAIN:=apprunner.MyMain} "$@"
```

often it's a helpful thing to keep these shell scripts handy to record
variaous -XX and -D parameters in the comments or at run time.

Re: Maven Dependencies Pop Quiz

[Jim N]

hmm, there's a moderately hard pop quiz for maven on linkedin tests.  it
starts out asking a few questions about how to build archetypes more or
less blindfolded.

On Fri, Mar 27, 2020 at 2:59 PM Arnaud Héritier  wrote:

> On the last page, when you end the test, there is a button to display the
> result.
> I missed it too the first time.
>
> On Thu, Mar 26, 2020 at 7:08 PM Andres Almiray  wrote:
>
> > That's strange, you should get the number of correct answers at the end
> of
> > the quiz although I don't know if it actually shows you which answers
> were
> > incorrect when that's the case.
> >
> > All data and results will be made public once the quiz is closed.
> >
> > Thank you for participating.
> >
> > Cheers,
> > Andres
> >
> > ---
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Thu, Mar 26, 2020 at 7:04 PM jieryn  wrote:
> >
> > > Kind of frustrating to not be shown my score at the end...
> > >
> > > On Thu, Mar 26, 2020 at 1:01 PM Andres Almiray 
> > wrote:
> > > >
> > > > Hello everyone!
> > > >
> > > > If I can ask you for 15 minutes of your time, I've put of a 14
> question
> > > pop
> > > > quiz on dependency resolution. I'm hopeful that this quiz will let us
> > > > realize a few things about the dependency resolution mechanism and
> its
> > > > rules, perhaps address concerns in the future and make Maven better
> as
> > a
> > > > result.
> > > >
> > > > The quiz can be found at https://bit.ly/maven-dependencies-popquiz
> and
> > > is
> > > > totally anonymous (no email address collected). Unless you feel like
> > > > sharing your name ;-)
> > > >
> > > > Some preliminary numbers to this date:
> > > >
> > > >  - 3 people have 13 correct answers
> > > >  - 3 people have 12correct answers
> > > >  - 10 people have 11 correct answers
> > > >
> > > > The current median is 8. Some quick feedback left:
> > > >
> > > >  - pretty tricky, even for an almost 20 year maven dude. good job!
> > > >  - I've never seen documentation on this
> > > >  - Good food for thought. I guess I generally hope Maven does what I
> > > expect
> > > > and when it doesn't, I start specifying more exactly what I want.
> > > >
> > > > Please feel free to share it with your colleagues and friends. More
> > > entries
> > > > mean more data and better results. Thank you!
> > > >
> > > > Cheers,
> > > > Andres
> > > >
> > > > ---
> > > > Java Champion; Groovy Enthusiast
> > > > http://andresalmiray.com
> > > > http://www.linkedin.com/in/aalmiray
> > > > --
> > > > What goes up, must come down. Ask any system administrator.
> > > > There are 10 types of people in the world: Those who understand
> binary,
> > > and
> > > > those who don't.
> > > > To understand recursion, we must first understand recursion.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> > >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Alternate Maven dependency upgrade opportunities report

[Jim N]

https://www.mojohaus.org/versions-maven-plugin

 ?

On Fri, Jul 27, 2018 at 4:46 PM Paul Hammant  wrote:

> If Maven-central has some upgrades for one of your project's dependencies,
> this little Python script can quickly* tell you.
>
> https://github.com/paul-hammant/analyze-mvn-deps
>
> Key feature:
>
> In some cases, the script may suggest two or more alternate upgrade
> suggestions. For example (as of July 27th), a Maven project depending on
> the jar for Groovy v2.5.0 would see *three alternate suggested upgrades*:
> 3.0.0-alpha-3, 2.6.0-alpha-4, or 2.5.1.
>
> * "quickly" may be minutes if the multi-module project is big enough.
>
> --
> Paul Hammant DevOps  Let me give your
> enterprise a step by step plan to migrate from GitFlow (or worse) to
> high-throughput CD on the essential DevOps foundation: Trunk-Based
> Development.
>

Re: Quicker local maven builds article

[Jim N]

how to maven plugin:

TLDR

https://github.com/0xCopy/prautobeans/tree/master/prautobeans-maven-plugin is
how a lazy man makes a hard problem as simple as possible.


pom boilerplate from this line until EOF:
https://github.com/0xCopy/prautobeans/blob/master/prautobeans-maven-plugin/pom.xml#L24


plugin annotation:
https://github.com/0xCopy/prautobeans/blob/master/prautobeans-maven-plugin/src/main/java/prauto/PrautoGen.java#L40


parameter annotation:
https://github.com/0xCopy/prautobeans/blob/master/prautobeans-maven-plugin/src/main/java/prauto/PrautoGen.java#L47


intellij will pop this one in for you:
https://github.com/0xCopy/prautobeans/blob/1ab26409cf9784f2ec579b631ced39d811689317/prautobeans-maven-plugin/src/main/java/prauto/PrautoGen.java#L163

*maybe* relevant to a build queue, the files visitor:
https://github.com/0xCopy/prautobeans/blob/master/prautobeans-maven-plugin/src/main/java/prauto/PrautoGen.java#L176





On Wed, Oct 23, 2019 at 1:46 AM Jim N  wrote:

> I'm in Indonesia, and reddit is censored here :-) even though it's as
> prevalent as youtube in technical value second only to SO.
>
> |Python3 proves to be a good prototyping tool. Maven's way is plugins, and
> |my creation/publish elapsed time would be 10x greater that way as I'd
> have
> |to learn it first. I think I'm faster with Java solutions than Python
> ones
> |generally, but not when I'm close to Bash. I could have done this in
> Bash,
> |but it'd have been six hours to make to this level of polish instead of
> the
> |three that it was.
>
> amen.  i really, really hate build tool dualism.   maven's success in
> eradicating jelly, and all conditionals and branching options was the
> impetus that made ORM's viable and transferable project nkowledge probably
> for the first time.
>
> jdk nio Files.* is better than what was on hand when maven plugins were
> defined.  I don't know  how you solved build resolution but .. the maven
> plugin boilerplate is as few as two annotations and reading some visitor
> javadocs.  for god sakes why can't gradle just emulate a maven build-daemon
> instead of deprecating the object model at every chance?
>
> Reactor architecture is ancient, and last i checked, the maven plugin list
> is a ghost town barely active enough to review and retire some of the first
> codehaus (your old stomping ground) ported plugins
>
> python is great, while you're on the machine you wrote it on.  once you
> import a package, it's a less reliable tool than a  maven plugin, at a
> cheap cost to prototype.
>
> polyglot-maven <https://github.com/takari/polyglot-maven> might be what's
> next,  enabling type-optional languages which incidentally brings inline
> imperative syntaxes for free.  is it time to look the other way on
> imperative languages in maven project object models?
>
>
> On Wed, Oct 23, 2019 at 12:26 AM Paul Hammant  wrote:
>
>> Thanks for the links and words of encouragement, gents. I'll update the
>> blog entry accordingly.
>>
>> I'm not a Maven committer (though i am an ASF member). I harang the
>> committers on rotating topics over the years, and at some point they'll
>> implement something similar to this if they want to. I love open source
>> where the 'upstream' team has a policy of patch consumption if they can't
>> state strong reasons for not doing so. And that's not Apache's policy.
>>
>> Python3 proves to be a good prototyping tool. Maven's way is plugins, and
>> my creation/publish elapsed time would be 10x greater that way as I'd have
>> to learn it first. I think I'm faster with Java solutions than Python ones
>> generally, but not when I'm close to Bash. I could have done this in Bash,
>> but it'd have been six hours to make to this level of polish instead of
>> the
>> three that it was.
>>
>> Perfect world for me would be:
>>
>> mvn -f buildThis.txt
>>
>> Where buildThis.txt was:
>>
>>   compile:
>>  foo, bar
>>   test:
>>  foo, bar, baz
>>
>> That'd allow one invocation of Java, rather than two as I have it.
>>
>> On the Maven sub-reddit, we've 40 new subscribers now as of this post :) I
>> love Reddit because of threading, in the same way I loved NNTP 20 years
>> ago.
>>
>

Re: Quicker local maven builds article

[Jim N]

I'm in Indonesia, and reddit is censored here :-) even though it's as
prevalent as youtube in technical value second only to SO.

|Python3 proves to be a good prototyping tool. Maven's way is plugins, and
|my creation/publish elapsed time would be 10x greater that way as I'd have
|to learn it first. I think I'm faster with Java solutions than Python ones
|generally, but not when I'm close to Bash. I could have done this in Bash,
|but it'd have been six hours to make to this level of polish instead of the
|three that it was.

amen.  i really, really hate build tool dualism.   maven's success in
eradicating jelly, and all conditionals and branching options was the
impetus that made ORM's viable and transferable project nkowledge probably
for the first time.

jdk nio Files.* is better than what was on hand when maven plugins were
defined.  I don't know  how you solved build resolution but .. the maven
plugin boilerplate is as few as two annotations and reading some visitor
javadocs.  for god sakes why can't gradle just emulate a maven build-daemon
instead of deprecating the object model at every chance?

Reactor architecture is ancient, and last i checked, the maven plugin list
is a ghost town barely active enough to review and retire some of the first
codehaus (your old stomping ground) ported plugins

python is great, while you're on the machine you wrote it on.  once you
import a package, it's a less reliable tool than a  maven plugin, at a
cheap cost to prototype.

polyglot-maven  might be what's
next,  enabling type-optional languages which incidentally brings inline
imperative syntaxes for free.  is it time to look the other way on
imperative languages in maven project object models?


On Wed, Oct 23, 2019 at 12:26 AM Paul Hammant  wrote:

> Thanks for the links and words of encouragement, gents. I'll update the
> blog entry accordingly.
>
> I'm not a Maven committer (though i am an ASF member). I harang the
> committers on rotating topics over the years, and at some point they'll
> implement something similar to this if they want to. I love open source
> where the 'upstream' team has a policy of patch consumption if they can't
> state strong reasons for not doing so. And that's not Apache's policy.
>
> Python3 proves to be a good prototyping tool. Maven's way is plugins, and
> my creation/publish elapsed time would be 10x greater that way as I'd have
> to learn it first. I think I'm faster with Java solutions than Python ones
> generally, but not when I'm close to Bash. I could have done this in Bash,
> but it'd have been six hours to make to this level of polish instead of the
> three that it was.
>
> Perfect world for me would be:
>
> mvn -f buildThis.txt
>
> Where buildThis.txt was:
>
>   compile:
>  foo, bar
>   test:
>  foo, bar, baz
>
> That'd allow one invocation of Java, rather than two as I have it.
>
> On the Maven sub-reddit, we've 40 new subscribers now as of this post :) I
> love Reddit because of threading, in the same way I loved NNTP 20 years
> ago.
>

Re: Dealing with a generated project

[Jim N]

Archetype with swagger Params in -D

On Sun, Aug 27, 2017, 11:32 AM Sander Verhagen 
wrote:

> Apparently no one had ideas about this. That hurts :)
>
> Just circling back with what ended up being my approach. So we generate a
> Maven project using Swagger Codegen Maven Plugin. I now generate it
> somewhere below the "target/" folder of the POM project that has this
> configuration. Then use the Maven Invoker Plugin in the compile phase to do
> an install on the generated project, and in the deploy phase to do a deploy
> on the generated project (the latter with skipTest=true, to not repeat too
> much). The later Invoker run also has the following configured, so that the
> generated project ends up in our company POM (without itself carrying this
> information, as the generated project is ultimately aimed at public
> consumption):
>
> ${
> project.distributionManagement.snapshotRepository.id
> }::default::${project.distributionManagement.snapshotRepository.url}
>
> I probably left out some small but fancy details. I code reviewed this
> with some colleagues, who praised me for my wicked Maven skills. Now...
> that's not necessarily a good thing, because this is one of those cases
> where little is left from Maven's "convention over configuration"
> philosophy, and others may have a hard time figuring out how this all
> works. (Including future versions of myself. That wouldn't be a first
> either.)
>
> That's all.
>
>
>
> Sander Verhagen
> [  san...@sanderverhagen.net  ]
>
> -Original Message-
> From: Sander Verhagen [mailto:san...@sanderverhagen.net]
> Sent: Saturday, July 22, 2017 01:10
> To: Maven Users List 
> Subject: Dealing with a generated project
>
> Hi list,
>
>
> The REST API of our application is using Swagger for documentation. During
> build we spin up our application, extract the Swagger JSON document, and
> feed it into the Swagger Codegen Maven Plugin to generate an API client.
> This plugin spits out a complete Maven project (and Gradle for that
> matter), including Java files that represent this API client, even Java
> files with unit tests. Great!
>
> So, now I have a generated project, that's not part of my current Maven
> build. (Could it be?) I've used generated code plenty, but I struggle to
> fully comprehend what the best pattern is for this generated project. I
> would like this project to be published to our Artifactory (its artifact)
> and to Git (its source code). All preferably from the same build. For the
> publish to Git I'm afraid to get into the vendor branch pattern, which I've
> never done well at. I'm anyway not even sure if I'd want to publish to Git
> on every build, and every commit of my application, or maybe publish to Git
> based on a source JAR (is that even a thing?), so yeah, I could use some
> pointers, if anyone has any some good ideas or examples to look at.
>
> Thanks, Sander.
>
>
>
> Sander Verhagen
> [  san...@sanderverhagen.net  ]
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>