Hi Tamás, great to hear from you again. Thanks so much for your help. That PR is very helpful! A few questions:
* The TODOs say that having a dependency on the `maven-install-plugin` and `maven-deploy-plugin` is wrong, but I can't figure out why? I currently have those dependencies declared because I'm extending them to install/deploy Enunciate artifacts. Is there a better way to do that than extending those plugins? Is it just generally bad practice to extend other plugins? * (Possibly related to above item above) One of the deprecations is complaining about an auto-injection of the `org.apache.maven.artifact.repository.ArtifactRepository` pojo into one of my plugins and (I think) telling me I should use `org.eclipse.aether.RepositorySystemSession` instead. (The original code was lifted from the `maven-deploy-plugin` at the time.) Is there any documentation on how to use the Maven API to install/deploy artifacts using the "correct" components? * Are there any guides on how to migrate off maven-compat? Thanks again- -Ryan On Mon, Mar 20, 2023 at 2:28 PM Tamás Cservenák <ta...@cservenak.net> wrote: > Here you go, that applied from above to enunciate: > https://github.com/stoicflame/enunciate/pull/1166 > > Notes: > - maven-filtering has some issues, so "locked down" (added comment) and > added exclusions (3.2.0 and 3.3.0 will NOT work) > - added TODOs that should be addressed > - you have deprecations (see warnings on console when building with 3.9.1) > and you use maven-compat deprecated module... these will need to be > updated. This WILL work with 3.9.1, but is recommended to move from them. > > HTH > T > > On Mon, Mar 20, 2023 at 8:01 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > Hey Ryan, > > > > (you might remember me, was committer on Enunciate project, while it was > > on Codehaus) > > > > Let me start from the far end: When you say "Maven 3.x", you most > probably > > mean (or you want to mean) Maven 3.2.5 and "onwards" (3.9.1 inclusive). > > Simply put, you should not strive to cover "all" from 3.0.x to 3.9.x, for > > simple (technical) reasons: Maven 3.0.x used org.sonatype package for > > resolver, Maven 3.1.x did not support Eclipse Sisu index usage, so the > > "most sane" Maven range to cover today is Maven 3.2.5-3.9.1. Actually, > this > > is what we do at ASF Maven project as well, almost all "core" plugins are > > declared as compatible with this Maven range (with some rare exceptions). > > By targeting this range, you get rid of ugly problems like package > renames, > > and various issues and shortcomings (like forced use of Plexus XML, etc). > > We also target Java 8 bytecode these days, we stopped supporting Java 7 > and > > older platforms. > > > > We, as contributors of the Maven project, simply have no resources to > > cover 10+ years (3.0 is 2010, 3.1 is 2013) of legacy, so this is the > "best > > effort" we came up with. Or in other words, if someone MUST HAVE Maven > > support for some pre-3.2.5 version, they will have to either live with an > > older version of tooling (plugins) as well, that works with older Maven, > > or use a phonebook to order some pizza :) > > > > What we typically do, is: > > a- declare "minimum runtime maven prerequisite" -- today this is for ASF > > Maven core plugins 3.2.5 (in maven-plugin POM this is > > project/prerequisite/maven element) > > b- declare "minimum maven dependencies" -- this is usually same as > > "minimum runtime maven prerequisite" (these are the maven dependencies > you > > build against) > > c- declare "minimum built time maven prerequisite" -- this is required > > maven version to build the plugin (or project), this is good to keep up > to > > date, ie. I would use 3.6.3 or even 3.8.8 or so, and can be enforced > using > > enforcer (along with Java build time version and Java byte code > versions). > > d- strive to use up to date maven-plugin-plugin (and related > dependencies, > > like maven-plugin-annotations) > > > > An example of this above (note: this is not ASF Maven Core plugin, but is > > a simple showcase as the plugin itself is simple. ASF Maven plugins have > > quite a deep POM parent-child hierarchy): > > a- > > > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L55-L57 > > and > > > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L106 > > b- > > > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L132-L155 > > c- > > > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L132-L155 > > and > > > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L233-L241 > > d- > > > https://github.com/eclipse/sisu.mojos/blob/084f21a04229cbf372d06243ce397b59b38167ae/pom.xml#L109 > > > > Moreover, all "maven dependencies" (those in groupID "org.apache.maven", > > part of Maven) should be in "provided" scope (as they are provided by > Maven > > itself at plugin runtime. But a more recent maven-plugin-plugin (reason > why > > is recommended) will direct you, and warn if some scope is off. > > > > Finally, if you use plexus-utils, declare it explicitly, as starting with > > Maven 3.9.x plexus-utils is NOT auto-injected (provided) in the plugin > > classpath anymore. > > > > Something similar I attempted to jot down here: > > > https://cwiki.apache.org/confluence/display/MAVEN/Notes+For+Maven+3.9.x+Plugin+Developers > > > > Another page, maybe not directly for you (targets Maven devs, but has > > useful information for plugin devs as well): > > > https://cwiki.apache.org/confluence/display/MAVEN/Maven+Ecosystem+Cleanup > > > > All this above is for Maven plugins "in general", nothing in relation > with > > "reporting", just a FYI. > > > > Now, this above is "ideal case", if things get more hairy (ie. plugin > > reaches to some internals of Maven, maybe not even meant to be as Public > > API, this may usually cause some breakage), solution MAY be to lift lower > > end of "compatibility" from 3.2.5 to something like 3.6.3 or so, if > > possible.... > > > > HTH > > Tamas > > > > > > > > > > > > On Mon, Mar 20, 2023 at 7:04 PM Ryan Heaton <r...@webcohesion.com> > wrote: > > > >> Hi. > >> > >> Apologies in advance if the dev list would have been a better place for > >> this question. I maintain some Maven plugins for the Enunciate project > >> <http://enunciate.webcohesion.com/> and wanted to update to the latest > >> versions of the Maven API. I have one specific question, and then a more > >> general question. > >> > >> My specific question is about the maven-reporting-api. Doing an artifact > >> search revealed version 3.1.x, so I assumed that was still compatible > with > >> the latest Maven versions. But when I updated my plugin to use that API > >> version it broke when using Maven 3.x.x: > >> > >> [WARNING] An issue has occurred with enunciate-maven-plugin:2.15.0:docs > >> > report, skipping LinkageError Receiver class > >> > com.webcohesion.enunciate.mojo.DocsMojo does not define or inherit an > >> > implementation of the resolved method 'abstract void > >> > generate(org.codehaus.doxia.sink.Sink, java.util.Locale)' of interface > >> > org.apache.maven.reporting.MavenReport., please report an issue to > Maven > >> > dev team. > >> > > >> > >> So do I just need to fix on maven-reporting-api version 3.0 and ignore > the > >> deprecation warnings for e.g. org.codehaus.doxia.sink.Sink? If > >> maven-reporting-api 3.1.x is incompatible with Maven 3.x why wasn't it > >> given a major version release? > >> > >> So now the more general question: how do I know which versions of > >> artifacts > >> are the latest versions that are compatible with Maven 3.x? > >> > >> I've got all these specific dependencies: > >> > >> - maven-plugin-api > >> - maven-artifact > >> - maven-compat > >> - maven-filtering > >> - maven-plugin-annotations > >> - plexus-utils > >> - plexus-interpolation > >> - maven-reporting-api > >> > >> How do I know the most up-to-date version recipe? > >> > >> Thanks! > >> > >> -Ryan > >> > > >
