Le mar. 6 août 2024 à 11:08, Martin Desruisseaux
<martin.desruisse...@geomatys.com> a écrit :
>
> Le 2024-08-05 à 14 h 19, Tamás Cservenák a écrit :
>
> > You are on the right track and Guillame and I had a lot of discussions
> > about this. IMO, best would be to wait for him (is on PTO I think) and
> > have a chat face to face?
> >
> Yes I'm fine with a talk. I'm available most time of the day (except
> today). Maybe it should be before merging pull request #1625 because
> that PR may change depending on the outcome.
>
> I have another wish that we may discuss: in order to reduce debugging
> time, I suggest to reduce the amount of convenience methods in the API.
> Especially the ones that are shortcuts doing nothing more than invoking
> a method of the same name with the same parameters plus some more
> parameters set to null. Those shortcuts only save the typing of a few
> "null" keywords, but come with a cost: when reading the code, it is not
> obvious that there are hidden null parameter values and that maybe we
> should paid attention to those parameters. This is what happened when I
> tried to understand why the dependency type ("test-jar", "modular-jar",
> etc.) was lost somewhere. When reading the code, it seems that all
> parameters are supplied. It took me step-by-step debugging to realize
> that they were an implicit null parameter value hidden behind a
> convenience method.No real problem from my side. > Another topic I would like to discuss is reducing the visibility of > implementation classes (i.e. turning public classes to package-private > ones). I started an experiment at [1], just to verify that Maven can > still run. The goal is to have more freedom for refactoring the > implementation later, with less fear of breaking some plugins outside > Maven core. I'm thinking in particular in reducing the amount of > wrappings or copyings, for reducing the risk of codes that forget to > copy an information. I'm not a big fan of reducing the visibility of implementation classes. The API is well defined, i.e. all org.apache.maven.api.* packages. If people go outside, their code may be broken. But from a usability POV, if they do need to access it (maybe as a workaround for a missing feature in the API or non foreseen use case), having to deal with private methods or classes is just a nightmare. As an API user, I prefer my code to be broken from time to time, rather than having to copy a bunch of classes and having to deal with merging changes. Anyway, I don't really see where the problem can be, as for plugins, the default setup should only expose the org.apache.maven.api packages, so they won't even have access to implementation classes. We just need to merge https://github.com/apache/maven/pull/1336 > Martin > > [1]https://github.com/Geomatys/maven/commit/8964892f8fd07a9fb2d4ffce833718d45f9aaf58 -- ------------------------ Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
