Do we have some links/pointers on "removing plugins from parent pom"? Just want to ensure it does not fall in user land but something internal.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le dim. 15 nov. 2020 à 17:03, Hervé BOUTEMY <[email protected]> a écrit : > Le vendredi 13 novembre 2020, 19:28:20 CET Michael Osipov a écrit : > > Am 2020-11-13 um 19:24 schrieb Robert Scholte: > > > Removing release profile should be combined with fail on > missing/unknown > > > profile of MNG-6012 > > Agreed, Karl just needs to complete his implementation. > > > > > Remove plugin section in super POM should be fine, now that Hervé has > > > added warnings for it. > > Correct. > 2 remarks: > 1. to better evaluate the impact, we are talking about default version for > antrun, assembly, dependency and release: the choice of removing that > default > version or not can be done per-plugin > 2. adding a warning if someone uses the version provided by super-pom was > done > to permit keeping a default version in super-pom but warning that using it > is > not the safest: then avoid bluntly removing the version > > > > > > There should be a default repository: central. I guess you want to > move it > > > to conf/settings.xml in the distribution. > > Exactly! > > > > > Robert > > > > > > On 13-11-2020 18:23:20, Michael Osipov <[email protected]> wrote: > > >>From the top of my head: > > > * Remove release profile > > > * Remove plugin section in super POM > > > * Move Central out of Core > > > > > > As well as a review of all consistency fixes to dependency resolution > > > done by Christian Schulte. > > > > > > I also agree with maven-compat. This needs to go, currently not > possible > > > due to MNG-6561. > > > > > > Am 2020-11-13 um 18:11 schrieb Robert Scholte: > > >> I'm not going to say simply yes, it probably depends. Any specific > things > > >> you have in mind? Also, I don't know what to do with maven-compat. > > >> I would prefer to remove it and introduce maven-compat3 as a bucket > for > > >> classes that we don't want to use in Maven 4, but can still be used by > > >> plugins. Reusing the maven-compat artifactId with a different set of > > >> classes is most likely a recipe for disaster. > > >> > > >> Robert > > >> On 13-11-2020 17:53:47, Michael Osipov wrote: > > >> Does this mean that we can finally drop deprecated stuff and even > break > > >> compat? > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
