Hi!
Happy to help with any automated migrations and/or recipe development.
Feel free to log an issue describing the changes needed over on:
https://github.com/openrewrite/rewrite-apache
I'll have some more time in June and over the summer to help out.
>From there on we can track progress and effect change through:
https://app.moderne.io/devcenter/Apache%20Maven
Best,
Tim
On Mon, May 20, 2024 at 9:19 PM Sylwester Lachiewicz
wrote:
> Hi,
> yes, it would be a good idea to review our project and at last update
> README that we plan to deprecate some components - to avoid unnecessary
> work on this.
>
> A quick search for "org.apache.maven.shared.dependency.graph" for
> org:apache shows that we should implement changes also in our plugins and
> create docs on how to migrate. Maybe an OpenRewrite recipe?
>
> Sylwester
>
>
> pon., 20 maj 2024 o 19:41 Hervé Boutemy
> napisał(a):
>
> > hi Tamasz,
> >
> > I think you're right on maven-dependency-tree, as it was with
> > maven-artifact-
> > transfer
> >
> > I'm not really convinced *many* shared stuff should be dropped: IMHO,
> over-
> > generalization
> >
> > And I think that when replacing a shared stuff with direct use of an
> > existing
> > API, in fact what normal people are looking for is documentation on how
> to
> > migrate: the shared components have one great advantage = they show a
> > quite
> > simple API that is easy to use, but it's not so easy to find the
> > replacement
> > hidden inside many big APIs
> >
> > I'm supportive to deprecating maven-dependency-tree and also finally drop
> > officially maven-artifact-transfer which has not been done yet.
> > What I'd like is that some clear documentation is written on how to
> > migrate
> > away from these deprecated components
> >
> > If you see any other shared component that deserve such plan, don't
> > hesitate
> > to share: I don't see so many cases
> >
> > Regards,
> >
> > Hervé
> >
> > Le lundi 20 mai 2024, 14:25:11 CEST Tamás Cservenák a écrit :
> > > Howdy,
> > >
> > > I see ongoing development against many "shared" libraries, that in
> fact,
> > > should be dropped instead. One notable example is
> > "maven-dependency-tree".
> > >
> > > This codebase was born (well, factored out) from Maven2 reporting, to
> be
> > > extended with "Maven 3.0 support", then "Maven 3.1 support" and is just
> > > collecting debt.
> > >
> > > This library, if you look at it now, is anemic and is merely a
> "wrapper"
> > > around Resolver classes, uses ancient stuff (read Maven2 classes) and
> > > patterns, like misuse of ProjectBuildingRequest (same pattern as in ill
> > > fated MAT), uses deprecated ArtifactRepository class for all kind of
> > stuff
> > > (hello split repository -- not possible to be used with these). In
> short,
> > > this project does not offer any (new, not available) functionality,
> while
> > > in turn, hinders and pushes for deprecated stuff. These should cease to
> > > exist.
> > >
> > > In fact, many shared projects should be scrutinized and most probably
> > > declared "deprecated", as most of them were born to support Maven2 to
> > > Maven3 transition (or maybe Maven 3.0 to 3.1+ transition like MAT was),
> > > while today they just hinder Maven3 to Maven4 change, as many of these
> > > shared stuff in fact still pull Maven2 classes in play.
> > >
> > >
> > > Thanks
> > > T
> >
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
