You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Konrad Windszus <kw...@apache.org> on 2022/11/16 09:20:11 UTC
Maven 3 API, backwards compatibility
Hi,
Unfortunately Maven 3 didn’t define a proper API. In effect everything somehow exposed through class loaders was considered API by plugin/extension developers.
For Maven 4 a completely separate API was established in package “org.apache.maven.api”, but what about the old packages used and exported in Maven 3?
For example in the context of https://issues.apache.org/jira/browse/MNG-7588 <https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the package “org.apache.maven.plugin.descriptor”.
We already figured out that this particular package (although not part of the Maven 4 API) is used from both Maven Core as well as Maven Plugin Tools, therefore this probably needs to stay backwards compatible.
What about others like https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java? <https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?>
This interface should IMHO never been implemented outside Maven Core but in fact it was exposed to all plugins/extensions (via https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40 <https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40>).
There are three options coming to my mind:
1. Deprecate the interfaces we don’t consider API and create new ones for Maven 4 which are not exported!
2. Modify the existing interfaces in a backwards compatible way (but somehow add a marker that they should not be implemented outside core)
3. Modify the existing interfaces in a backwards compatible way (but somehow add a marker that they should not be implemented outside core)
For all three options we somehow need to come up with a list of classes/interfaces currently being exported through the API class loader, which should be considered private and agree on an Annotation/Javadoc for that (something like https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29 <https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
WDYT?
Konrad
Re: Maven 3 API, backwards compatibility
Posted by Konrad Windszus <kw...@apache.org>.
On 2022/11/16 10:04:36 Tamás Cservenák wrote:
...
> In general, I guess, we should. For this reason JapiCmp has been used in
> Resolver since 1.9.0 (as noted on refd page end).
I added https://issues.apache.org/jira/browse/MNG-7598 to track that. Currently we did a poor job when this was intended. I added a PR for enforcing binary compatibility with Maven 3.8.6 and saw plenty of incompatibilities, details in https://github.com/apache/maven/pull/874.
Konrad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Guillaume Nodet <gn...@apache.org>.
I don't think would OSGi actually bring much in our case. The goal is to
have maven-core only export a given set of packages to the plugins, with no
libraries at all. Each plugin has its own classloader only importing the
v4 api from maven-core.
Le mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> If you really like to separate API and get out of the ClassRealm-Hell
> OSGi would be much more suitable:
>
> https://issues.apache.org/jira/browse/MNG-7518
>
> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11
> and
> > adopt JPMS to better define its public APIs.
> >
> > Gary
> >
> > On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote:
> >
> >> Yes, to define rules is quite easy, but to make our users to obey them
> is
> >> tricky :D
> >>
> >> In general, I guess, we should. For this reason JapiCmp has been used in
> >> Resolver since 1.9.0 (as noted on refd page end).
> >>
> >> But while this was "kinda simple" to achieve in Resolver, I am really
> >> unsure if it is doable in Maven (sans 4 API) :(
> >>
> >> Ultimately, this was the whole reason for API:
> >> - users "grabbed" whatever could get hold on and used
> >> - maven progress was really hindered by this, as that meant modifying
> (even
> >> internal) interfaces without breaking clients was impossible, so we went
> >> with tricks, and more tricks and even more tricks that now pays back.
> >>
> >> The other day we had a question on ML about 4-alpha compatibility
> breakage,
> >> and from mail it was clear that the package of the referred class was
> >> having "internal" in it. I mean, developers should really take care of
> what
> >> they import.
> >>
> >> This is another huge plus for Takari lifecycle, it FORBIDS compilation
> >> against "encapsulated" internal classes....
> >>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>
> >> T
> >>
> >> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
> wrote:
> >>
> >>> I guess this is the easy part, the tricky question remains: Do we need
> to
> >>> make sure that all Maven 3 API interfaces/classes stay 100% backwards
> >>> compatible until we reach 4.100/5.0/whatever?
> >>>
> >>> This wasn't handled consistently in master till now, e.g. the classes
> >>> generated from
> >>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>> are now immutable, i.e. lack setter methods in Maven 4.
> >>> My change in
> >>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>> was not backwards compatible (removed a method on an interface which
> may
> >>> have been implemented by extensions...)
> >>>
> >>> Konrad
> >>>
> >>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>> Unsure we want to deprecate all of Maven :)
> >>>>
> >>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
> >> sadly,
> >>>> and is probably our major source of problems and reason we started
> >> Maven
> >>> 4
> >>>> API.
> >>>>
> >>>> IMO, I'd consider them as "whole", and just say "starting with Maven
> >>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >>> ACCESSIBLE
> >>>> ANYMORE FROM PLUGINS.
> >>>> And done.
> >>>>
> >>>> Just as an example, here is what Maven Resolver has to say about same
> >>> topic
> >>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>
> >>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>
> >>>> HTH
> >>>> T
> >>>>
> >>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
> >>> wrote:
> >>>>
> >>>>> I see now there is already
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>> but to me the javadoc is not explicit enough. It should state: Only
> >>> Maven
> >>>>> is allowed to implement/extend types with this annotation.
> >>>>>
> >>>>> Konrad
> >>>>>
> >>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>> Hi,
> >>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>> everything
> >>>>> somehow exposed through class loaders was considered API by
> >>>>> plugin/extension developers.
> >>>>>> For Maven 4 a completely separate API was established in package
> >>>>> “org.apache.maven.api”, but what about the old packages used and
> >>> exported
> >>>>> in Maven 3?
> >>>>>>
> >>>>>> For example in the context of
> >>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> >>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>> We already figured out that this particular package (although not
> >>> part
> >>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
> >>> Plugin
> >>>>> Tools, therefore this probably needs to stay backwards compatible.
> >>>>>> What about others like
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>> ?
> >>>>> <
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>> ?>
> >>>>>> This interface should IMHO never been implemented outside Maven
> >> Core
> >>> but
> >>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>> <
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>> ).
> >>>>>>
> >>>>>> There are three options coming to my mind:
> >>>>>>
> >>>>>> 1. Deprecate the interfaces we don’t consider API and create new
> >> ones
> >>>>> for Maven 4 which are not exported!
> >>>>>> 2. Modify the existing interfaces in a backwards compatible way
> >> (but
> >>>>> somehow add a marker that they should not be implemented outside
> >> core)
> >>>>>> 3. Modify the existing interfaces in a backwards compatible way
> >> (but
> >>>>> somehow add a marker that they should not be implemented outside
> >> core)
> >>>>>>
> >>>>>> For all three options we somehow need to come up with a list of
> >>>>> classes/interfaces currently being exported through the API class
> >>> loader,
> >>>>> which should be considered private and agree on an Annotation/Javadoc
> >>> for
> >>>>> that (something like
> >>>>>
> >>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>> <
> >>>>>
> >>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>
> >>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> >>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>> Konrad
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Errata: NOT imports, but rather "named capabilities". So now, I'd not let
plugins fiddle with imports, but would rather "group" and name elements of
extensions.xml
On Fri, Nov 18, 2022 at 7:53 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Now imports. But somewhat "named capabilities". Most of the plugins (vast
> majority) would use the default of "*" (give me whatever you have).
>
> If I look at this file:
>
> https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml
>
> I see "capabilities" like:
> - m4 api
> - m3 api x
> - wagon x?
> - resolver x
> - classworlds x?
> - plexus-xml x? <- Guillaume?
> - plexus-container x
> - jsr330
> - jsr250
> - slf4j
> - jansi
>
> Note: in some future maven 4.5/5/whatever entries marked with "x" are
> gone. Those with "?" capabilities are unsure if I am right or not (that
> will be gone), Guillaume will chime in hopefully.
>
> The vast majority of plugins will not bother with these settings at all
> (will have default value of "*").
> Some may want to tune it, like not having jsr330 or slf4j, or purist
> plugins may ask only for "m4api".
>
> Point is (whether enum or not) is:
> if a plugin asks for capability that maven runtime does not have (for
> example m3api in maven 5) -> leads to breakage.
>
> ===
>
> BUT, I said this would be a "dream" :) Do not stick to it. Am completely
> fine with a flag as I described before.
>
> T
>
>
> On Fri, Nov 18, 2022 at 7:36 PM Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Guess if you start to enable imports of components outside the API all the
>> API work done for m4 disappear and you get back in current state, ie a
>> mojo
>> is not able to know what it can rely on from maven until we create an enum
>> and it would be we put jsr330 (note this one does not mean much since the
>> injected type will be the most important), slf4j are part of the API and
>> we
>> said we don't want that - for goods so sounds like we should stick to the
>> API respect IMHO and if needed promote some new API, no?
>>
>> 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 ven. 18 nov. 2022 à 19:11, Tamás Cservenák <ta...@cservenak.net> a
>> écrit :
>>
>> > Howdy,
>> >
>> > just to describe a bit what I meant under "reversed flag":
>> >
>> > default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
>> > Plugin classrealm gets (from memory, might be incomplete or wrong):
>> > - m4 API
>> > - m3 "plugin-api"
>> > - javax.inject
>> > - resolver api
>> > - etc as today
>> >
>> > consider that MANY plugins have components, and creating components in
>> > MAJORITY of plugins is easy and should remain easy (and offered "out of
>> the
>> > box").
>> >
>> > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
>> realm
>> > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
>> > plugin can do whatever it wants, but still has access to m4 API (that is
>> > heaven vs earth when compared to m3 state of affairs).
>> >
>> > ===
>> >
>> > in future, when we drop m3 support, this could mean:
>> >
>> > false (default)
>> > - m4 API
>> > - javax.inject
>> >
>> > true
>> > -m4 API
>> >
>> > ===
>> >
>> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
>> > values:
>> > - * <- plugin classrealm should have all "capabilities" current Maven
>> > runtime provides
>> > - m4api <- I want maven 4 api ONLY
>> > - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
>> drops
>> > m3 backward compat), slf4j logging and would use jsr330 components
>> > "capability"
>> >
>> > But this is getting too wild maybe :)
>> >
>> >
>> > T
>> >
>> > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
>> > wrote:
>> >
>> > > Howdy,
>> > >
>> > > Am -1 on this. We just reached the point to (somewhat) undo the "Maven
>> > > downloads the whole world", at least latest plugins by putting Maven
>> and
>> > > friends in provided scope will not download dozens of versions of
>> > > maven-core and friends... If we do this, at one point we would end up
>> > with
>> > > plugins downloading dozens of DI container (or their versions), as
>> even
>> > ASF
>> > > plugins would not be in "lockstep".
>> > >
>> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
>> > > that would say maven "I will be in charge of my components" (defaults
>> to
>> > > false, Maven behaves as today). When true, it would mean Mojo wants to
>> > > bootstrap some DI/whatever container of its own, and then, for plugins
>> > like
>> > > these, Maven could even "narrow" the list of exported classes? (like
>> > > javax.inject?)
>> > >
>> > > T
>> > >
>> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
>> > wrote:
>> > >
>> > >> Following up on my previous response, and in a more realistic way
>> than
>> > >> switching to OSGi, I wonder if we should let maven 4 plugins do their
>> > own
>> > >> DI injection and only care about the mojos, i.e. not rely on
>> sisu/plexus
>> > >> to
>> > >> create and inject the mojo. Mojos using the v4 api do not need to be
>> > >> injected with other components from maven, they should all come from
>> the
>> > >> api and should be retrieved using Session.getService(xx), or simply
>> > using
>> > >> session's shortcut methods. The injection of Project and Session is
>> not
>> > >> controlled by sisu. For the ComponentConfigurator, we could change
>> the
>> > >> mojo
>> > >> descriptor to have the full configuration class name for mojos that
>> > >> require
>> > >> custom configuration injection, the plugin manager being in charge of
>> > >> instantiating this class and using it as a ComponentConfigurator
>> (which
>> > is
>> > >> not part yet of the api btw).
>> > >>
>> > >> Complex plugins which rely on plexus/sisu to do some custom injection
>> > >> would
>> > >> have to be changed to do their own DI, maybe using a simple Guice
>> setup.
>> > >>
>> > >> If that sounds like too big a change for those plugins, we may be
>> able
>> > to
>> > >> add a flag on the mojo descriptor so that those v4-enabled mojos
>> would
>> > >> trigger a DI injection on behalf of the plugin. But if we have to
>> > >> implement something like that, I would go for a plain CDI-like api,
>> > either
>> > >> using guice or another DI library supporting the javax.inject
>> package,
>> > or
>> > >> rather the jakarta.inject package, as it would be nice to switch to
>> the
>> > >> jakarta version at the same time. Or maybe even plexus if we really
>> > need
>> > >> to, but with a limited scope, i.e. no visibility on the maven
>> > components,
>> > >> so that plugins are better decoupled from maven-core.
>> > >>
>> > >> Thoughts ?
>> > >>
>> > >> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
>> > >> écrit :
>> > >>
>> > >> > I do agree that debugging the provisioning side is *very*
>> complicated
>> > >> when
>> > >> > there's a problem.
>> > >> > I'd be happy to get rid of sisu/plexus and use a more simple DI
>> > >> framework,
>> > >> > at least for simple plugins.
>> > >> > However, I definitely don't think pushing OSGi to plugins would be
>> a
>> > >> good
>> > >> > idea : the cost and burden on plugin developers would outweigh the
>> > >> benefits.
>> > >> >
>> > >> > For extensions, and for maven itself, that is a different story
>> > though.
>> > >> > Maven and extensions could definitely benefit from OSGi, but this
>> > would
>> > >> be
>> > >> > a complete breakage and it would be hard to keep some level of
>> > >> > compatibility.
>> > >> >
>> > >> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
>> mail@laeubi-soft.de
>> > >
>> > >> a
>> > >> > écrit :
>> > >> >
>> > >> >> > Guess classrealm is fine for maven, it does not bring much
>> issues
>> > >> >>
>> > >> >> As long as it works, maybe, maybe even if you write a simple maven
>> > >> >> plugin, but for any more complex it is just a complete mess.
>> > >> >>
>> > >> >> Last time I asked on the mailing list how to debug that stuff ...
>> > >> >> complete silence ...
>> > >> >>
>> > >> >> Today I tried to refactor the name of one module of a more complex
>> > >> >> maven-plugin (with core extension), now I end up with
>> > >> >>
>> > >> >> org.apache.maven.InternalErrorException: Internal error:
>> > >> >> com.google.inject.ProvisionException: Unable to provision, see the
>> > >> >> following errors:
>> > >> >> 1) No implementation for org.eclipse.aether.RepositorySystem was
>> > bound.
>> > >> >>
>> > >> >> A whole bunch of stack trace but not a little info why the *****
>> it
>> > is
>> > >> >> not happy. Now I need to add random "exportedArtifact" /
>> > >> >> "exportedPackage" stuff to hope finding out where it has lost a
>> > >> >> transitive dependency, also here absolutely no documentation what
>> > this
>> > >> >> is supposed to do/work exactly beside some introduction that these
>> > xml
>> > >> >> tags exits and reading the code... or probably add maven-compat
>> > >> >> anywhere... or change provided to compile scope (even maven is
>> > jelling
>> > >> >> at me that's bad and I will be punished soon)... not counting the
>> > many
>> > >> >> times where I messed up the realms because I accidentally trying
>> to
>> > use
>> > >> >> XppDom objects in extensions and plugins and something between got
>> > >> >> messed up.
>> > >> >>
>> > >> >> With OSGi i get clear errors for missing requirements, I can
>> clearly
>> > >> >> share API (or declare I don't want to share it) and can reliable
>> use
>> > it
>> > >> >> without classlaoding problems.
>> > >> >> If one wan't can even implement service filtering that would hide
>> all
>> > >> >> "illegal implemented API" ... and you can even make sure API is
>> > >> >> (backward) compatible with implementation without waiting for a
>> > method
>> > >> >> not found exception or alike.
>> > >> >>
>> > >> >> Beside that I find it often more clear to distinguish between API
>> > (that
>> > >> >> is only implemented by the framework) and SPI (that might be
>> > >> implemented
>> > >> >> by extenders). So probably it would be good to have maven-api and
>> > >> >> maven-spi (instead of "maven-core") to make this clear.
>> > >> >>
>> > >> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Guess classrealm is fine for maven, it does not bring much
>> issues
>> > >> (less
>> > >> >> > than OSGi or JPMS to be concrete), the real issue is the
>> stability
>> > of
>> > >> >> the
>> > >> >> > exposed API.
>> > >> >> > Thanks the hard work Guillaume did on that for maven 4 I guess
>> it
>> > is
>> > >> >> mainly
>> > >> >> > a matter of deciding what we do for maven 3.
>> > >> >> > Due to the resources and work needed I assume we can just play
>> the
>> > >> >> > status-quo for maven 3.
>> > >> >> > Remaining question is for maven 4 do we drop the compatibilty. I
>> > >> don't
>> > >> >> like
>> > >> >> > much the idea but a compat layer can solve that smoothly for
>> maven
>> > >> >= 4
>> > >> >> and
>> > >> >> > limit the work needed, no?
>> > >> >> >
>> > >> >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>> > >> mail@laeubi-soft.de>
>> > >> >> a
>> > >> >> > écrit :
>> > >> >> >
>> > >> >> >> If you really like to separate API and get out of the
>> > >> ClassRealm-Hell
>> > >> >> >> OSGi would be much more suitable:
>> > >> >> >>
>> > >> >> >> https://issues.apache.org/jira/browse/MNG-7518
>> > >> >> >>
>> > >> >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>> > >> >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to
>> Java 9
>> > >> or
>> > >> >> 11
>> > >> >> >> and
>> > >> >> >>> adopt JPMS to better define its public APIs.
>> > >> >> >>>
>> > >> >> >>> Gary
>> > >> >> >>>
>> > >> >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
>> tamas@cservenak.net
>> > >
>> > >> >> wrote:
>> > >> >> >>>
>> > >> >> >>>> Yes, to define rules is quite easy, but to make our users to
>> > obey
>> > >> >> them
>> > >> >> >> is
>> > >> >> >>>> tricky :D
>> > >> >> >>>>
>> > >> >> >>>> In general, I guess, we should. For this reason JapiCmp has
>> been
>> > >> >> used in
>> > >> >> >>>> Resolver since 1.9.0 (as noted on refd page end).
>> > >> >> >>>>
>> > >> >> >>>> But while this was "kinda simple" to achieve in Resolver, I
>> am
>> > >> really
>> > >> >> >>>> unsure if it is doable in Maven (sans 4 API) :(
>> > >> >> >>>>
>> > >> >> >>>> Ultimately, this was the whole reason for API:
>> > >> >> >>>> - users "grabbed" whatever could get hold on and used
>> > >> >> >>>> - maven progress was really hindered by this, as that meant
>> > >> modifying
>> > >> >> >> (even
>> > >> >> >>>> internal) interfaces without breaking clients was
>> impossible, so
>> > >> we
>> > >> >> went
>> > >> >> >>>> with tricks, and more tricks and even more tricks that now
>> pays
>> > >> back.
>> > >> >> >>>>
>> > >> >> >>>> The other day we had a question on ML about 4-alpha
>> > compatibility
>> > >> >> >> breakage,
>> > >> >> >>>> and from mail it was clear that the package of the referred
>> > class
>> > >> was
>> > >> >> >>>> having "internal" in it. I mean, developers should really
>> take
>> > >> care
>> > >> >> of
>> > >> >> >> what
>> > >> >> >>>> they import.
>> > >> >> >>>>
>> > >> >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
>> > >> >> compilation
>> > >> >> >>>> against "encapsulated" internal classes....
>> > >> >> >>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>> > >> >> >>>>
>> > >> >> >>>> T
>> > >> >> >>>>
>> > >> >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
>> > kwin@apache.org
>> > >> >
>> > >> >> >> wrote:
>> > >> >> >>>>
>> > >> >> >>>>> I guess this is the easy part, the tricky question remains:
>> Do
>> > we
>> > >> >> need
>> > >> >> >> to
>> > >> >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>> > >> >> backwards
>> > >> >> >>>>> compatible until we reach 4.100/5.0/whatever?
>> > >> >> >>>>>
>> > >> >> >>>>> This wasn't handled consistently in master till now, e.g.
>> the
>> > >> >> classes
>> > >> >> >>>>> generated from
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>> > >> >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
>> > >> >> >>>>> My change in
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>> > >> >> >>>>> was not backwards compatible (removed a method on an
>> interface
>> > >> which
>> > >> >> >> may
>> > >> >> >>>>> have been implemented by extensions...)
>> > >> >> >>>>>
>> > >> >> >>>>> Konrad
>> > >> >> >>>>>
>> > >> >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>> > >> >> >>>>>> Unsure we want to deprecate all of Maven :)
>> > >> >> >>>>>>
>> > >> >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users
>> can
>> > >> grab"
>> > >> >> >>>> sadly,
>> > >> >> >>>>>> and is probably our major source of problems and reason we
>> > >> started
>> > >> >> >>>> Maven
>> > >> >> >>>>> 4
>> > >> >> >>>>>> API.
>> > >> >> >>>>>>
>> > >> >> >>>>>> IMO, I'd consider them as "whole", and just say "starting
>> with
>> > >> >> Maven
>> > >> >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
>> > NOT
>> > >> >> >>>>> ACCESSIBLE
>> > >> >> >>>>>> ANYMORE FROM PLUGINS.
>> > >> >> >>>>>> And done.
>> > >> >> >>>>>>
>> > >> >> >>>>>> Just as an example, here is what Maven Resolver has to say
>> > about
>> > >> >> same
>> > >> >> >>>>> topic
>> > >> >> >>>>>> (part of not-yet-released, vote is in process 1.9.1
>> version):
>> > >> >> >>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>> > >> >> >>>>>>
>> > >> >> >>>>>> HTH
>> > >> >> >>>>>> T
>> > >> >> >>>>>>
>> > >> >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>> > >> kwin@apache.org>
>> > >> >> >>>>> wrote:
>> > >> >> >>>>>>
>> > >> >> >>>>>>> I see now there is already
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>> > >> >> >>>>>>> but to me the javadoc is not explicit enough. It should
>> > state:
>> > >> >> Only
>> > >> >> >>>>> Maven
>> > >> >> >>>>>>> is allowed to implement/extend types with this annotation.
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> Konrad
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>> > >> >> >>>>>>>> Hi,
>> > >> >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In
>> effect
>> > >> >> >>>>> everything
>> > >> >> >>>>>>> somehow exposed through class loaders was considered API
>> by
>> > >> >> >>>>>>> plugin/extension developers.
>> > >> >> >>>>>>>> For Maven 4 a completely separate API was established in
>> > >> package
>> > >> >> >>>>>>> “org.apache.maven.api”, but what about the old packages
>> used
>> > >> and
>> > >> >> >>>>> exported
>> > >> >> >>>>>>> in Maven 3?
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> For example in the context of
>> > >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>> > >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>> > >> evolve
>> > >> >> the
>> > >> >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
>> > >> >> >>>>>>>> We already figured out that this particular package
>> > (although
>> > >> not
>> > >> >> >>>>> part
>> > >> >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well
>> as
>> > >> Maven
>> > >> >> >>>>> Plugin
>> > >> >> >>>>>>> Tools, therefore this probably needs to stay backwards
>> > >> compatible.
>> > >> >> >>>>>>>> What about others like
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> > >> >> >>>>> ?
>> > >> >> >>>>>>> <
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> > >> >> >>>>>>> ?>
>> > >> >> >>>>>>>> This interface should IMHO never been implemented outside
>> > >> Maven
>> > >> >> >>>> Core
>> > >> >> >>>>> but
>> > >> >> >>>>>>> in fact it was exposed to all plugins/extensions (via
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> > >> >> >>>>>>> <
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> > >> >> >>>>>>>> ).
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> There are three options coming to my mind:
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and
>> create
>> > >> new
>> > >> >> >>>> ones
>> > >> >> >>>>>>> for Maven 4 which are not exported!
>> > >> >> >>>>>>>> 2. Modify the existing interfaces in a backwards
>> compatible
>> > >> way
>> > >> >> >>>> (but
>> > >> >> >>>>>>> somehow add a marker that they should not be implemented
>> > >> outside
>> > >> >> >>>> core)
>> > >> >> >>>>>>>> 3. Modify the existing interfaces in a backwards
>> compatible
>> > >> way
>> > >> >> >>>> (but
>> > >> >> >>>>>>> somehow add a marker that they should not be implemented
>> > >> outside
>> > >> >> >>>> core)
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> For all three options we somehow need to come up with a
>> list
>> > >> of
>> > >> >> >>>>>>> classes/interfaces currently being exported through the
>> API
>> > >> class
>> > >> >> >>>>> loader,
>> > >> >> >>>>>>> which should be considered private and agree on an
>> > >> >> Annotation/Javadoc
>> > >> >> >>>>> for
>> > >> >> >>>>>>> that (something like
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> > >> >> >>>>>>> <
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>
>> > >> >>
>> > >>
>> >
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> > >> >> >>>>>>
>> > >> >> >>>>>>> or
>> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>> > >> <
>> > >> >> >>>>>>>
>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> WDYT?
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>> Konrad
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>>
>> > >> >> >>>>>>>
>> > >> >> >>>>>>>
>> > >> >>
>> ---------------------------------------------------------------------
>> > >> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> >>>>>>> For additional commands, e-mail:
>> dev-help@maven.apache.org
>> > >> >> >>>>>>>
>> > >> >> >>>>>>>
>> > >> >> >>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>>
>> > >> >>
>> ---------------------------------------------------------------------
>> > >> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >> >>>>>
>> > >> >> >>>>>
>> > >> >> >>>>
>> > >> >> >>>
>> > >> >> >>
>> > >> >> >>
>> > >> ---------------------------------------------------------------------
>> > >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >>
>> > >> >>
>> ---------------------------------------------------------------------
>> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> > >> >>
>> > >> >>
>> > >> >
>> > >> > --
>> > >> > ------------------------
>> > >> > Guillaume Nodet
>> > >> >
>> > >> >
>> > >>
>> > >> --
>> > >> ------------------------
>> > >> Guillaume Nodet
>> > >>
>> > >
>> >
>>
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Now imports. But somewhat "named capabilities". Most of the plugins (vast
majority) would use the default of "*" (give me whatever you have).
If I look at this file:
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml
I see "capabilities" like:
- m4 api
- m3 api x
- wagon x?
- resolver x
- classworlds x?
- plexus-xml x? <- Guillaume?
- plexus-container x
- jsr330
- jsr250
- slf4j
- jansi
Note: in some future maven 4.5/5/whatever entries marked with "x" are gone.
Those with "?" capabilities are unsure if I am right or not (that will be
gone), Guillaume will chime in hopefully.
The vast majority of plugins will not bother with these settings at all
(will have default value of "*").
Some may want to tune it, like not having jsr330 or slf4j, or purist
plugins may ask only for "m4api".
Point is (whether enum or not) is:
if a plugin asks for capability that maven runtime does not have (for
example m3api in maven 5) -> leads to breakage.
===
BUT, I said this would be a "dream" :) Do not stick to it. Am completely
fine with a flag as I described before.
T
On Fri, Nov 18, 2022 at 7:36 PM Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Guess if you start to enable imports of components outside the API all the
> API work done for m4 disappear and you get back in current state, ie a mojo
> is not able to know what it can rely on from maven until we create an enum
> and it would be we put jsr330 (note this one does not mean much since the
> injected type will be the most important), slf4j are part of the API and we
> said we don't want that - for goods so sounds like we should stick to the
> API respect IMHO and if needed promote some new API, no?
>
> 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 ven. 18 nov. 2022 à 19:11, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Howdy,
> >
> > just to describe a bit what I meant under "reversed flag":
> >
> > default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
> > Plugin classrealm gets (from memory, might be incomplete or wrong):
> > - m4 API
> > - m3 "plugin-api"
> > - javax.inject
> > - resolver api
> > - etc as today
> >
> > consider that MANY plugins have components, and creating components in
> > MAJORITY of plugins is easy and should remain easy (and offered "out of
> the
> > box").
> >
> > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
> > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> > plugin can do whatever it wants, but still has access to m4 API (that is
> > heaven vs earth when compared to m3 state of affairs).
> >
> > ===
> >
> > in future, when we drop m3 support, this could mean:
> >
> > false (default)
> > - m4 API
> > - javax.inject
> >
> > true
> > -m4 API
> >
> > ===
> >
> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
> > values:
> > - * <- plugin classrealm should have all "capabilities" current Maven
> > runtime provides
> > - m4api <- I want maven 4 api ONLY
> > - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
> drops
> > m3 backward compat), slf4j logging and would use jsr330 components
> > "capability"
> >
> > But this is getting too wild maybe :)
> >
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> >
> > > Howdy,
> > >
> > > Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> > > downloads the whole world", at least latest plugins by putting Maven
> and
> > > friends in provided scope will not download dozens of versions of
> > > maven-core and friends... If we do this, at one point we would end up
> > with
> > > plugins downloading dozens of DI container (or their versions), as even
> > ASF
> > > plugins would not be in "lockstep".
> > >
> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > > that would say maven "I will be in charge of my components" (defaults
> to
> > > false, Maven behaves as today). When true, it would mean Mojo wants to
> > > bootstrap some DI/whatever container of its own, and then, for plugins
> > like
> > > these, Maven could even "narrow" the list of exported classes? (like
> > > javax.inject?)
> > >
> > > T
> > >
> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > >> Following up on my previous response, and in a more realistic way than
> > >> switching to OSGi, I wonder if we should let maven 4 plugins do their
> > own
> > >> DI injection and only care about the mojos, i.e. not rely on
> sisu/plexus
> > >> to
> > >> create and inject the mojo. Mojos using the v4 api do not need to be
> > >> injected with other components from maven, they should all come from
> the
> > >> api and should be retrieved using Session.getService(xx), or simply
> > using
> > >> session's shortcut methods. The injection of Project and Session is
> not
> > >> controlled by sisu. For the ComponentConfigurator, we could change the
> > >> mojo
> > >> descriptor to have the full configuration class name for mojos that
> > >> require
> > >> custom configuration injection, the plugin manager being in charge of
> > >> instantiating this class and using it as a ComponentConfigurator
> (which
> > is
> > >> not part yet of the api btw).
> > >>
> > >> Complex plugins which rely on plexus/sisu to do some custom injection
> > >> would
> > >> have to be changed to do their own DI, maybe using a simple Guice
> setup.
> > >>
> > >> If that sounds like too big a change for those plugins, we may be able
> > to
> > >> add a flag on the mojo descriptor so that those v4-enabled mojos would
> > >> trigger a DI injection on behalf of the plugin. But if we have to
> > >> implement something like that, I would go for a plain CDI-like api,
> > either
> > >> using guice or another DI library supporting the javax.inject package,
> > or
> > >> rather the jakarta.inject package, as it would be nice to switch to
> the
> > >> jakarta version at the same time. Or maybe even plexus if we really
> > need
> > >> to, but with a limited scope, i.e. no visibility on the maven
> > components,
> > >> so that plugins are better decoupled from maven-core.
> > >>
> > >> Thoughts ?
> > >>
> > >> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> > >> écrit :
> > >>
> > >> > I do agree that debugging the provisioning side is *very*
> complicated
> > >> when
> > >> > there's a problem.
> > >> > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > >> framework,
> > >> > at least for simple plugins.
> > >> > However, I definitely don't think pushing OSGi to plugins would be a
> > >> good
> > >> > idea : the cost and burden on plugin developers would outweigh the
> > >> benefits.
> > >> >
> > >> > For extensions, and for maven itself, that is a different story
> > though.
> > >> > Maven and extensions could definitely benefit from OSGi, but this
> > would
> > >> be
> > >> > a complete breakage and it would be hard to keep some level of
> > >> > compatibility.
> > >> >
> > >> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> mail@laeubi-soft.de
> > >
> > >> a
> > >> > écrit :
> > >> >
> > >> >> > Guess classrealm is fine for maven, it does not bring much
> issues
> > >> >>
> > >> >> As long as it works, maybe, maybe even if you write a simple maven
> > >> >> plugin, but for any more complex it is just a complete mess.
> > >> >>
> > >> >> Last time I asked on the mailing list how to debug that stuff ...
> > >> >> complete silence ...
> > >> >>
> > >> >> Today I tried to refactor the name of one module of a more complex
> > >> >> maven-plugin (with core extension), now I end up with
> > >> >>
> > >> >> org.apache.maven.InternalErrorException: Internal error:
> > >> >> com.google.inject.ProvisionException: Unable to provision, see the
> > >> >> following errors:
> > >> >> 1) No implementation for org.eclipse.aether.RepositorySystem was
> > bound.
> > >> >>
> > >> >> A whole bunch of stack trace but not a little info why the ***** it
> > is
> > >> >> not happy. Now I need to add random "exportedArtifact" /
> > >> >> "exportedPackage" stuff to hope finding out where it has lost a
> > >> >> transitive dependency, also here absolutely no documentation what
> > this
> > >> >> is supposed to do/work exactly beside some introduction that these
> > xml
> > >> >> tags exits and reading the code... or probably add maven-compat
> > >> >> anywhere... or change provided to compile scope (even maven is
> > jelling
> > >> >> at me that's bad and I will be punished soon)... not counting the
> > many
> > >> >> times where I messed up the realms because I accidentally trying to
> > use
> > >> >> XppDom objects in extensions and plugins and something between got
> > >> >> messed up.
> > >> >>
> > >> >> With OSGi i get clear errors for missing requirements, I can
> clearly
> > >> >> share API (or declare I don't want to share it) and can reliable
> use
> > it
> > >> >> without classlaoding problems.
> > >> >> If one wan't can even implement service filtering that would hide
> all
> > >> >> "illegal implemented API" ... and you can even make sure API is
> > >> >> (backward) compatible with implementation without waiting for a
> > method
> > >> >> not found exception or alike.
> > >> >>
> > >> >> Beside that I find it often more clear to distinguish between API
> > (that
> > >> >> is only implemented by the framework) and SPI (that might be
> > >> implemented
> > >> >> by extenders). So probably it would be good to have maven-api and
> > >> >> maven-spi (instead of "maven-core") to make this clear.
> > >> >>
> > >> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> > >> >> > Hi,
> > >> >> >
> > >> >> > Guess classrealm is fine for maven, it does not bring much issues
> > >> (less
> > >> >> > than OSGi or JPMS to be concrete), the real issue is the
> stability
> > of
> > >> >> the
> > >> >> > exposed API.
> > >> >> > Thanks the hard work Guillaume did on that for maven 4 I guess it
> > is
> > >> >> mainly
> > >> >> > a matter of deciding what we do for maven 3.
> > >> >> > Due to the resources and work needed I assume we can just play
> the
> > >> >> > status-quo for maven 3.
> > >> >> > Remaining question is for maven 4 do we drop the compatibilty. I
> > >> don't
> > >> >> like
> > >> >> > much the idea but a compat layer can solve that smoothly for
> maven
> > >> >= 4
> > >> >> and
> > >> >> > limit the work needed, no?
> > >> >> >
> > >> >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> > >> mail@laeubi-soft.de>
> > >> >> a
> > >> >> > écrit :
> > >> >> >
> > >> >> >> If you really like to separate API and get out of the
> > >> ClassRealm-Hell
> > >> >> >> OSGi would be much more suitable:
> > >> >> >>
> > >> >> >> https://issues.apache.org/jira/browse/MNG-7518
> > >> >> >>
> > >> >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > >> >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to
> Java 9
> > >> or
> > >> >> 11
> > >> >> >> and
> > >> >> >>> adopt JPMS to better define its public APIs.
> > >> >> >>>
> > >> >> >>> Gary
> > >> >> >>>
> > >> >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> tamas@cservenak.net
> > >
> > >> >> wrote:
> > >> >> >>>
> > >> >> >>>> Yes, to define rules is quite easy, but to make our users to
> > obey
> > >> >> them
> > >> >> >> is
> > >> >> >>>> tricky :D
> > >> >> >>>>
> > >> >> >>>> In general, I guess, we should. For this reason JapiCmp has
> been
> > >> >> used in
> > >> >> >>>> Resolver since 1.9.0 (as noted on refd page end).
> > >> >> >>>>
> > >> >> >>>> But while this was "kinda simple" to achieve in Resolver, I am
> > >> really
> > >> >> >>>> unsure if it is doable in Maven (sans 4 API) :(
> > >> >> >>>>
> > >> >> >>>> Ultimately, this was the whole reason for API:
> > >> >> >>>> - users "grabbed" whatever could get hold on and used
> > >> >> >>>> - maven progress was really hindered by this, as that meant
> > >> modifying
> > >> >> >> (even
> > >> >> >>>> internal) interfaces without breaking clients was impossible,
> so
> > >> we
> > >> >> went
> > >> >> >>>> with tricks, and more tricks and even more tricks that now
> pays
> > >> back.
> > >> >> >>>>
> > >> >> >>>> The other day we had a question on ML about 4-alpha
> > compatibility
> > >> >> >> breakage,
> > >> >> >>>> and from mail it was clear that the package of the referred
> > class
> > >> was
> > >> >> >>>> having "internal" in it. I mean, developers should really take
> > >> care
> > >> >> of
> > >> >> >> what
> > >> >> >>>> they import.
> > >> >> >>>>
> > >> >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
> > >> >> compilation
> > >> >> >>>> against "encapsulated" internal classes....
> > >> >> >>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> > >> >> >>>>
> > >> >> >>>> T
> > >> >> >>>>
> > >> >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> > kwin@apache.org
> > >> >
> > >> >> >> wrote:
> > >> >> >>>>
> > >> >> >>>>> I guess this is the easy part, the tricky question remains:
> Do
> > we
> > >> >> need
> > >> >> >> to
> > >> >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> > >> >> backwards
> > >> >> >>>>> compatible until we reach 4.100/5.0/whatever?
> > >> >> >>>>>
> > >> >> >>>>> This wasn't handled consistently in master till now, e.g. the
> > >> >> classes
> > >> >> >>>>> generated from
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > >> >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> > >> >> >>>>> My change in
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > >> >> >>>>> was not backwards compatible (removed a method on an
> interface
> > >> which
> > >> >> >> may
> > >> >> >>>>> have been implemented by extensions...)
> > >> >> >>>>>
> > >> >> >>>>> Konrad
> > >> >> >>>>>
> > >> >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > >> >> >>>>>> Unsure we want to deprecate all of Maven :)
> > >> >> >>>>>>
> > >> >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> > >> grab"
> > >> >> >>>> sadly,
> > >> >> >>>>>> and is probably our major source of problems and reason we
> > >> started
> > >> >> >>>> Maven
> > >> >> >>>>> 4
> > >> >> >>>>>> API.
> > >> >> >>>>>>
> > >> >> >>>>>> IMO, I'd consider them as "whole", and just say "starting
> with
> > >> >> Maven
> > >> >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> > NOT
> > >> >> >>>>> ACCESSIBLE
> > >> >> >>>>>> ANYMORE FROM PLUGINS.
> > >> >> >>>>>> And done.
> > >> >> >>>>>>
> > >> >> >>>>>> Just as an example, here is what Maven Resolver has to say
> > about
> > >> >> same
> > >> >> >>>>> topic
> > >> >> >>>>>> (part of not-yet-released, vote is in process 1.9.1
> version):
> > >> >> >>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > >> >> >>>>>>
> > >> >> >>>>>> HTH
> > >> >> >>>>>> T
> > >> >> >>>>>>
> > >> >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> > >> kwin@apache.org>
> > >> >> >>>>> wrote:
> > >> >> >>>>>>
> > >> >> >>>>>>> I see now there is already
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > >> >> >>>>>>> but to me the javadoc is not explicit enough. It should
> > state:
> > >> >> Only
> > >> >> >>>>> Maven
> > >> >> >>>>>>> is allowed to implement/extend types with this annotation.
> > >> >> >>>>>>>
> > >> >> >>>>>>> Konrad
> > >> >> >>>>>>>
> > >> >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > >> >> >>>>>>>> Hi,
> > >> >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In
> effect
> > >> >> >>>>> everything
> > >> >> >>>>>>> somehow exposed through class loaders was considered API by
> > >> >> >>>>>>> plugin/extension developers.
> > >> >> >>>>>>>> For Maven 4 a completely separate API was established in
> > >> package
> > >> >> >>>>>>> “org.apache.maven.api”, but what about the old packages
> used
> > >> and
> > >> >> >>>>> exported
> > >> >> >>>>>>> in Maven 3?
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> For example in the context of
> > >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> > >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> > >> evolve
> > >> >> the
> > >> >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> > >> >> >>>>>>>> We already figured out that this particular package
> > (although
> > >> not
> > >> >> >>>>> part
> > >> >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> > >> Maven
> > >> >> >>>>> Plugin
> > >> >> >>>>>>> Tools, therefore this probably needs to stay backwards
> > >> compatible.
> > >> >> >>>>>>>> What about others like
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > >> >> >>>>> ?
> > >> >> >>>>>>> <
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > >> >> >>>>>>> ?>
> > >> >> >>>>>>>> This interface should IMHO never been implemented outside
> > >> Maven
> > >> >> >>>> Core
> > >> >> >>>>> but
> > >> >> >>>>>>> in fact it was exposed to all plugins/extensions (via
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >> >> >>>>>>> <
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >> >> >>>>>>>> ).
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> There are three options coming to my mind:
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> create
> > >> new
> > >> >> >>>> ones
> > >> >> >>>>>>> for Maven 4 which are not exported!
> > >> >> >>>>>>>> 2. Modify the existing interfaces in a backwards
> compatible
> > >> way
> > >> >> >>>> (but
> > >> >> >>>>>>> somehow add a marker that they should not be implemented
> > >> outside
> > >> >> >>>> core)
> > >> >> >>>>>>>> 3. Modify the existing interfaces in a backwards
> compatible
> > >> way
> > >> >> >>>> (but
> > >> >> >>>>>>> somehow add a marker that they should not be implemented
> > >> outside
> > >> >> >>>> core)
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> For all three options we somehow need to come up with a
> list
> > >> of
> > >> >> >>>>>>> classes/interfaces currently being exported through the API
> > >> class
> > >> >> >>>>> loader,
> > >> >> >>>>>>> which should be considered private and agree on an
> > >> >> Annotation/Javadoc
> > >> >> >>>>> for
> > >> >> >>>>>>> that (something like
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >> >> >>>>>>> <
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>
> > >> >>
> > >>
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >> >> >>>>>>
> > >> >> >>>>>>> or
> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> > >> <
> > >> >> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> WDYT?
> > >> >> >>>>>>>>
> > >> >> >>>>>>>> Konrad
> > >> >> >>>>>>>>
> > >> >> >>>>>>>>
> > >> >> >>>>>>>
> > >> >> >>>>>>>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >> >>>>>>>
> > >> >> >>>>>>>
> > >> >> >>>>>>
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>>
> > >> >> >>>
> > >> >> >>
> > >> >> >>
> > >> ---------------------------------------------------------------------
> > >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>
> > >> >>
> > >> >
> > >> > --
> > >> > ------------------------
> > >> > Guillaume Nodet
> > >> >
> > >> >
> > >>
> > >> --
> > >> ------------------------
> > >> Guillaume Nodet
> > >>
> > >
> >
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Guess if you start to enable imports of components outside the API all the
API work done for m4 disappear and you get back in current state, ie a mojo
is not able to know what it can rely on from maven until we create an enum
and it would be we put jsr330 (note this one does not mean much since the
injected type will be the most important), slf4j are part of the API and we
said we don't want that - for goods so sounds like we should stick to the
API respect IMHO and if needed promote some new API, no?
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 ven. 18 nov. 2022 à 19:11, Tamás Cservenák <ta...@cservenak.net> a
écrit :
> Howdy,
>
> just to describe a bit what I meant under "reversed flag":
>
> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
> Plugin classrealm gets (from memory, might be incomplete or wrong):
> - m4 API
> - m3 "plugin-api"
> - javax.inject
> - resolver api
> - etc as today
>
> consider that MANY plugins have components, and creating components in
> MAJORITY of plugins is easy and should remain easy (and offered "out of the
> box").
>
> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> plugin can do whatever it wants, but still has access to m4 API (that is
> heaven vs earth when compared to m3 state of affairs).
>
> ===
>
> in future, when we drop m3 support, this could mean:
>
> false (default)
> - m4 API
> - javax.inject
>
> true
> -m4 API
>
> ===
>
> Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
> values:
> - * <- plugin classrealm should have all "capabilities" current Maven
> runtime provides
> - m4api <- I want maven 4 api ONLY
> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that drops
> m3 backward compat), slf4j logging and would use jsr330 components
> "capability"
>
> But this is getting too wild maybe :)
>
>
> T
>
> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
> wrote:
>
> > Howdy,
> >
> > Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> > downloads the whole world", at least latest plugins by putting Maven and
> > friends in provided scope will not download dozens of versions of
> > maven-core and friends... If we do this, at one point we would end up
> with
> > plugins downloading dozens of DI container (or their versions), as even
> ASF
> > plugins would not be in "lockstep".
> >
> > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > that would say maven "I will be in charge of my components" (defaults to
> > false, Maven behaves as today). When true, it would mean Mojo wants to
> > bootstrap some DI/whatever container of its own, and then, for plugins
> like
> > these, Maven could even "narrow" the list of exported classes? (like
> > javax.inject?)
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> >> Following up on my previous response, and in a more realistic way than
> >> switching to OSGi, I wonder if we should let maven 4 plugins do their
> own
> >> DI injection and only care about the mojos, i.e. not rely on sisu/plexus
> >> to
> >> create and inject the mojo. Mojos using the v4 api do not need to be
> >> injected with other components from maven, they should all come from the
> >> api and should be retrieved using Session.getService(xx), or simply
> using
> >> session's shortcut methods. The injection of Project and Session is not
> >> controlled by sisu. For the ComponentConfigurator, we could change the
> >> mojo
> >> descriptor to have the full configuration class name for mojos that
> >> require
> >> custom configuration injection, the plugin manager being in charge of
> >> instantiating this class and using it as a ComponentConfigurator (which
> is
> >> not part yet of the api btw).
> >>
> >> Complex plugins which rely on plexus/sisu to do some custom injection
> >> would
> >> have to be changed to do their own DI, maybe using a simple Guice setup.
> >>
> >> If that sounds like too big a change for those plugins, we may be able
> to
> >> add a flag on the mojo descriptor so that those v4-enabled mojos would
> >> trigger a DI injection on behalf of the plugin. But if we have to
> >> implement something like that, I would go for a plain CDI-like api,
> either
> >> using guice or another DI library supporting the javax.inject package,
> or
> >> rather the jakarta.inject package, as it would be nice to switch to the
> >> jakarta version at the same time. Or maybe even plexus if we really
> need
> >> to, but with a limited scope, i.e. no visibility on the maven
> components,
> >> so that plugins are better decoupled from maven-core.
> >>
> >> Thoughts ?
> >>
> >> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> >> écrit :
> >>
> >> > I do agree that debugging the provisioning side is *very* complicated
> >> when
> >> > there's a problem.
> >> > I'd be happy to get rid of sisu/plexus and use a more simple DI
> >> framework,
> >> > at least for simple plugins.
> >> > However, I definitely don't think pushing OSGi to plugins would be a
> >> good
> >> > idea : the cost and burden on plugin developers would outweigh the
> >> benefits.
> >> >
> >> > For extensions, and for maven itself, that is a different story
> though.
> >> > Maven and extensions could definitely benefit from OSGi, but this
> would
> >> be
> >> > a complete breakage and it would be hard to keep some level of
> >> > compatibility.
> >> >
> >> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <mail@laeubi-soft.de
> >
> >> a
> >> > écrit :
> >> >
> >> >> > Guess classrealm is fine for maven, it does not bring much issues
> >> >>
> >> >> As long as it works, maybe, maybe even if you write a simple maven
> >> >> plugin, but for any more complex it is just a complete mess.
> >> >>
> >> >> Last time I asked on the mailing list how to debug that stuff ...
> >> >> complete silence ...
> >> >>
> >> >> Today I tried to refactor the name of one module of a more complex
> >> >> maven-plugin (with core extension), now I end up with
> >> >>
> >> >> org.apache.maven.InternalErrorException: Internal error:
> >> >> com.google.inject.ProvisionException: Unable to provision, see the
> >> >> following errors:
> >> >> 1) No implementation for org.eclipse.aether.RepositorySystem was
> bound.
> >> >>
> >> >> A whole bunch of stack trace but not a little info why the ***** it
> is
> >> >> not happy. Now I need to add random "exportedArtifact" /
> >> >> "exportedPackage" stuff to hope finding out where it has lost a
> >> >> transitive dependency, also here absolutely no documentation what
> this
> >> >> is supposed to do/work exactly beside some introduction that these
> xml
> >> >> tags exits and reading the code... or probably add maven-compat
> >> >> anywhere... or change provided to compile scope (even maven is
> jelling
> >> >> at me that's bad and I will be punished soon)... not counting the
> many
> >> >> times where I messed up the realms because I accidentally trying to
> use
> >> >> XppDom objects in extensions and plugins and something between got
> >> >> messed up.
> >> >>
> >> >> With OSGi i get clear errors for missing requirements, I can clearly
> >> >> share API (or declare I don't want to share it) and can reliable use
> it
> >> >> without classlaoding problems.
> >> >> If one wan't can even implement service filtering that would hide all
> >> >> "illegal implemented API" ... and you can even make sure API is
> >> >> (backward) compatible with implementation without waiting for a
> method
> >> >> not found exception or alike.
> >> >>
> >> >> Beside that I find it often more clear to distinguish between API
> (that
> >> >> is only implemented by the framework) and SPI (that might be
> >> implemented
> >> >> by extenders). So probably it would be good to have maven-api and
> >> >> maven-spi (instead of "maven-core") to make this clear.
> >> >>
> >> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >> >> > Hi,
> >> >> >
> >> >> > Guess classrealm is fine for maven, it does not bring much issues
> >> (less
> >> >> > than OSGi or JPMS to be concrete), the real issue is the stability
> of
> >> >> the
> >> >> > exposed API.
> >> >> > Thanks the hard work Guillaume did on that for maven 4 I guess it
> is
> >> >> mainly
> >> >> > a matter of deciding what we do for maven 3.
> >> >> > Due to the resources and work needed I assume we can just play the
> >> >> > status-quo for maven 3.
> >> >> > Remaining question is for maven 4 do we drop the compatibilty. I
> >> don't
> >> >> like
> >> >> > much the idea but a compat layer can solve that smoothly for maven
> >> >= 4
> >> >> and
> >> >> > limit the work needed, no?
> >> >> >
> >> >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >> mail@laeubi-soft.de>
> >> >> a
> >> >> > écrit :
> >> >> >
> >> >> >> If you really like to separate API and get out of the
> >> ClassRealm-Hell
> >> >> >> OSGi would be much more suitable:
> >> >> >>
> >> >> >> https://issues.apache.org/jira/browse/MNG-7518
> >> >> >>
> >> >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >> >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
> >> or
> >> >> 11
> >> >> >> and
> >> >> >>> adopt JPMS to better define its public APIs.
> >> >> >>>
> >> >> >>> Gary
> >> >> >>>
> >> >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <tamas@cservenak.net
> >
> >> >> wrote:
> >> >> >>>
> >> >> >>>> Yes, to define rules is quite easy, but to make our users to
> obey
> >> >> them
> >> >> >> is
> >> >> >>>> tricky :D
> >> >> >>>>
> >> >> >>>> In general, I guess, we should. For this reason JapiCmp has been
> >> >> used in
> >> >> >>>> Resolver since 1.9.0 (as noted on refd page end).
> >> >> >>>>
> >> >> >>>> But while this was "kinda simple" to achieve in Resolver, I am
> >> really
> >> >> >>>> unsure if it is doable in Maven (sans 4 API) :(
> >> >> >>>>
> >> >> >>>> Ultimately, this was the whole reason for API:
> >> >> >>>> - users "grabbed" whatever could get hold on and used
> >> >> >>>> - maven progress was really hindered by this, as that meant
> >> modifying
> >> >> >> (even
> >> >> >>>> internal) interfaces without breaking clients was impossible, so
> >> we
> >> >> went
> >> >> >>>> with tricks, and more tricks and even more tricks that now pays
> >> back.
> >> >> >>>>
> >> >> >>>> The other day we had a question on ML about 4-alpha
> compatibility
> >> >> >> breakage,
> >> >> >>>> and from mail it was clear that the package of the referred
> class
> >> was
> >> >> >>>> having "internal" in it. I mean, developers should really take
> >> care
> >> >> of
> >> >> >> what
> >> >> >>>> they import.
> >> >> >>>>
> >> >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >> >> compilation
> >> >> >>>> against "encapsulated" internal classes....
> >> >> >>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >> >> >>>>
> >> >> >>>> T
> >> >> >>>>
> >> >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> kwin@apache.org
> >> >
> >> >> >> wrote:
> >> >> >>>>
> >> >> >>>>> I guess this is the easy part, the tricky question remains: Do
> we
> >> >> need
> >> >> >> to
> >> >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >> >> backwards
> >> >> >>>>> compatible until we reach 4.100/5.0/whatever?
> >> >> >>>>>
> >> >> >>>>> This wasn't handled consistently in master till now, e.g. the
> >> >> classes
> >> >> >>>>> generated from
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >> >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >> >> >>>>> My change in
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >> >> >>>>> was not backwards compatible (removed a method on an interface
> >> which
> >> >> >> may
> >> >> >>>>> have been implemented by extensions...)
> >> >> >>>>>
> >> >> >>>>> Konrad
> >> >> >>>>>
> >> >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >> >> >>>>>> Unsure we want to deprecate all of Maven :)
> >> >> >>>>>>
> >> >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> >> grab"
> >> >> >>>> sadly,
> >> >> >>>>>> and is probably our major source of problems and reason we
> >> started
> >> >> >>>> Maven
> >> >> >>>>> 4
> >> >> >>>>>> API.
> >> >> >>>>>>
> >> >> >>>>>> IMO, I'd consider them as "whole", and just say "starting with
> >> >> Maven
> >> >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> NOT
> >> >> >>>>> ACCESSIBLE
> >> >> >>>>>> ANYMORE FROM PLUGINS.
> >> >> >>>>>> And done.
> >> >> >>>>>>
> >> >> >>>>>> Just as an example, here is what Maven Resolver has to say
> about
> >> >> same
> >> >> >>>>> topic
> >> >> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >> >> >>>>>>
> >> >> >>>>>> HTH
> >> >> >>>>>> T
> >> >> >>>>>>
> >> >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >> kwin@apache.org>
> >> >> >>>>> wrote:
> >> >> >>>>>>
> >> >> >>>>>>> I see now there is already
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >> >> >>>>>>> but to me the javadoc is not explicit enough. It should
> state:
> >> >> Only
> >> >> >>>>> Maven
> >> >> >>>>>>> is allowed to implement/extend types with this annotation.
> >> >> >>>>>>>
> >> >> >>>>>>> Konrad
> >> >> >>>>>>>
> >> >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >> >> >>>>>>>> Hi,
> >> >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >> >> >>>>> everything
> >> >> >>>>>>> somehow exposed through class loaders was considered API by
> >> >> >>>>>>> plugin/extension developers.
> >> >> >>>>>>>> For Maven 4 a completely separate API was established in
> >> package
> >> >> >>>>>>> “org.apache.maven.api”, but what about the old packages used
> >> and
> >> >> >>>>> exported
> >> >> >>>>>>> in Maven 3?
> >> >> >>>>>>>>
> >> >> >>>>>>>> For example in the context of
> >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >> evolve
> >> >> the
> >> >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> >> >> >>>>>>>> We already figured out that this particular package
> (although
> >> not
> >> >> >>>>> part
> >> >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> >> Maven
> >> >> >>>>> Plugin
> >> >> >>>>>>> Tools, therefore this probably needs to stay backwards
> >> compatible.
> >> >> >>>>>>>> What about others like
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >> >> >>>>> ?
> >> >> >>>>>>> <
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >> >> >>>>>>> ?>
> >> >> >>>>>>>> This interface should IMHO never been implemented outside
> >> Maven
> >> >> >>>> Core
> >> >> >>>>> but
> >> >> >>>>>>> in fact it was exposed to all plugins/extensions (via
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >> >> >>>>>>> <
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >> >> >>>>>>>> ).
> >> >> >>>>>>>>
> >> >> >>>>>>>> There are three options coming to my mind:
> >> >> >>>>>>>>
> >> >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
> >> new
> >> >> >>>> ones
> >> >> >>>>>>> for Maven 4 which are not exported!
> >> >> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> >> way
> >> >> >>>> (but
> >> >> >>>>>>> somehow add a marker that they should not be implemented
> >> outside
> >> >> >>>> core)
> >> >> >>>>>>>> 3. Modify the existing interfaces in a backwards compatible
> >> way
> >> >> >>>> (but
> >> >> >>>>>>> somehow add a marker that they should not be implemented
> >> outside
> >> >> >>>> core)
> >> >> >>>>>>>>
> >> >> >>>>>>>> For all three options we somehow need to come up with a list
> >> of
> >> >> >>>>>>> classes/interfaces currently being exported through the API
> >> class
> >> >> >>>>> loader,
> >> >> >>>>>>> which should be considered private and agree on an
> >> >> Annotation/Javadoc
> >> >> >>>>> for
> >> >> >>>>>>> that (something like
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >> >> >>>>>>> <
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>
> >> >>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >> >> >>>>>>
> >> >> >>>>>>> or
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >> <
> >> >> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >> >> >>>>>>>>
> >> >> >>>>>>>> WDYT?
> >> >> >>>>>>>>
> >> >> >>>>>>>> Konrad
> >> >> >>>>>>>>
> >> >> >>>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> ---------------------------------------------------------------------
> >> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> > --
> >> > ------------------------
> >> > Guillaume Nodet
> >> >
> >> >
> >>
> >> --
> >> ------------------------
> >> Guillaume Nodet
> >>
> >
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Guillaume Nodet <gn...@apache.org>.
I haven't proposed any real change to the classloading in this discussion
afair. Extensions can currently contribute packages and artifacts and that
is ok. At some point, the stock maven should only expose the maven4 api
with no additional packages. THis is currently not the case as the same
classloader is used for maven 3 and maven 4 plugins.
If a plugin wants to communicate with a different plugin or with an
extension, it should be doable through the Session#getSessionData() which
can contain any kind of object. It may also be possible through
Session#getService() if the extension has a bean that implements the
Service interface. If that's not sufficient, we could add an explicit way
to expose additional services I suppose.
My proposal is simply to reduce the scope of the DI mechanism used to the
classloader of the plugin (without even scanning the parent classloader),
and maybe using a tiny DI mechanism to ease maintenance and debugging.
Le dim. 20 nov. 2022 à 07:59, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> This does not really answer the question. Extensions are made for
> extending maven(-plugins) (either on the core or the project level) so
> if plugins are only ever getting maven4-api available how will it be
> possible then?
>
> Whether or not Extensions are "bad" or not "maven spirit" seems a
> different topic for me.
>
> Am 19.11.22 um 14:51 schrieb Romain Manni-Bucau:
> > Sounds like some code needing to move to extensions more than some mojo
> > interactions to me to stick to a simple and maven spirit.
> >
> > Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> > That's a good question. Plugins currently don't interact.
> >> > Is that really something we want ?
> >>
> >> At least there are several places where I wish I could "plug" into an
> >> existing plugin, curently for example surefire allows some limited
> >> extension using test-frameworks but this requires special configuration.
> >>
> >> A good example might be the "set-version" plugin, where in the context
> >> of Tycho one needs to also update versions not only in the
> >> pom.xml/dependency part, the current approach is we actually
> >> copy/replicate what set-version does, but this obviously is far from
> >> optimal. The same applies to jar-plugin (where for example BND plugin
> >> requires special setup/configuration) and even the release-plugin
> >> currently would be something where one needs to do special enhancement
> >> that are hard to maintain and manage.
> >>
> >> That's why I previously mentioned in a "we have one isolated mojo"
> >> scenario everything might looks easy and great, but when it comes to
> >> complex setups it gets complicated fast.
> >>
> >> > I'd rather keep things simple if possible. They can use the Session
> >>
> >> I as well but the problem arises if you want to share more than a simple
> >> string or integer. For example currently Tycho has a project-extension
> >> and also a core-extension part and then people can configure different
> >> mojos ... for sure one can put everything in one big fat jar but that's
> >> really hard to manage and configure, so we have split this up into
> >> smaller mojos.
> >>
> >> Still they need to interact (e.g. to not calculate the same stuff over
> >> and over again)... this mostly works as we export some packages that are
> >> kind of "tycho-api" but as one don't write all from scratch there are of
> >> course other dependencies to consider. Even that works, but we always
> >> see issues with classpath incompatibilities that are really hard to
> >> track, e.g. if version of core-extension do not match 100% version of
> >> plugin used in the pom... And i have totally no clue what would happen
> >> if there is another extension also exporting the same dependency ...
> >>
> >>
> >> Am 19.11.22 um 09:37 schrieb Guillaume Nodet:
> >>> Requiring OSGi for anything user facing in maven is a no-go for me.
> >>>
> >>> Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> >>> écrit :
> >>>
> >>>> > Dreaming: but what if not a flag, but some filter(s) for
> >> "capabilities"?
> >>>>
> >>>> OSGi support generic capabilities/requirements model:
> >>>>
> https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
> >>>>
> >>>> Just mentioning it ... for sure we one can re-implement this (again)
> in
> >>>> maven as well, as a prime goal seems not to reuse existing techniques
> >> ;-)
> >>>>
> >>>
> >>> I've been working full time on OSGi for 10 years or so. So I'm quite
> >> aware
> >>> of the benefits... and the costs.
> >>> I don't think we need maven to provide any choice here.
> >>>
> >>>
> >>>>
> >>>> With all this perfect "only m4api" world I'm just wondering how will
> >>>> this work together with extensions (either core or project ones) and
> how
> >>>> is it supposed to allow different plugins to interact?
> >>>>
> >>>
> >>> That's a good question. Plugins currently don't interact. Is that
> really
> >>> something we want ?
> >>> I'd rather keep things simple if possible. They can use the Session
> >>>
> >>>
> >>>> Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
> >>>>> Howdy,
> >>>>>
> >>>>> just to describe a bit what I meant under "reversed flag":
> >>>>>
> >>>>> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as
> >> today.
> >>>>> Plugin classrealm gets (from memory, might be incomplete or wrong):
> >>>>> - m4 API
> >>>>> - m3 "plugin-api"
> >>>>> - javax.inject
> >>>>> - resolver api
> >>>>> - etc as today
> >>>>>
> >>>>> consider that MANY plugins have components, and creating components
> in
> >>>>> MAJORITY of plugins is easy and should remain easy (and offered "out
> of
> >>>> the
> >>>>> box").
> >>>>
> >>>> Sounds good to me.
> >>>
> >>>
> >>>>> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
> >> realm
> >>>>> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox,
> the
> >>>>> plugin can do whatever it wants, but still has access to m4 API (that
> >> is
> >>>>> heaven vs earth when compared to m3 state of affairs).
> >>>>
> >>>> Not sure there's any benefit. If we use a custom package for a few DI
> >>> annotation,
> >>> there will be no conflict, so if there's no maven component defined,
> >>> nothing will be done
> >>> and the plugin is still free to use its own DI if it needs.
> >>>
> >>>
> >>>>> ===
> >>>>>
> >>>>> in future, when we drop m3 support, this could mean:
> >>>>>
> >>>>> false (default)
> >>>>> - m4 API
> >>>>> - javax.inject
> >>>>>
> >>>>> true
> >>>>> -m4 API
> >>>>>
> >>>>> ===
> >>>>>
> >>>>> Dreaming: but what if not a flag, but some filter(s) for
> >> "capabilities"?
> >>>>> values:
> >>>>> - * <- plugin classrealm should have all "capabilities" current Maven
> >>>>> runtime provides
> >>>>> - m4api <- I want maven 4 api ONLY
> >>>>> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
> >>>> drops
> >>>>> m3 backward compat), slf4j logging and would use jsr330 components
> >>>>> "capability"
> >>>>>
> >>>>> But this is getting too wild maybe :)
> >>>>
> >>>
> >>> Simple is good.
> >>>
> >>> Not touching maven 3 plugins or they way they are loaded at all, I'd
> >>> propose:
> >>> * define a few annotations in org.apache.maven.api.di package, we
> >> really
> >>> don't need many, maybe just @Inject, @Bean
> >>> * make sure the plugin classloader does only expose the api to
> maven
> >>> plugins
> >>> * write a simplistic DI framework
> >>> * make sure plugin can use a different DI framework if they need
> >>>
> >>> Guillaume
> >>>
> >>>> T
> >>>>>
> >>>>> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <tamas@cservenak.net
> >
> >>>> wrote:
> >>>>>
> >>>>>> Howdy,
> >>>>>>
> >>>>>> Am -1 on this. We just reached the point to (somewhat) undo the
> "Maven
> >>>>>> downloads the whole world", at least latest plugins by putting Maven
> >> and
> >>>>>> friends in provided scope will not download dozens of versions of
> >>>>>> maven-core and friends... If we do this, at one point we would end
> up
> >>>> with
> >>>>>> plugins downloading dozens of DI container (or their versions), as
> >> even
> >>>> ASF
> >>>>>> plugins would not be in "lockstep".
> >>>>>>
> >>>>>> OTOH, that said, I like the idea of a flag, but I'd reverse it: a
> flag
> >>>>>> that would say maven "I will be in charge of my components"
> (defaults
> >> to
> >>>>>> false, Maven behaves as today). When true, it would mean Mojo wants
> to
> >>>>>> bootstrap some DI/whatever container of its own, and then, for
> plugins
> >>>> like
> >>>>>> these, Maven could even "narrow" the list of exported classes? (like
> >>>>>> javax.inject?)
> >>>>>>
> >>>>>> T
> >>>>>>
> >>>>>> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> >>>> wrote:
> >>>>>>
> >>>>>>> Following up on my previous response, and in a more realistic way
> >> than
> >>>>>>> switching to OSGi, I wonder if we should let maven 4 plugins do
> their
> >>>> own
> >>>>>>> DI injection and only care about the mojos, i.e. not rely on
> >>>> sisu/plexus
> >>>>>>> to
> >>>>>>> create and inject the mojo. Mojos using the v4 api do not need to
> be
> >>>>>>> injected with other components from maven, they should all come
> from
> >>>> the
> >>>>>>> api and should be retrieved using Session.getService(xx), or simply
> >>>> using
> >>>>>>> session's shortcut methods. The injection of Project and Session
> is
> >>>> not
> >>>>>>> controlled by sisu. For the ComponentConfigurator, we could change
> >> the
> >>>>>>> mojo
> >>>>>>> descriptor to have the full configuration class name for mojos that
> >>>>>>> require
> >>>>>>> custom configuration injection, the plugin manager being in charge
> of
> >>>>>>> instantiating this class and using it as a ComponentConfigurator
> >>>> (which is
> >>>>>>> not part yet of the api btw).
> >>>>>>>
> >>>>>>> Complex plugins which rely on plexus/sisu to do some custom
> injection
> >>>>>>> would
> >>>>>>> have to be changed to do their own DI, maybe using a simple Guice
> >>>> setup.
> >>>>>>>
> >>>>>>> If that sounds like too big a change for those plugins, we may be
> >> able
> >>>> to
> >>>>>>> add a flag on the mojo descriptor so that those v4-enabled mojos
> >> would
> >>>>>>> trigger a DI injection on behalf of the plugin. But if we have to
> >>>>>>> implement something like that, I would go for a plain CDI-like api,
> >>>> either
> >>>>>>> using guice or another DI library supporting the javax.inject
> >> package,
> >>>> or
> >>>>>>> rather the jakarta.inject package, as it would be nice to switch to
> >> the
> >>>>>>> jakarta version at the same time. Or maybe even plexus if we
> really
> >>>> need
> >>>>>>> to, but with a limited scope, i.e. no visibility on the maven
> >>>> components,
> >>>>>>> so that plugins are better decoupled from maven-core.
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org>
> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> I do agree that debugging the provisioning side is *very*
> >> complicated
> >>>>>>> when
> >>>>>>>> there's a problem.
> >>>>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >>>>>>> framework,
> >>>>>>>> at least for simple plugins.
> >>>>>>>> However, I definitely don't think pushing OSGi to plugins would
> be a
> >>>>>>> good
> >>>>>>>> idea : the cost and burden on plugin developers would outweigh the
> >>>>>>> benefits.
> >>>>>>>>
> >>>>>>>> For extensions, and for maven itself, that is a different story
> >>>> though.
> >>>>>>>> Maven and extensions could definitely benefit from OSGi, but this
> >>>> would
> >>>>>>> be
> >>>>>>>> a complete breakage and it would be hard to keep some level of
> >>>>>>>> compatibility.
> >>>>>>>>
> >>>>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> >> mail@laeubi-soft.de
> >>>>>
> >>>>>>> a
> >>>>>>>> écrit :
> >>>>>>>>
> >>>>>>>>> > Guess classrealm is fine for maven, it does not bring much
> >> issues
> >>>>>>>>>
> >>>>>>>>> As long as it works, maybe, maybe even if you write a simple
> maven
> >>>>>>>>> plugin, but for any more complex it is just a complete mess.
> >>>>>>>>>
> >>>>>>>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>>>>>>> complete silence ...
> >>>>>>>>>
> >>>>>>>>> Today I tried to refactor the name of one module of a more
> complex
> >>>>>>>>> maven-plugin (with core extension), now I end up with
> >>>>>>>>>
> >>>>>>>>> org.apache.maven.InternalErrorException: Internal error:
> >>>>>>>>> com.google.inject.ProvisionException: Unable to provision, see
> the
> >>>>>>>>> following errors:
> >>>>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> >>>> bound.
> >>>>>>>>>
> >>>>>>>>> A whole bunch of stack trace but not a little info why the *****
> it
> >>>> is
> >>>>>>>>> not happy. Now I need to add random "exportedArtifact" /
> >>>>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>>>>>>> transitive dependency, also here absolutely no documentation what
> >>>> this
> >>>>>>>>> is supposed to do/work exactly beside some introduction that
> these
> >>>> xml
> >>>>>>>>> tags exits and reading the code... or probably add maven-compat
> >>>>>>>>> anywhere... or change provided to compile scope (even maven is
> >>>> jelling
> >>>>>>>>> at me that's bad and I will be punished soon)... not counting the
> >>>> many
> >>>>>>>>> times where I messed up the realms because I accidentally trying
> to
> >>>> use
> >>>>>>>>> XppDom objects in extensions and plugins and something between
> got
> >>>>>>>>> messed up.
> >>>>>>>>>
> >>>>>>>>> With OSGi i get clear errors for missing requirements, I can
> >> clearly
> >>>>>>>>> share API (or declare I don't want to share it) and can reliable
> >> use
> >>>> it
> >>>>>>>>> without classlaoding problems.
> >>>>>>>>> If one wan't can even implement service filtering that would hide
> >> all
> >>>>>>>>> "illegal implemented API" ... and you can even make sure API is
> >>>>>>>>> (backward) compatible with implementation without waiting for a
> >>>> method
> >>>>>>>>> not found exception or alike.
> >>>>>>>>>
> >>>>>>>>> Beside that I find it often more clear to distinguish between API
> >>>> (that
> >>>>>>>>> is only implemented by the framework) and SPI (that might be
> >>>>>>> implemented
> >>>>>>>>> by extenders). So probably it would be good to have maven-api and
> >>>>>>>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>>>>>>
> >>>>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Guess classrealm is fine for maven, it does not bring much
> issues
> >>>>>>> (less
> >>>>>>>>>> than OSGi or JPMS to be concrete), the real issue is the
> stability
> >>>> of
> >>>>>>>>> the
> >>>>>>>>>> exposed API.
> >>>>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess
> it
> >> is
> >>>>>>>>> mainly
> >>>>>>>>>> a matter of deciding what we do for maven 3.
> >>>>>>>>>> Due to the resources and work needed I assume we can just play
> the
> >>>>>>>>>> status-quo for maven 3.
> >>>>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> >>>>>>> don't
> >>>>>>>>> like
> >>>>>>>>>> much the idea but a compat layer can solve that smoothly for
> maven
> >>>>>>>> = 4
> >>>>>>>>> and
> >>>>>>>>>> limit the work needed, no?
> >>>>>>>>>>
> >>>>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >>>>>>> mail@laeubi-soft.de>
> >>>>>>>>> a
> >>>>>>>>>> écrit :
> >>>>>>>>>>
> >>>>>>>>>>> If you really like to separate API and get out of the
> >>>>>>> ClassRealm-Hell
> >>>>>>>>>>> OSGi would be much more suitable:
> >>>>>>>>>>>
> >>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>>>>>>
> >>>>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to
> Java
> >> 9
> >>>>>>> or
> >>>>>>>>> 11
> >>>>>>>>>>> and
> >>>>>>>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Gary
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> >> tamas@cservenak.net>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
> >> obey
> >>>>>>>>> them
> >>>>>>>>>>> is
> >>>>>>>>>>>>> tricky :D
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has
> >> been
> >>>>>>>>> used in
> >>>>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I
> am
> >>>>>>> really
> >>>>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>>>>>>> - maven progress was really hindered by this, as that meant
> >>>>>>> modifying
> >>>>>>>>>>> (even
> >>>>>>>>>>>>> internal) interfaces without breaking clients was impossible,
> >> so
> >>>>>>> we
> >>>>>>>>> went
> >>>>>>>>>>>>> with tricks, and more tricks and even more tricks that now
> pays
> >>>>>>> back.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The other day we had a question on ML about 4-alpha
> >> compatibility
> >>>>>>>>>>> breakage,
> >>>>>>>>>>>>> and from mail it was clear that the package of the referred
> >> class
> >>>>>>> was
> >>>>>>>>>>>>> having "internal" in it. I mean, developers should really
> take
> >>>>>>> care
> >>>>>>>>> of
> >>>>>>>>>>> what
> >>>>>>>>>>>>> they import.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >>>>>>>>> compilation
> >>>>>>>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> T
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> >>>> kwin@apache.org
> >>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I guess this is the easy part, the tricky question remains:
> Do
> >>>> we
> >>>>>>>>> need
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >>>>>>>>> backwards
> >>>>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This wasn't handled consistently in master till now, e.g.
> the
> >>>>>>>>> classes
> >>>>>>>>>>>>>> generated from
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>>>>>>> My change in
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>>>>>>> was not backwards compatible (removed a method on an
> interface
> >>>>>>> which
> >>>>>>>>>>> may
> >>>>>>>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users
> can
> >>>>>>> grab"
> >>>>>>>>>>>>> sadly,
> >>>>>>>>>>>>>>> and is probably our major source of problems and reason we
> >>>>>>> started
> >>>>>>>>>>>>> Maven
> >>>>>>>>>>>>>> 4
> >>>>>>>>>>>>>>> API.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting
> >> with
> >>>>>>>>> Maven
> >>>>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> >> NOT
> >>>>>>>>>>>>>> ACCESSIBLE
> >>>>>>>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>>>>>>> And done.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> >>>> about
> >>>>>>>>> same
> >>>>>>>>>>>>>> topic
> >>>>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1
> version):
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> HTH
> >>>>>>>>>>>>>>> T
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >>>>>>> kwin@apache.org>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I see now there is already
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
> >> state:
> >>>>>>>>> Only
> >>>>>>>>>>>>>> Maven
> >>>>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In
> effect
> >>>>>>>>>>>>>> everything
> >>>>>>>>>>>>>>>> somehow exposed through class loaders was considered API
> by
> >>>>>>>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> >>>>>>> package
> >>>>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages
> used
> >>>>>>> and
> >>>>>>>>>>>>>> exported
> >>>>>>>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> For example in the context of
> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >>>>>>> evolve
> >>>>>>>>> the
> >>>>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>>>>>>> We already figured out that this particular package
> >> (although
> >>>>>>> not
> >>>>>>>>>>>>>> part
> >>>>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well
> as
> >>>>>>> Maven
> >>>>>>>>>>>>>> Plugin
> >>>>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >>>>>>> compatible.
> >>>>>>>>>>>>>>>>> What about others like
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>>> ?
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>>>>> ?>
> >>>>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
> >>>>>>> Maven
> >>>>>>>>>>>>> Core
> >>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>>>> ).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> >> create
> >>>>>>> new
> >>>>>>>>>>>>> ones
> >>>>>>>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards
> compatible
> >>>>>>> way
> >>>>>>>>>>>>> (but
> >>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>>>>> outside
> >>>>>>>>>>>>> core)
> >>>>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards
> >> compatible
> >>>>>>> way
> >>>>>>>>>>>>> (but
> >>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>>>>> outside
> >>>>>>>>>>>>> core)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> For all three options we somehow need to come up with a
> >> list
> >>>>>>> of
> >>>>>>>>>>>>>>>> classes/interfaces currently being exported through the
> API
> >>>>>>> class
> >>>>>>>>>>>>>> loader,
> >>>>>>>>>>>>>>>> which should be considered private and agree on an
> >>>>>>>>> Annotation/Javadoc
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> that (something like
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> or
> >> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >>>>>>> <
> >>>>>>>>>>>>>>>>
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> ------------------------
> >>>>>>>> Guillaume Nodet
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> ------------------------
> >>>>>>> Guillaume Nodet
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le dim. 20 nov. 2022 à 07:59, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> This does not really answer the question. Extensions are made for
> extending maven(-plugins) (either on the core or the project level) so
> if plugins are only ever getting maven4-api available how will it be
> possible then?
>
Hopefully it will not cause it breaks plugin design as explained.
> Whether or not Extensions are "bad" or not "maven spirit" seems a
> different topic for me.
>
Didnt say any of both, said it was and the way to go to achieve what you
want to do at plugin level against maven spirit.
> Am 19.11.22 um 14:51 schrieb Romain Manni-Bucau:
> > Sounds like some code needing to move to extensions more than some mojo
> > interactions to me to stick to a simple and maven spirit.
> >
> > Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> > That's a good question. Plugins currently don't interact.
> >> > Is that really something we want ?
> >>
> >> At least there are several places where I wish I could "plug" into an
> >> existing plugin, curently for example surefire allows some limited
> >> extension using test-frameworks but this requires special configuration.
> >>
> >> A good example might be the "set-version" plugin, where in the context
> >> of Tycho one needs to also update versions not only in the
> >> pom.xml/dependency part, the current approach is we actually
> >> copy/replicate what set-version does, but this obviously is far from
> >> optimal. The same applies to jar-plugin (where for example BND plugin
> >> requires special setup/configuration) and even the release-plugin
> >> currently would be something where one needs to do special enhancement
> >> that are hard to maintain and manage.
> >>
> >> That's why I previously mentioned in a "we have one isolated mojo"
> >> scenario everything might looks easy and great, but when it comes to
> >> complex setups it gets complicated fast.
> >>
> >> > I'd rather keep things simple if possible. They can use the Session
> >>
> >> I as well but the problem arises if you want to share more than a simple
> >> string or integer. For example currently Tycho has a project-extension
> >> and also a core-extension part and then people can configure different
> >> mojos ... for sure one can put everything in one big fat jar but that's
> >> really hard to manage and configure, so we have split this up into
> >> smaller mojos.
> >>
> >> Still they need to interact (e.g. to not calculate the same stuff over
> >> and over again)... this mostly works as we export some packages that are
> >> kind of "tycho-api" but as one don't write all from scratch there are of
> >> course other dependencies to consider. Even that works, but we always
> >> see issues with classpath incompatibilities that are really hard to
> >> track, e.g. if version of core-extension do not match 100% version of
> >> plugin used in the pom... And i have totally no clue what would happen
> >> if there is another extension also exporting the same dependency ...
> >>
> >>
> >> Am 19.11.22 um 09:37 schrieb Guillaume Nodet:
> >>> Requiring OSGi for anything user facing in maven is a no-go for me.
> >>>
> >>> Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> >>> écrit :
> >>>
> >>>> > Dreaming: but what if not a flag, but some filter(s) for
> >> "capabilities"?
> >>>>
> >>>> OSGi support generic capabilities/requirements model:
> >>>>
> https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
> >>>>
> >>>> Just mentioning it ... for sure we one can re-implement this (again)
> in
> >>>> maven as well, as a prime goal seems not to reuse existing techniques
> >> ;-)
> >>>>
> >>>
> >>> I've been working full time on OSGi for 10 years or so. So I'm quite
> >> aware
> >>> of the benefits... and the costs.
> >>> I don't think we need maven to provide any choice here.
> >>>
> >>>
> >>>>
> >>>> With all this perfect "only m4api" world I'm just wondering how will
> >>>> this work together with extensions (either core or project ones) and
> how
> >>>> is it supposed to allow different plugins to interact?
> >>>>
> >>>
> >>> That's a good question. Plugins currently don't interact. Is that
> really
> >>> something we want ?
> >>> I'd rather keep things simple if possible. They can use the Session
> >>>
> >>>
> >>>> Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
> >>>>> Howdy,
> >>>>>
> >>>>> just to describe a bit what I meant under "reversed flag":
> >>>>>
> >>>>> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as
> >> today.
> >>>>> Plugin classrealm gets (from memory, might be incomplete or wrong):
> >>>>> - m4 API
> >>>>> - m3 "plugin-api"
> >>>>> - javax.inject
> >>>>> - resolver api
> >>>>> - etc as today
> >>>>>
> >>>>> consider that MANY plugins have components, and creating components
> in
> >>>>> MAJORITY of plugins is easy and should remain easy (and offered "out
> of
> >>>> the
> >>>>> box").
> >>>>
> >>>> Sounds good to me.
> >>>
> >>>
> >>>>> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
> >> realm
> >>>>> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox,
> the
> >>>>> plugin can do whatever it wants, but still has access to m4 API (that
> >> is
> >>>>> heaven vs earth when compared to m3 state of affairs).
> >>>>
> >>>> Not sure there's any benefit. If we use a custom package for a few DI
> >>> annotation,
> >>> there will be no conflict, so if there's no maven component defined,
> >>> nothing will be done
> >>> and the plugin is still free to use its own DI if it needs.
> >>>
> >>>
> >>>>> ===
> >>>>>
> >>>>> in future, when we drop m3 support, this could mean:
> >>>>>
> >>>>> false (default)
> >>>>> - m4 API
> >>>>> - javax.inject
> >>>>>
> >>>>> true
> >>>>> -m4 API
> >>>>>
> >>>>> ===
> >>>>>
> >>>>> Dreaming: but what if not a flag, but some filter(s) for
> >> "capabilities"?
> >>>>> values:
> >>>>> - * <- plugin classrealm should have all "capabilities" current Maven
> >>>>> runtime provides
> >>>>> - m4api <- I want maven 4 api ONLY
> >>>>> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
> >>>> drops
> >>>>> m3 backward compat), slf4j logging and would use jsr330 components
> >>>>> "capability"
> >>>>>
> >>>>> But this is getting too wild maybe :)
> >>>>
> >>>
> >>> Simple is good.
> >>>
> >>> Not touching maven 3 plugins or they way they are loaded at all, I'd
> >>> propose:
> >>> * define a few annotations in org.apache.maven.api.di package, we
> >> really
> >>> don't need many, maybe just @Inject, @Bean
> >>> * make sure the plugin classloader does only expose the api to
> maven
> >>> plugins
> >>> * write a simplistic DI framework
> >>> * make sure plugin can use a different DI framework if they need
> >>>
> >>> Guillaume
> >>>
> >>>> T
> >>>>>
> >>>>> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <tamas@cservenak.net
> >
> >>>> wrote:
> >>>>>
> >>>>>> Howdy,
> >>>>>>
> >>>>>> Am -1 on this. We just reached the point to (somewhat) undo the
> "Maven
> >>>>>> downloads the whole world", at least latest plugins by putting Maven
> >> and
> >>>>>> friends in provided scope will not download dozens of versions of
> >>>>>> maven-core and friends... If we do this, at one point we would end
> up
> >>>> with
> >>>>>> plugins downloading dozens of DI container (or their versions), as
> >> even
> >>>> ASF
> >>>>>> plugins would not be in "lockstep".
> >>>>>>
> >>>>>> OTOH, that said, I like the idea of a flag, but I'd reverse it: a
> flag
> >>>>>> that would say maven "I will be in charge of my components"
> (defaults
> >> to
> >>>>>> false, Maven behaves as today). When true, it would mean Mojo wants
> to
> >>>>>> bootstrap some DI/whatever container of its own, and then, for
> plugins
> >>>> like
> >>>>>> these, Maven could even "narrow" the list of exported classes? (like
> >>>>>> javax.inject?)
> >>>>>>
> >>>>>> T
> >>>>>>
> >>>>>> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> >>>> wrote:
> >>>>>>
> >>>>>>> Following up on my previous response, and in a more realistic way
> >> than
> >>>>>>> switching to OSGi, I wonder if we should let maven 4 plugins do
> their
> >>>> own
> >>>>>>> DI injection and only care about the mojos, i.e. not rely on
> >>>> sisu/plexus
> >>>>>>> to
> >>>>>>> create and inject the mojo. Mojos using the v4 api do not need to
> be
> >>>>>>> injected with other components from maven, they should all come
> from
> >>>> the
> >>>>>>> api and should be retrieved using Session.getService(xx), or simply
> >>>> using
> >>>>>>> session's shortcut methods. The injection of Project and Session
> is
> >>>> not
> >>>>>>> controlled by sisu. For the ComponentConfigurator, we could change
> >> the
> >>>>>>> mojo
> >>>>>>> descriptor to have the full configuration class name for mojos that
> >>>>>>> require
> >>>>>>> custom configuration injection, the plugin manager being in charge
> of
> >>>>>>> instantiating this class and using it as a ComponentConfigurator
> >>>> (which is
> >>>>>>> not part yet of the api btw).
> >>>>>>>
> >>>>>>> Complex plugins which rely on plexus/sisu to do some custom
> injection
> >>>>>>> would
> >>>>>>> have to be changed to do their own DI, maybe using a simple Guice
> >>>> setup.
> >>>>>>>
> >>>>>>> If that sounds like too big a change for those plugins, we may be
> >> able
> >>>> to
> >>>>>>> add a flag on the mojo descriptor so that those v4-enabled mojos
> >> would
> >>>>>>> trigger a DI injection on behalf of the plugin. But if we have to
> >>>>>>> implement something like that, I would go for a plain CDI-like api,
> >>>> either
> >>>>>>> using guice or another DI library supporting the javax.inject
> >> package,
> >>>> or
> >>>>>>> rather the jakarta.inject package, as it would be nice to switch to
> >> the
> >>>>>>> jakarta version at the same time. Or maybe even plexus if we
> really
> >>>> need
> >>>>>>> to, but with a limited scope, i.e. no visibility on the maven
> >>>> components,
> >>>>>>> so that plugins are better decoupled from maven-core.
> >>>>>>>
> >>>>>>> Thoughts ?
> >>>>>>>
> >>>>>>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org>
> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> I do agree that debugging the provisioning side is *very*
> >> complicated
> >>>>>>> when
> >>>>>>>> there's a problem.
> >>>>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >>>>>>> framework,
> >>>>>>>> at least for simple plugins.
> >>>>>>>> However, I definitely don't think pushing OSGi to plugins would
> be a
> >>>>>>> good
> >>>>>>>> idea : the cost and burden on plugin developers would outweigh the
> >>>>>>> benefits.
> >>>>>>>>
> >>>>>>>> For extensions, and for maven itself, that is a different story
> >>>> though.
> >>>>>>>> Maven and extensions could definitely benefit from OSGi, but this
> >>>> would
> >>>>>>> be
> >>>>>>>> a complete breakage and it would be hard to keep some level of
> >>>>>>>> compatibility.
> >>>>>>>>
> >>>>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> >> mail@laeubi-soft.de
> >>>>>
> >>>>>>> a
> >>>>>>>> écrit :
> >>>>>>>>
> >>>>>>>>> > Guess classrealm is fine for maven, it does not bring much
> >> issues
> >>>>>>>>>
> >>>>>>>>> As long as it works, maybe, maybe even if you write a simple
> maven
> >>>>>>>>> plugin, but for any more complex it is just a complete mess.
> >>>>>>>>>
> >>>>>>>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>>>>>>> complete silence ...
> >>>>>>>>>
> >>>>>>>>> Today I tried to refactor the name of one module of a more
> complex
> >>>>>>>>> maven-plugin (with core extension), now I end up with
> >>>>>>>>>
> >>>>>>>>> org.apache.maven.InternalErrorException: Internal error:
> >>>>>>>>> com.google.inject.ProvisionException: Unable to provision, see
> the
> >>>>>>>>> following errors:
> >>>>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> >>>> bound.
> >>>>>>>>>
> >>>>>>>>> A whole bunch of stack trace but not a little info why the *****
> it
> >>>> is
> >>>>>>>>> not happy. Now I need to add random "exportedArtifact" /
> >>>>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>>>>>>> transitive dependency, also here absolutely no documentation what
> >>>> this
> >>>>>>>>> is supposed to do/work exactly beside some introduction that
> these
> >>>> xml
> >>>>>>>>> tags exits and reading the code... or probably add maven-compat
> >>>>>>>>> anywhere... or change provided to compile scope (even maven is
> >>>> jelling
> >>>>>>>>> at me that's bad and I will be punished soon)... not counting the
> >>>> many
> >>>>>>>>> times where I messed up the realms because I accidentally trying
> to
> >>>> use
> >>>>>>>>> XppDom objects in extensions and plugins and something between
> got
> >>>>>>>>> messed up.
> >>>>>>>>>
> >>>>>>>>> With OSGi i get clear errors for missing requirements, I can
> >> clearly
> >>>>>>>>> share API (or declare I don't want to share it) and can reliable
> >> use
> >>>> it
> >>>>>>>>> without classlaoding problems.
> >>>>>>>>> If one wan't can even implement service filtering that would hide
> >> all
> >>>>>>>>> "illegal implemented API" ... and you can even make sure API is
> >>>>>>>>> (backward) compatible with implementation without waiting for a
> >>>> method
> >>>>>>>>> not found exception or alike.
> >>>>>>>>>
> >>>>>>>>> Beside that I find it often more clear to distinguish between API
> >>>> (that
> >>>>>>>>> is only implemented by the framework) and SPI (that might be
> >>>>>>> implemented
> >>>>>>>>> by extenders). So probably it would be good to have maven-api and
> >>>>>>>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>>>>>>
> >>>>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Guess classrealm is fine for maven, it does not bring much
> issues
> >>>>>>> (less
> >>>>>>>>>> than OSGi or JPMS to be concrete), the real issue is the
> stability
> >>>> of
> >>>>>>>>> the
> >>>>>>>>>> exposed API.
> >>>>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess
> it
> >> is
> >>>>>>>>> mainly
> >>>>>>>>>> a matter of deciding what we do for maven 3.
> >>>>>>>>>> Due to the resources and work needed I assume we can just play
> the
> >>>>>>>>>> status-quo for maven 3.
> >>>>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> >>>>>>> don't
> >>>>>>>>> like
> >>>>>>>>>> much the idea but a compat layer can solve that smoothly for
> maven
> >>>>>>>> = 4
> >>>>>>>>> and
> >>>>>>>>>> limit the work needed, no?
> >>>>>>>>>>
> >>>>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >>>>>>> mail@laeubi-soft.de>
> >>>>>>>>> a
> >>>>>>>>>> écrit :
> >>>>>>>>>>
> >>>>>>>>>>> If you really like to separate API and get out of the
> >>>>>>> ClassRealm-Hell
> >>>>>>>>>>> OSGi would be much more suitable:
> >>>>>>>>>>>
> >>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>>>>>>
> >>>>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to
> Java
> >> 9
> >>>>>>> or
> >>>>>>>>> 11
> >>>>>>>>>>> and
> >>>>>>>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Gary
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> >> tamas@cservenak.net>
> >>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
> >> obey
> >>>>>>>>> them
> >>>>>>>>>>> is
> >>>>>>>>>>>>> tricky :D
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has
> >> been
> >>>>>>>>> used in
> >>>>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I
> am
> >>>>>>> really
> >>>>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>>>>>>> - maven progress was really hindered by this, as that meant
> >>>>>>> modifying
> >>>>>>>>>>> (even
> >>>>>>>>>>>>> internal) interfaces without breaking clients was impossible,
> >> so
> >>>>>>> we
> >>>>>>>>> went
> >>>>>>>>>>>>> with tricks, and more tricks and even more tricks that now
> pays
> >>>>>>> back.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The other day we had a question on ML about 4-alpha
> >> compatibility
> >>>>>>>>>>> breakage,
> >>>>>>>>>>>>> and from mail it was clear that the package of the referred
> >> class
> >>>>>>> was
> >>>>>>>>>>>>> having "internal" in it. I mean, developers should really
> take
> >>>>>>> care
> >>>>>>>>> of
> >>>>>>>>>>> what
> >>>>>>>>>>>>> they import.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >>>>>>>>> compilation
> >>>>>>>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> T
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> >>>> kwin@apache.org
> >>>>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I guess this is the easy part, the tricky question remains:
> Do
> >>>> we
> >>>>>>>>> need
> >>>>>>>>>>> to
> >>>>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >>>>>>>>> backwards
> >>>>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This wasn't handled consistently in master till now, e.g.
> the
> >>>>>>>>> classes
> >>>>>>>>>>>>>> generated from
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>>>>>>> My change in
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>>>>>>> was not backwards compatible (removed a method on an
> interface
> >>>>>>> which
> >>>>>>>>>>> may
> >>>>>>>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users
> can
> >>>>>>> grab"
> >>>>>>>>>>>>> sadly,
> >>>>>>>>>>>>>>> and is probably our major source of problems and reason we
> >>>>>>> started
> >>>>>>>>>>>>> Maven
> >>>>>>>>>>>>>> 4
> >>>>>>>>>>>>>>> API.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting
> >> with
> >>>>>>>>> Maven
> >>>>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> >> NOT
> >>>>>>>>>>>>>> ACCESSIBLE
> >>>>>>>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>>>>>>> And done.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> >>>> about
> >>>>>>>>> same
> >>>>>>>>>>>>>> topic
> >>>>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1
> version):
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> HTH
> >>>>>>>>>>>>>>> T
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >>>>>>> kwin@apache.org>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I see now there is already
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
> >> state:
> >>>>>>>>> Only
> >>>>>>>>>>>>>> Maven
> >>>>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In
> effect
> >>>>>>>>>>>>>> everything
> >>>>>>>>>>>>>>>> somehow exposed through class loaders was considered API
> by
> >>>>>>>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> >>>>>>> package
> >>>>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages
> used
> >>>>>>> and
> >>>>>>>>>>>>>> exported
> >>>>>>>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> For example in the context of
> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >>>>>>> evolve
> >>>>>>>>> the
> >>>>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>>>>>>> We already figured out that this particular package
> >> (although
> >>>>>>> not
> >>>>>>>>>>>>>> part
> >>>>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well
> as
> >>>>>>> Maven
> >>>>>>>>>>>>>> Plugin
> >>>>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >>>>>>> compatible.
> >>>>>>>>>>>>>>>>> What about others like
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>>> ?
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>>>>> ?>
> >>>>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
> >>>>>>> Maven
> >>>>>>>>>>>>> Core
> >>>>>>>>>>>>>> but
> >>>>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>>>> ).
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> >> create
> >>>>>>> new
> >>>>>>>>>>>>> ones
> >>>>>>>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards
> compatible
> >>>>>>> way
> >>>>>>>>>>>>> (but
> >>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>>>>> outside
> >>>>>>>>>>>>> core)
> >>>>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards
> >> compatible
> >>>>>>> way
> >>>>>>>>>>>>> (but
> >>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>>>>> outside
> >>>>>>>>>>>>> core)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> For all three options we somehow need to come up with a
> >> list
> >>>>>>> of
> >>>>>>>>>>>>>>>> classes/interfaces currently being exported through the
> API
> >>>>>>> class
> >>>>>>>>>>>>>> loader,
> >>>>>>>>>>>>>>>> which should be considered private and agree on an
> >>>>>>>>> Annotation/Javadoc
> >>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> that (something like
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> or
> >> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >>>>>>> <
> >>>>>>>>>>>>>>>>
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> ------------------------
> >>>>>>>> Guillaume Nodet
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> ------------------------
> >>>>>>> Guillaume Nodet
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
This does not really answer the question. Extensions are made for
extending maven(-plugins) (either on the core or the project level) so
if plugins are only ever getting maven4-api available how will it be
possible then?
Whether or not Extensions are "bad" or not "maven spirit" seems a
different topic for me.
Am 19.11.22 um 14:51 schrieb Romain Manni-Bucau:
> Sounds like some code needing to move to extensions more than some mojo
> interactions to me to stick to a simple and maven spirit.
>
> Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> > That's a good question. Plugins currently don't interact.
>> > Is that really something we want ?
>>
>> At least there are several places where I wish I could "plug" into an
>> existing plugin, curently for example surefire allows some limited
>> extension using test-frameworks but this requires special configuration.
>>
>> A good example might be the "set-version" plugin, where in the context
>> of Tycho one needs to also update versions not only in the
>> pom.xml/dependency part, the current approach is we actually
>> copy/replicate what set-version does, but this obviously is far from
>> optimal. The same applies to jar-plugin (where for example BND plugin
>> requires special setup/configuration) and even the release-plugin
>> currently would be something where one needs to do special enhancement
>> that are hard to maintain and manage.
>>
>> That's why I previously mentioned in a "we have one isolated mojo"
>> scenario everything might looks easy and great, but when it comes to
>> complex setups it gets complicated fast.
>>
>> > I'd rather keep things simple if possible. They can use the Session
>>
>> I as well but the problem arises if you want to share more than a simple
>> string or integer. For example currently Tycho has a project-extension
>> and also a core-extension part and then people can configure different
>> mojos ... for sure one can put everything in one big fat jar but that's
>> really hard to manage and configure, so we have split this up into
>> smaller mojos.
>>
>> Still they need to interact (e.g. to not calculate the same stuff over
>> and over again)... this mostly works as we export some packages that are
>> kind of "tycho-api" but as one don't write all from scratch there are of
>> course other dependencies to consider. Even that works, but we always
>> see issues with classpath incompatibilities that are really hard to
>> track, e.g. if version of core-extension do not match 100% version of
>> plugin used in the pom... And i have totally no clue what would happen
>> if there is another extension also exporting the same dependency ...
>>
>>
>> Am 19.11.22 um 09:37 schrieb Guillaume Nodet:
>>> Requiring OSGi for anything user facing in maven is a no-go for me.
>>>
>>> Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de> a
>>> écrit :
>>>
>>>> > Dreaming: but what if not a flag, but some filter(s) for
>> "capabilities"?
>>>>
>>>> OSGi support generic capabilities/requirements model:
>>>> https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
>>>>
>>>> Just mentioning it ... for sure we one can re-implement this (again) in
>>>> maven as well, as a prime goal seems not to reuse existing techniques
>> ;-)
>>>>
>>>
>>> I've been working full time on OSGi for 10 years or so. So I'm quite
>> aware
>>> of the benefits... and the costs.
>>> I don't think we need maven to provide any choice here.
>>>
>>>
>>>>
>>>> With all this perfect "only m4api" world I'm just wondering how will
>>>> this work together with extensions (either core or project ones) and how
>>>> is it supposed to allow different plugins to interact?
>>>>
>>>
>>> That's a good question. Plugins currently don't interact. Is that really
>>> something we want ?
>>> I'd rather keep things simple if possible. They can use the Session
>>>
>>>
>>>> Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
>>>>> Howdy,
>>>>>
>>>>> just to describe a bit what I meant under "reversed flag":
>>>>>
>>>>> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as
>> today.
>>>>> Plugin classrealm gets (from memory, might be incomplete or wrong):
>>>>> - m4 API
>>>>> - m3 "plugin-api"
>>>>> - javax.inject
>>>>> - resolver api
>>>>> - etc as today
>>>>>
>>>>> consider that MANY plugins have components, and creating components in
>>>>> MAJORITY of plugins is easy and should remain easy (and offered "out of
>>>> the
>>>>> box").
>>>>
>>>> Sounds good to me.
>>>
>>>
>>>>> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
>> realm
>>>>> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
>>>>> plugin can do whatever it wants, but still has access to m4 API (that
>> is
>>>>> heaven vs earth when compared to m3 state of affairs).
>>>>
>>>> Not sure there's any benefit. If we use a custom package for a few DI
>>> annotation,
>>> there will be no conflict, so if there's no maven component defined,
>>> nothing will be done
>>> and the plugin is still free to use its own DI if it needs.
>>>
>>>
>>>>> ===
>>>>>
>>>>> in future, when we drop m3 support, this could mean:
>>>>>
>>>>> false (default)
>>>>> - m4 API
>>>>> - javax.inject
>>>>>
>>>>> true
>>>>> -m4 API
>>>>>
>>>>> ===
>>>>>
>>>>> Dreaming: but what if not a flag, but some filter(s) for
>> "capabilities"?
>>>>> values:
>>>>> - * <- plugin classrealm should have all "capabilities" current Maven
>>>>> runtime provides
>>>>> - m4api <- I want maven 4 api ONLY
>>>>> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
>>>> drops
>>>>> m3 backward compat), slf4j logging and would use jsr330 components
>>>>> "capability"
>>>>>
>>>>> But this is getting too wild maybe :)
>>>>
>>>
>>> Simple is good.
>>>
>>> Not touching maven 3 plugins or they way they are loaded at all, I'd
>>> propose:
>>> * define a few annotations in org.apache.maven.api.di package, we
>> really
>>> don't need many, maybe just @Inject, @Bean
>>> * make sure the plugin classloader does only expose the api to maven
>>> plugins
>>> * write a simplistic DI framework
>>> * make sure plugin can use a different DI framework if they need
>>>
>>> Guillaume
>>>
>>>> T
>>>>>
>>>>> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
>>>> wrote:
>>>>>
>>>>>> Howdy,
>>>>>>
>>>>>> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
>>>>>> downloads the whole world", at least latest plugins by putting Maven
>> and
>>>>>> friends in provided scope will not download dozens of versions of
>>>>>> maven-core and friends... If we do this, at one point we would end up
>>>> with
>>>>>> plugins downloading dozens of DI container (or their versions), as
>> even
>>>> ASF
>>>>>> plugins would not be in "lockstep".
>>>>>>
>>>>>> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
>>>>>> that would say maven "I will be in charge of my components" (defaults
>> to
>>>>>> false, Maven behaves as today). When true, it would mean Mojo wants to
>>>>>> bootstrap some DI/whatever container of its own, and then, for plugins
>>>> like
>>>>>> these, Maven could even "narrow" the list of exported classes? (like
>>>>>> javax.inject?)
>>>>>>
>>>>>> T
>>>>>>
>>>>>> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>> Following up on my previous response, and in a more realistic way
>> than
>>>>>>> switching to OSGi, I wonder if we should let maven 4 plugins do their
>>>> own
>>>>>>> DI injection and only care about the mojos, i.e. not rely on
>>>> sisu/plexus
>>>>>>> to
>>>>>>> create and inject the mojo. Mojos using the v4 api do not need to be
>>>>>>> injected with other components from maven, they should all come from
>>>> the
>>>>>>> api and should be retrieved using Session.getService(xx), or simply
>>>> using
>>>>>>> session's shortcut methods. The injection of Project and Session is
>>>> not
>>>>>>> controlled by sisu. For the ComponentConfigurator, we could change
>> the
>>>>>>> mojo
>>>>>>> descriptor to have the full configuration class name for mojos that
>>>>>>> require
>>>>>>> custom configuration injection, the plugin manager being in charge of
>>>>>>> instantiating this class and using it as a ComponentConfigurator
>>>> (which is
>>>>>>> not part yet of the api btw).
>>>>>>>
>>>>>>> Complex plugins which rely on plexus/sisu to do some custom injection
>>>>>>> would
>>>>>>> have to be changed to do their own DI, maybe using a simple Guice
>>>> setup.
>>>>>>>
>>>>>>> If that sounds like too big a change for those plugins, we may be
>> able
>>>> to
>>>>>>> add a flag on the mojo descriptor so that those v4-enabled mojos
>> would
>>>>>>> trigger a DI injection on behalf of the plugin. But if we have to
>>>>>>> implement something like that, I would go for a plain CDI-like api,
>>>> either
>>>>>>> using guice or another DI library supporting the javax.inject
>> package,
>>>> or
>>>>>>> rather the jakarta.inject package, as it would be nice to switch to
>> the
>>>>>>> jakarta version at the same time. Or maybe even plexus if we really
>>>> need
>>>>>>> to, but with a limited scope, i.e. no visibility on the maven
>>>> components,
>>>>>>> so that plugins are better decoupled from maven-core.
>>>>>>>
>>>>>>> Thoughts ?
>>>>>>>
>>>>>>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> I do agree that debugging the provisioning side is *very*
>> complicated
>>>>>>> when
>>>>>>>> there's a problem.
>>>>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
>>>>>>> framework,
>>>>>>>> at least for simple plugins.
>>>>>>>> However, I definitely don't think pushing OSGi to plugins would be a
>>>>>>> good
>>>>>>>> idea : the cost and burden on plugin developers would outweigh the
>>>>>>> benefits.
>>>>>>>>
>>>>>>>> For extensions, and for maven itself, that is a different story
>>>> though.
>>>>>>>> Maven and extensions could definitely benefit from OSGi, but this
>>>> would
>>>>>>> be
>>>>>>>> a complete breakage and it would be hard to keep some level of
>>>>>>>> compatibility.
>>>>>>>>
>>>>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
>> mail@laeubi-soft.de
>>>>>
>>>>>>> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> > Guess classrealm is fine for maven, it does not bring much
>> issues
>>>>>>>>>
>>>>>>>>> As long as it works, maybe, maybe even if you write a simple maven
>>>>>>>>> plugin, but for any more complex it is just a complete mess.
>>>>>>>>>
>>>>>>>>> Last time I asked on the mailing list how to debug that stuff ...
>>>>>>>>> complete silence ...
>>>>>>>>>
>>>>>>>>> Today I tried to refactor the name of one module of a more complex
>>>>>>>>> maven-plugin (with core extension), now I end up with
>>>>>>>>>
>>>>>>>>> org.apache.maven.InternalErrorException: Internal error:
>>>>>>>>> com.google.inject.ProvisionException: Unable to provision, see the
>>>>>>>>> following errors:
>>>>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
>>>> bound.
>>>>>>>>>
>>>>>>>>> A whole bunch of stack trace but not a little info why the ***** it
>>>> is
>>>>>>>>> not happy. Now I need to add random "exportedArtifact" /
>>>>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
>>>>>>>>> transitive dependency, also here absolutely no documentation what
>>>> this
>>>>>>>>> is supposed to do/work exactly beside some introduction that these
>>>> xml
>>>>>>>>> tags exits and reading the code... or probably add maven-compat
>>>>>>>>> anywhere... or change provided to compile scope (even maven is
>>>> jelling
>>>>>>>>> at me that's bad and I will be punished soon)... not counting the
>>>> many
>>>>>>>>> times where I messed up the realms because I accidentally trying to
>>>> use
>>>>>>>>> XppDom objects in extensions and plugins and something between got
>>>>>>>>> messed up.
>>>>>>>>>
>>>>>>>>> With OSGi i get clear errors for missing requirements, I can
>> clearly
>>>>>>>>> share API (or declare I don't want to share it) and can reliable
>> use
>>>> it
>>>>>>>>> without classlaoding problems.
>>>>>>>>> If one wan't can even implement service filtering that would hide
>> all
>>>>>>>>> "illegal implemented API" ... and you can even make sure API is
>>>>>>>>> (backward) compatible with implementation without waiting for a
>>>> method
>>>>>>>>> not found exception or alike.
>>>>>>>>>
>>>>>>>>> Beside that I find it often more clear to distinguish between API
>>>> (that
>>>>>>>>> is only implemented by the framework) and SPI (that might be
>>>>>>> implemented
>>>>>>>>> by extenders). So probably it would be good to have maven-api and
>>>>>>>>> maven-spi (instead of "maven-core") to make this clear.
>>>>>>>>>
>>>>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Guess classrealm is fine for maven, it does not bring much issues
>>>>>>> (less
>>>>>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
>>>> of
>>>>>>>>> the
>>>>>>>>>> exposed API.
>>>>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it
>> is
>>>>>>>>> mainly
>>>>>>>>>> a matter of deciding what we do for maven 3.
>>>>>>>>>> Due to the resources and work needed I assume we can just play the
>>>>>>>>>> status-quo for maven 3.
>>>>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
>>>>>>> don't
>>>>>>>>> like
>>>>>>>>>> much the idea but a compat layer can solve that smoothly for maven
>>>>>>>> = 4
>>>>>>>>> and
>>>>>>>>>> limit the work needed, no?
>>>>>>>>>>
>>>>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>>>>>>> mail@laeubi-soft.de>
>>>>>>>>> a
>>>>>>>>>> écrit :
>>>>>>>>>>
>>>>>>>>>>> If you really like to separate API and get out of the
>>>>>>> ClassRealm-Hell
>>>>>>>>>>> OSGi would be much more suitable:
>>>>>>>>>>>
>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>>>>>>>>
>>>>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java
>> 9
>>>>>>> or
>>>>>>>>> 11
>>>>>>>>>>> and
>>>>>>>>>>>> adopt JPMS to better define its public APIs.
>>>>>>>>>>>>
>>>>>>>>>>>> Gary
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
>> tamas@cservenak.net>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
>> obey
>>>>>>>>> them
>>>>>>>>>>> is
>>>>>>>>>>>>> tricky :D
>>>>>>>>>>>>>
>>>>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has
>> been
>>>>>>>>> used in
>>>>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>>>>>>>>
>>>>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
>>>>>>> really
>>>>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ultimately, this was the whole reason for API:
>>>>>>>>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>>>>>>>>> - maven progress was really hindered by this, as that meant
>>>>>>> modifying
>>>>>>>>>>> (even
>>>>>>>>>>>>> internal) interfaces without breaking clients was impossible,
>> so
>>>>>>> we
>>>>>>>>> went
>>>>>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
>>>>>>> back.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The other day we had a question on ML about 4-alpha
>> compatibility
>>>>>>>>>>> breakage,
>>>>>>>>>>>>> and from mail it was clear that the package of the referred
>> class
>>>>>>> was
>>>>>>>>>>>>> having "internal" in it. I mean, developers should really take
>>>>>>> care
>>>>>>>>> of
>>>>>>>>>>> what
>>>>>>>>>>>>> they import.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
>>>>>>>>> compilation
>>>>>>>>>>>>> against "encapsulated" internal classes....
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>>>>>>>>
>>>>>>>>>>>>> T
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
>>>> kwin@apache.org
>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
>>>> we
>>>>>>>>> need
>>>>>>>>>>> to
>>>>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>>>>>>>>> backwards
>>>>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
>>>>>>>>> classes
>>>>>>>>>>>>>> generated from
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>>>>>>>>> My change in
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>>>>>>>>> was not backwards compatible (removed a method on an interface
>>>>>>> which
>>>>>>>>>>> may
>>>>>>>>>>>>>> have been implemented by extensions...)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
>>>>>>> grab"
>>>>>>>>>>>>> sadly,
>>>>>>>>>>>>>>> and is probably our major source of problems and reason we
>>>>>>> started
>>>>>>>>>>>>> Maven
>>>>>>>>>>>>>> 4
>>>>>>>>>>>>>>> API.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting
>> with
>>>>>>>>> Maven
>>>>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
>> NOT
>>>>>>>>>>>>>> ACCESSIBLE
>>>>>>>>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>>>>>>>>> And done.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
>>>> about
>>>>>>>>> same
>>>>>>>>>>>>>> topic
>>>>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> HTH
>>>>>>>>>>>>>>> T
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>>>>>>> kwin@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I see now there is already
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
>> state:
>>>>>>>>> Only
>>>>>>>>>>>>>> Maven
>>>>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>>>>>>>>> everything
>>>>>>>>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>>>>>>>>> plugin/extension developers.
>>>>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
>>>>>>> package
>>>>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
>>>>>>> and
>>>>>>>>>>>>>> exported
>>>>>>>>>>>>>>>> in Maven 3?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For example in the context of
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>>>>>>> evolve
>>>>>>>>> the
>>>>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>>>>>>>>> We already figured out that this particular package
>> (although
>>>>>>> not
>>>>>>>>>>>>>> part
>>>>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
>>>>>>> Maven
>>>>>>>>>>>>>> Plugin
>>>>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
>>>>>>> compatible.
>>>>>>>>>>>>>>>>> What about others like
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>>>>>> ?>
>>>>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
>>>>>>> Maven
>>>>>>>>>>>>> Core
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and
>> create
>>>>>>> new
>>>>>>>>>>>>> ones
>>>>>>>>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
>>>>>>> way
>>>>>>>>>>>>> (but
>>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>>>>>> outside
>>>>>>>>>>>>> core)
>>>>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards
>> compatible
>>>>>>> way
>>>>>>>>>>>>> (but
>>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>>>>>> outside
>>>>>>>>>>>>> core)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For all three options we somehow need to come up with a
>> list
>>>>>>> of
>>>>>>>>>>>>>>>> classes/interfaces currently being exported through the API
>>>>>>> class
>>>>>>>>>>>>>> loader,
>>>>>>>>>>>>>>>> which should be considered private and agree on an
>>>>>>>>> Annotation/Javadoc
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> that (something like
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> or
>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>>>>>>> <
>>>>>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Sounds like some code needing to move to extensions more than some mojo
interactions to me to stick to a simple and maven spirit.
Le sam. 19 nov. 2022 à 13:14, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> > That's a good question. Plugins currently don't interact.
> > Is that really something we want ?
>
> At least there are several places where I wish I could "plug" into an
> existing plugin, curently for example surefire allows some limited
> extension using test-frameworks but this requires special configuration.
>
> A good example might be the "set-version" plugin, where in the context
> of Tycho one needs to also update versions not only in the
> pom.xml/dependency part, the current approach is we actually
> copy/replicate what set-version does, but this obviously is far from
> optimal. The same applies to jar-plugin (where for example BND plugin
> requires special setup/configuration) and even the release-plugin
> currently would be something where one needs to do special enhancement
> that are hard to maintain and manage.
>
> That's why I previously mentioned in a "we have one isolated mojo"
> scenario everything might looks easy and great, but when it comes to
> complex setups it gets complicated fast.
>
> > I'd rather keep things simple if possible. They can use the Session
>
> I as well but the problem arises if you want to share more than a simple
> string or integer. For example currently Tycho has a project-extension
> and also a core-extension part and then people can configure different
> mojos ... for sure one can put everything in one big fat jar but that's
> really hard to manage and configure, so we have split this up into
> smaller mojos.
>
> Still they need to interact (e.g. to not calculate the same stuff over
> and over again)... this mostly works as we export some packages that are
> kind of "tycho-api" but as one don't write all from scratch there are of
> course other dependencies to consider. Even that works, but we always
> see issues with classpath incompatibilities that are really hard to
> track, e.g. if version of core-extension do not match 100% version of
> plugin used in the pom... And i have totally no clue what would happen
> if there is another extension also exporting the same dependency ...
>
>
> Am 19.11.22 um 09:37 schrieb Guillaume Nodet:
> > Requiring OSGi for anything user facing in maven is a no-go for me.
> >
> > Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> > Dreaming: but what if not a flag, but some filter(s) for
> "capabilities"?
> >>
> >> OSGi support generic capabilities/requirements model:
> >> https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
> >>
> >> Just mentioning it ... for sure we one can re-implement this (again) in
> >> maven as well, as a prime goal seems not to reuse existing techniques
> ;-)
> >>
> >
> > I've been working full time on OSGi for 10 years or so. So I'm quite
> aware
> > of the benefits... and the costs.
> > I don't think we need maven to provide any choice here.
> >
> >
> >>
> >> With all this perfect "only m4api" world I'm just wondering how will
> >> this work together with extensions (either core or project ones) and how
> >> is it supposed to allow different plugins to interact?
> >>
> >
> > That's a good question. Plugins currently don't interact. Is that really
> > something we want ?
> > I'd rather keep things simple if possible. They can use the Session
> >
> >
> >> Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
> >>> Howdy,
> >>>
> >>> just to describe a bit what I meant under "reversed flag":
> >>>
> >>> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as
> today.
> >>> Plugin classrealm gets (from memory, might be incomplete or wrong):
> >>> - m4 API
> >>> - m3 "plugin-api"
> >>> - javax.inject
> >>> - resolver api
> >>> - etc as today
> >>>
> >>> consider that MANY plugins have components, and creating components in
> >>> MAJORITY of plugins is easy and should remain easy (and offered "out of
> >> the
> >>> box").
> >>
> >> Sounds good to me.
> >
> >
> >>> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
> realm
> >>> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> >>> plugin can do whatever it wants, but still has access to m4 API (that
> is
> >>> heaven vs earth when compared to m3 state of affairs).
> >>
> >> Not sure there's any benefit. If we use a custom package for a few DI
> > annotation,
> > there will be no conflict, so if there's no maven component defined,
> > nothing will be done
> > and the plugin is still free to use its own DI if it needs.
> >
> >
> >>> ===
> >>>
> >>> in future, when we drop m3 support, this could mean:
> >>>
> >>> false (default)
> >>> - m4 API
> >>> - javax.inject
> >>>
> >>> true
> >>> -m4 API
> >>>
> >>> ===
> >>>
> >>> Dreaming: but what if not a flag, but some filter(s) for
> "capabilities"?
> >>> values:
> >>> - * <- plugin classrealm should have all "capabilities" current Maven
> >>> runtime provides
> >>> - m4api <- I want maven 4 api ONLY
> >>> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
> >> drops
> >>> m3 backward compat), slf4j logging and would use jsr330 components
> >>> "capability"
> >>>
> >>> But this is getting too wild maybe :)
> >>
> >
> > Simple is good.
> >
> > Not touching maven 3 plugins or they way they are loaded at all, I'd
> > propose:
> > * define a few annotations in org.apache.maven.api.di package, we
> really
> > don't need many, maybe just @Inject, @Bean
> > * make sure the plugin classloader does only expose the api to maven
> > plugins
> > * write a simplistic DI framework
> > * make sure plugin can use a different DI framework if they need
> >
> > Guillaume
> >
> >> T
> >>>
> >>> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
> >> wrote:
> >>>
> >>>> Howdy,
> >>>>
> >>>> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> >>>> downloads the whole world", at least latest plugins by putting Maven
> and
> >>>> friends in provided scope will not download dozens of versions of
> >>>> maven-core and friends... If we do this, at one point we would end up
> >> with
> >>>> plugins downloading dozens of DI container (or their versions), as
> even
> >> ASF
> >>>> plugins would not be in "lockstep".
> >>>>
> >>>> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> >>>> that would say maven "I will be in charge of my components" (defaults
> to
> >>>> false, Maven behaves as today). When true, it would mean Mojo wants to
> >>>> bootstrap some DI/whatever container of its own, and then, for plugins
> >> like
> >>>> these, Maven could even "narrow" the list of exported classes? (like
> >>>> javax.inject?)
> >>>>
> >>>> T
> >>>>
> >>>> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> >> wrote:
> >>>>
> >>>>> Following up on my previous response, and in a more realistic way
> than
> >>>>> switching to OSGi, I wonder if we should let maven 4 plugins do their
> >> own
> >>>>> DI injection and only care about the mojos, i.e. not rely on
> >> sisu/plexus
> >>>>> to
> >>>>> create and inject the mojo. Mojos using the v4 api do not need to be
> >>>>> injected with other components from maven, they should all come from
> >> the
> >>>>> api and should be retrieved using Session.getService(xx), or simply
> >> using
> >>>>> session's shortcut methods. The injection of Project and Session is
> >> not
> >>>>> controlled by sisu. For the ComponentConfigurator, we could change
> the
> >>>>> mojo
> >>>>> descriptor to have the full configuration class name for mojos that
> >>>>> require
> >>>>> custom configuration injection, the plugin manager being in charge of
> >>>>> instantiating this class and using it as a ComponentConfigurator
> >> (which is
> >>>>> not part yet of the api btw).
> >>>>>
> >>>>> Complex plugins which rely on plexus/sisu to do some custom injection
> >>>>> would
> >>>>> have to be changed to do their own DI, maybe using a simple Guice
> >> setup.
> >>>>>
> >>>>> If that sounds like too big a change for those plugins, we may be
> able
> >> to
> >>>>> add a flag on the mojo descriptor so that those v4-enabled mojos
> would
> >>>>> trigger a DI injection on behalf of the plugin. But if we have to
> >>>>> implement something like that, I would go for a plain CDI-like api,
> >> either
> >>>>> using guice or another DI library supporting the javax.inject
> package,
> >> or
> >>>>> rather the jakarta.inject package, as it would be nice to switch to
> the
> >>>>> jakarta version at the same time. Or maybe even plexus if we really
> >> need
> >>>>> to, but with a limited scope, i.e. no visibility on the maven
> >> components,
> >>>>> so that plugins are better decoupled from maven-core.
> >>>>>
> >>>>> Thoughts ?
> >>>>>
> >>>>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> >>>>> écrit :
> >>>>>
> >>>>>> I do agree that debugging the provisioning side is *very*
> complicated
> >>>>> when
> >>>>>> there's a problem.
> >>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >>>>> framework,
> >>>>>> at least for simple plugins.
> >>>>>> However, I definitely don't think pushing OSGi to plugins would be a
> >>>>> good
> >>>>>> idea : the cost and burden on plugin developers would outweigh the
> >>>>> benefits.
> >>>>>>
> >>>>>> For extensions, and for maven itself, that is a different story
> >> though.
> >>>>>> Maven and extensions could definitely benefit from OSGi, but this
> >> would
> >>>>> be
> >>>>>> a complete breakage and it would be hard to keep some level of
> >>>>>> compatibility.
> >>>>>>
> >>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> mail@laeubi-soft.de
> >>>
> >>>>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>> > Guess classrealm is fine for maven, it does not bring much
> issues
> >>>>>>>
> >>>>>>> As long as it works, maybe, maybe even if you write a simple maven
> >>>>>>> plugin, but for any more complex it is just a complete mess.
> >>>>>>>
> >>>>>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>>>>> complete silence ...
> >>>>>>>
> >>>>>>> Today I tried to refactor the name of one module of a more complex
> >>>>>>> maven-plugin (with core extension), now I end up with
> >>>>>>>
> >>>>>>> org.apache.maven.InternalErrorException: Internal error:
> >>>>>>> com.google.inject.ProvisionException: Unable to provision, see the
> >>>>>>> following errors:
> >>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> >> bound.
> >>>>>>>
> >>>>>>> A whole bunch of stack trace but not a little info why the ***** it
> >> is
> >>>>>>> not happy. Now I need to add random "exportedArtifact" /
> >>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>>>>> transitive dependency, also here absolutely no documentation what
> >> this
> >>>>>>> is supposed to do/work exactly beside some introduction that these
> >> xml
> >>>>>>> tags exits and reading the code... or probably add maven-compat
> >>>>>>> anywhere... or change provided to compile scope (even maven is
> >> jelling
> >>>>>>> at me that's bad and I will be punished soon)... not counting the
> >> many
> >>>>>>> times where I messed up the realms because I accidentally trying to
> >> use
> >>>>>>> XppDom objects in extensions and plugins and something between got
> >>>>>>> messed up.
> >>>>>>>
> >>>>>>> With OSGi i get clear errors for missing requirements, I can
> clearly
> >>>>>>> share API (or declare I don't want to share it) and can reliable
> use
> >> it
> >>>>>>> without classlaoding problems.
> >>>>>>> If one wan't can even implement service filtering that would hide
> all
> >>>>>>> "illegal implemented API" ... and you can even make sure API is
> >>>>>>> (backward) compatible with implementation without waiting for a
> >> method
> >>>>>>> not found exception or alike.
> >>>>>>>
> >>>>>>> Beside that I find it often more clear to distinguish between API
> >> (that
> >>>>>>> is only implemented by the framework) and SPI (that might be
> >>>>> implemented
> >>>>>>> by extenders). So probably it would be good to have maven-api and
> >>>>>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>>>>
> >>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Guess classrealm is fine for maven, it does not bring much issues
> >>>>> (less
> >>>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
> >> of
> >>>>>>> the
> >>>>>>>> exposed API.
> >>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it
> is
> >>>>>>> mainly
> >>>>>>>> a matter of deciding what we do for maven 3.
> >>>>>>>> Due to the resources and work needed I assume we can just play the
> >>>>>>>> status-quo for maven 3.
> >>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> >>>>> don't
> >>>>>>> like
> >>>>>>>> much the idea but a compat layer can solve that smoothly for maven
> >>>>>> = 4
> >>>>>>> and
> >>>>>>>> limit the work needed, no?
> >>>>>>>>
> >>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >>>>> mail@laeubi-soft.de>
> >>>>>>> a
> >>>>>>>> écrit :
> >>>>>>>>
> >>>>>>>>> If you really like to separate API and get out of the
> >>>>> ClassRealm-Hell
> >>>>>>>>> OSGi would be much more suitable:
> >>>>>>>>>
> >>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>>>>
> >>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java
> 9
> >>>>> or
> >>>>>>> 11
> >>>>>>>>> and
> >>>>>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>>>>
> >>>>>>>>>> Gary
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> tamas@cservenak.net>
> >>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
> obey
> >>>>>>> them
> >>>>>>>>> is
> >>>>>>>>>>> tricky :D
> >>>>>>>>>>>
> >>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has
> been
> >>>>>>> used in
> >>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>>>>
> >>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> >>>>> really
> >>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>>>>
> >>>>>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>>>>> - maven progress was really hindered by this, as that meant
> >>>>> modifying
> >>>>>>>>> (even
> >>>>>>>>>>> internal) interfaces without breaking clients was impossible,
> so
> >>>>> we
> >>>>>>> went
> >>>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
> >>>>> back.
> >>>>>>>>>>>
> >>>>>>>>>>> The other day we had a question on ML about 4-alpha
> compatibility
> >>>>>>>>> breakage,
> >>>>>>>>>>> and from mail it was clear that the package of the referred
> class
> >>>>> was
> >>>>>>>>>>> having "internal" in it. I mean, developers should really take
> >>>>> care
> >>>>>>> of
> >>>>>>>>> what
> >>>>>>>>>>> they import.
> >>>>>>>>>>>
> >>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >>>>>>> compilation
> >>>>>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>>>>
> >>>>>>>>>>> T
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> >> kwin@apache.org
> >>>>>>
> >>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
> >> we
> >>>>>>> need
> >>>>>>>>> to
> >>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >>>>>>> backwards
> >>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>>>>
> >>>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
> >>>>>>> classes
> >>>>>>>>>>>> generated from
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>>>>> My change in
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>>>>> was not backwards compatible (removed a method on an interface
> >>>>> which
> >>>>>>>>> may
> >>>>>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Konrad
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> >>>>> grab"
> >>>>>>>>>>> sadly,
> >>>>>>>>>>>>> and is probably our major source of problems and reason we
> >>>>> started
> >>>>>>>>>>> Maven
> >>>>>>>>>>>> 4
> >>>>>>>>>>>>> API.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting
> with
> >>>>>>> Maven
> >>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> NOT
> >>>>>>>>>>>> ACCESSIBLE
> >>>>>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>>>>> And done.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> >> about
> >>>>>>> same
> >>>>>>>>>>>> topic
> >>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> HTH
> >>>>>>>>>>>>> T
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >>>>> kwin@apache.org>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> I see now there is already
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
> state:
> >>>>>>> Only
> >>>>>>>>>>>> Maven
> >>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>>>>>>>>>>> everything
> >>>>>>>>>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> >>>>> package
> >>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
> >>>>> and
> >>>>>>>>>>>> exported
> >>>>>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> For example in the context of
> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >>>>> evolve
> >>>>>>> the
> >>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>>>>> We already figured out that this particular package
> (although
> >>>>> not
> >>>>>>>>>>>> part
> >>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> >>>>> Maven
> >>>>>>>>>>>> Plugin
> >>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >>>>> compatible.
> >>>>>>>>>>>>>>> What about others like
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>> ?
> >>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>>> ?>
> >>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
> >>>>> Maven
> >>>>>>>>>>> Core
> >>>>>>>>>>>> but
> >>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>> ).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> create
> >>>>> new
> >>>>>>>>>>> ones
> >>>>>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> >>>>> way
> >>>>>>>>>>> (but
> >>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>>> outside
> >>>>>>>>>>> core)
> >>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards
> compatible
> >>>>> way
> >>>>>>>>>>> (but
> >>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>>> outside
> >>>>>>>>>>> core)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> For all three options we somehow need to come up with a
> list
> >>>>> of
> >>>>>>>>>>>>>> classes/interfaces currently being exported through the API
> >>>>> class
> >>>>>>>>>>>> loader,
> >>>>>>>>>>>>>> which should be considered private and agree on an
> >>>>>>> Annotation/Javadoc
> >>>>>>>>>>>> for
> >>>>>>>>>>>>>> that (something like
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> or
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >>>>> <
> >>>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> ------------------------
> >>>>>> Guillaume Nodet
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> ------------------------
> >>>>> Guillaume Nodet
> >>>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
> That's a good question. Plugins currently don't interact.
> Is that really something we want ?
At least there are several places where I wish I could "plug" into an
existing plugin, curently for example surefire allows some limited
extension using test-frameworks but this requires special configuration.
A good example might be the "set-version" plugin, where in the context
of Tycho one needs to also update versions not only in the
pom.xml/dependency part, the current approach is we actually
copy/replicate what set-version does, but this obviously is far from
optimal. The same applies to jar-plugin (where for example BND plugin
requires special setup/configuration) and even the release-plugin
currently would be something where one needs to do special enhancement
that are hard to maintain and manage.
That's why I previously mentioned in a "we have one isolated mojo"
scenario everything might looks easy and great, but when it comes to
complex setups it gets complicated fast.
> I'd rather keep things simple if possible. They can use the Session
I as well but the problem arises if you want to share more than a simple
string or integer. For example currently Tycho has a project-extension
and also a core-extension part and then people can configure different
mojos ... for sure one can put everything in one big fat jar but that's
really hard to manage and configure, so we have split this up into
smaller mojos.
Still they need to interact (e.g. to not calculate the same stuff over
and over again)... this mostly works as we export some packages that are
kind of "tycho-api" but as one don't write all from scratch there are of
course other dependencies to consider. Even that works, but we always
see issues with classpath incompatibilities that are really hard to
track, e.g. if version of core-extension do not match 100% version of
plugin used in the pom... And i have totally no clue what would happen
if there is another extension also exporting the same dependency ...
Am 19.11.22 um 09:37 schrieb Guillaume Nodet:
> Requiring OSGi for anything user facing in maven is a no-go for me.
>
> Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
>>
>> OSGi support generic capabilities/requirements model:
>> https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
>>
>> Just mentioning it ... for sure we one can re-implement this (again) in
>> maven as well, as a prime goal seems not to reuse existing techniques ;-)
>>
>
> I've been working full time on OSGi for 10 years or so. So I'm quite aware
> of the benefits... and the costs.
> I don't think we need maven to provide any choice here.
>
>
>>
>> With all this perfect "only m4api" world I'm just wondering how will
>> this work together with extensions (either core or project ones) and how
>> is it supposed to allow different plugins to interact?
>>
>
> That's a good question. Plugins currently don't interact. Is that really
> something we want ?
> I'd rather keep things simple if possible. They can use the Session
>
>
>> Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
>>> Howdy,
>>>
>>> just to describe a bit what I meant under "reversed flag":
>>>
>>> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
>>> Plugin classrealm gets (from memory, might be incomplete or wrong):
>>> - m4 API
>>> - m3 "plugin-api"
>>> - javax.inject
>>> - resolver api
>>> - etc as today
>>>
>>> consider that MANY plugins have components, and creating components in
>>> MAJORITY of plugins is easy and should remain easy (and offered "out of
>> the
>>> box").
>>
>> Sounds good to me.
>
>
>>> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
>>> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
>>> plugin can do whatever it wants, but still has access to m4 API (that is
>>> heaven vs earth when compared to m3 state of affairs).
>>
>> Not sure there's any benefit. If we use a custom package for a few DI
> annotation,
> there will be no conflict, so if there's no maven component defined,
> nothing will be done
> and the plugin is still free to use its own DI if it needs.
>
>
>>> ===
>>>
>>> in future, when we drop m3 support, this could mean:
>>>
>>> false (default)
>>> - m4 API
>>> - javax.inject
>>>
>>> true
>>> -m4 API
>>>
>>> ===
>>>
>>> Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
>>> values:
>>> - * <- plugin classrealm should have all "capabilities" current Maven
>>> runtime provides
>>> - m4api <- I want maven 4 api ONLY
>>> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
>> drops
>>> m3 backward compat), slf4j logging and would use jsr330 components
>>> "capability"
>>>
>>> But this is getting too wild maybe :)
>>
>
> Simple is good.
>
> Not touching maven 3 plugins or they way they are loaded at all, I'd
> propose:
> * define a few annotations in org.apache.maven.api.di package, we really
> don't need many, maybe just @Inject, @Bean
> * make sure the plugin classloader does only expose the api to maven
> plugins
> * write a simplistic DI framework
> * make sure plugin can use a different DI framework if they need
>
> Guillaume
>
>> T
>>>
>>> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>>>
>>>> Howdy,
>>>>
>>>> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
>>>> downloads the whole world", at least latest plugins by putting Maven and
>>>> friends in provided scope will not download dozens of versions of
>>>> maven-core and friends... If we do this, at one point we would end up
>> with
>>>> plugins downloading dozens of DI container (or their versions), as even
>> ASF
>>>> plugins would not be in "lockstep".
>>>>
>>>> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
>>>> that would say maven "I will be in charge of my components" (defaults to
>>>> false, Maven behaves as today). When true, it would mean Mojo wants to
>>>> bootstrap some DI/whatever container of its own, and then, for plugins
>> like
>>>> these, Maven could even "narrow" the list of exported classes? (like
>>>> javax.inject?)
>>>>
>>>> T
>>>>
>>>> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
>> wrote:
>>>>
>>>>> Following up on my previous response, and in a more realistic way than
>>>>> switching to OSGi, I wonder if we should let maven 4 plugins do their
>> own
>>>>> DI injection and only care about the mojos, i.e. not rely on
>> sisu/plexus
>>>>> to
>>>>> create and inject the mojo. Mojos using the v4 api do not need to be
>>>>> injected with other components from maven, they should all come from
>> the
>>>>> api and should be retrieved using Session.getService(xx), or simply
>> using
>>>>> session's shortcut methods. The injection of Project and Session is
>> not
>>>>> controlled by sisu. For the ComponentConfigurator, we could change the
>>>>> mojo
>>>>> descriptor to have the full configuration class name for mojos that
>>>>> require
>>>>> custom configuration injection, the plugin manager being in charge of
>>>>> instantiating this class and using it as a ComponentConfigurator
>> (which is
>>>>> not part yet of the api btw).
>>>>>
>>>>> Complex plugins which rely on plexus/sisu to do some custom injection
>>>>> would
>>>>> have to be changed to do their own DI, maybe using a simple Guice
>> setup.
>>>>>
>>>>> If that sounds like too big a change for those plugins, we may be able
>> to
>>>>> add a flag on the mojo descriptor so that those v4-enabled mojos would
>>>>> trigger a DI injection on behalf of the plugin. But if we have to
>>>>> implement something like that, I would go for a plain CDI-like api,
>> either
>>>>> using guice or another DI library supporting the javax.inject package,
>> or
>>>>> rather the jakarta.inject package, as it would be nice to switch to the
>>>>> jakarta version at the same time. Or maybe even plexus if we really
>> need
>>>>> to, but with a limited scope, i.e. no visibility on the maven
>> components,
>>>>> so that plugins are better decoupled from maven-core.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
>>>>> écrit :
>>>>>
>>>>>> I do agree that debugging the provisioning side is *very* complicated
>>>>> when
>>>>>> there's a problem.
>>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
>>>>> framework,
>>>>>> at least for simple plugins.
>>>>>> However, I definitely don't think pushing OSGi to plugins would be a
>>>>> good
>>>>>> idea : the cost and burden on plugin developers would outweigh the
>>>>> benefits.
>>>>>>
>>>>>> For extensions, and for maven itself, that is a different story
>> though.
>>>>>> Maven and extensions could definitely benefit from OSGi, but this
>> would
>>>>> be
>>>>>> a complete breakage and it would be hard to keep some level of
>>>>>> compatibility.
>>>>>>
>>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <mail@laeubi-soft.de
>>>
>>>>> a
>>>>>> écrit :
>>>>>>
>>>>>>> > Guess classrealm is fine for maven, it does not bring much issues
>>>>>>>
>>>>>>> As long as it works, maybe, maybe even if you write a simple maven
>>>>>>> plugin, but for any more complex it is just a complete mess.
>>>>>>>
>>>>>>> Last time I asked on the mailing list how to debug that stuff ...
>>>>>>> complete silence ...
>>>>>>>
>>>>>>> Today I tried to refactor the name of one module of a more complex
>>>>>>> maven-plugin (with core extension), now I end up with
>>>>>>>
>>>>>>> org.apache.maven.InternalErrorException: Internal error:
>>>>>>> com.google.inject.ProvisionException: Unable to provision, see the
>>>>>>> following errors:
>>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
>> bound.
>>>>>>>
>>>>>>> A whole bunch of stack trace but not a little info why the ***** it
>> is
>>>>>>> not happy. Now I need to add random "exportedArtifact" /
>>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
>>>>>>> transitive dependency, also here absolutely no documentation what
>> this
>>>>>>> is supposed to do/work exactly beside some introduction that these
>> xml
>>>>>>> tags exits and reading the code... or probably add maven-compat
>>>>>>> anywhere... or change provided to compile scope (even maven is
>> jelling
>>>>>>> at me that's bad and I will be punished soon)... not counting the
>> many
>>>>>>> times where I messed up the realms because I accidentally trying to
>> use
>>>>>>> XppDom objects in extensions and plugins and something between got
>>>>>>> messed up.
>>>>>>>
>>>>>>> With OSGi i get clear errors for missing requirements, I can clearly
>>>>>>> share API (or declare I don't want to share it) and can reliable use
>> it
>>>>>>> without classlaoding problems.
>>>>>>> If one wan't can even implement service filtering that would hide all
>>>>>>> "illegal implemented API" ... and you can even make sure API is
>>>>>>> (backward) compatible with implementation without waiting for a
>> method
>>>>>>> not found exception or alike.
>>>>>>>
>>>>>>> Beside that I find it often more clear to distinguish between API
>> (that
>>>>>>> is only implemented by the framework) and SPI (that might be
>>>>> implemented
>>>>>>> by extenders). So probably it would be good to have maven-api and
>>>>>>> maven-spi (instead of "maven-core") to make this clear.
>>>>>>>
>>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Guess classrealm is fine for maven, it does not bring much issues
>>>>> (less
>>>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
>> of
>>>>>>> the
>>>>>>>> exposed API.
>>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
>>>>>>> mainly
>>>>>>>> a matter of deciding what we do for maven 3.
>>>>>>>> Due to the resources and work needed I assume we can just play the
>>>>>>>> status-quo for maven 3.
>>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
>>>>> don't
>>>>>>> like
>>>>>>>> much the idea but a compat layer can solve that smoothly for maven
>>>>>> = 4
>>>>>>> and
>>>>>>>> limit the work needed, no?
>>>>>>>>
>>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>>>>> mail@laeubi-soft.de>
>>>>>>> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>> If you really like to separate API and get out of the
>>>>> ClassRealm-Hell
>>>>>>>>> OSGi would be much more suitable:
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>>>>>>
>>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
>>>>> or
>>>>>>> 11
>>>>>>>>> and
>>>>>>>>>> adopt JPMS to better define its public APIs.
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to obey
>>>>>>> them
>>>>>>>>> is
>>>>>>>>>>> tricky :D
>>>>>>>>>>>
>>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
>>>>>>> used in
>>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>>>>>>
>>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
>>>>> really
>>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>>>>>>
>>>>>>>>>>> Ultimately, this was the whole reason for API:
>>>>>>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>>>>>>> - maven progress was really hindered by this, as that meant
>>>>> modifying
>>>>>>>>> (even
>>>>>>>>>>> internal) interfaces without breaking clients was impossible, so
>>>>> we
>>>>>>> went
>>>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
>>>>> back.
>>>>>>>>>>>
>>>>>>>>>>> The other day we had a question on ML about 4-alpha compatibility
>>>>>>>>> breakage,
>>>>>>>>>>> and from mail it was clear that the package of the referred class
>>>>> was
>>>>>>>>>>> having "internal" in it. I mean, developers should really take
>>>>> care
>>>>>>> of
>>>>>>>>> what
>>>>>>>>>>> they import.
>>>>>>>>>>>
>>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
>>>>>>> compilation
>>>>>>>>>>> against "encapsulated" internal classes....
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>>>>>>
>>>>>>>>>>> T
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
>> kwin@apache.org
>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
>> we
>>>>>>> need
>>>>>>>>> to
>>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>>>>>>> backwards
>>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>>>>>>
>>>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
>>>>>>> classes
>>>>>>>>>>>> generated from
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>>>>>>> My change in
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>>>>>>> was not backwards compatible (removed a method on an interface
>>>>> which
>>>>>>>>> may
>>>>>>>>>>>> have been implemented by extensions...)
>>>>>>>>>>>>
>>>>>>>>>>>> Konrad
>>>>>>>>>>>>
>>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
>>>>> grab"
>>>>>>>>>>> sadly,
>>>>>>>>>>>>> and is probably our major source of problems and reason we
>>>>> started
>>>>>>>>>>> Maven
>>>>>>>>>>>> 4
>>>>>>>>>>>>> API.
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
>>>>>>> Maven
>>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>>>>>>>>>>> ACCESSIBLE
>>>>>>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>>>>>>> And done.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
>> about
>>>>>>> same
>>>>>>>>>>>> topic
>>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>>>>>>
>>>>>>>>>>>>> HTH
>>>>>>>>>>>>> T
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>>>>> kwin@apache.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I see now there is already
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should state:
>>>>>>> Only
>>>>>>>>>>>> Maven
>>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>>>>>>> everything
>>>>>>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>>>>>>> plugin/extension developers.
>>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
>>>>> package
>>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
>>>>> and
>>>>>>>>>>>> exported
>>>>>>>>>>>>>> in Maven 3?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For example in the context of
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>>>>> evolve
>>>>>>> the
>>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>>>>>>> We already figured out that this particular package (although
>>>>> not
>>>>>>>>>>>> part
>>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
>>>>> Maven
>>>>>>>>>>>> Plugin
>>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
>>>>> compatible.
>>>>>>>>>>>>>>> What about others like
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>> ?
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>>>> ?>
>>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
>>>>> Maven
>>>>>>>>>>> Core
>>>>>>>>>>>> but
>>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
>>>>> new
>>>>>>>>>>> ones
>>>>>>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
>>>>> way
>>>>>>>>>>> (but
>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>>>> outside
>>>>>>>>>>> core)
>>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
>>>>> way
>>>>>>>>>>> (but
>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>>>> outside
>>>>>>>>>>> core)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For all three options we somehow need to come up with a list
>>>>> of
>>>>>>>>>>>>>> classes/interfaces currently being exported through the API
>>>>> class
>>>>>>>>>>>> loader,
>>>>>>>>>>>>>> which should be considered private and agree on an
>>>>>>> Annotation/Javadoc
>>>>>>>>>>>> for
>>>>>>>>>>>>>> that (something like
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>>
>>>>>>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>>>>> <
>>>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I agree with Guillaume and as discussed by the past we must not expose
anything existing so o.a.maven.whatever.inject sounds the way to go to
ensure we own it in time, and behavior is defined bybus and not a random
not well defined or stable impl.
Le sam. 19 nov. 2022 à 09:37, Guillaume Nodet <gn...@apache.org> a écrit :
> Requiring OSGi for anything user facing in maven is a no-go for me.
>
> Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
> > > Dreaming: but what if not a flag, but some filter(s) for
> "capabilities"?
> >
> > OSGi support generic capabilities/requirements model:
> > https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
> >
> > Just mentioning it ... for sure we one can re-implement this (again) in
> > maven as well, as a prime goal seems not to reuse existing techniques ;-)
> >
>
> I've been working full time on OSGi for 10 years or so. So I'm quite aware
> of the benefits... and the costs.
> I don't think we need maven to provide any choice here.
>
>
> >
> > With all this perfect "only m4api" world I'm just wondering how will
> > this work together with extensions (either core or project ones) and how
> > is it supposed to allow different plugins to interact?
> >
>
> That's a good question. Plugins currently don't interact. Is that really
> something we want ?
> I'd rather keep things simple if possible. They can use the Session
>
>
> > Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
> > > Howdy,
> > >
> > > just to describe a bit what I meant under "reversed flag":
> > >
> > > default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as
> today.
> > > Plugin classrealm gets (from memory, might be incomplete or wrong):
> > > - m4 API
> > > - m3 "plugin-api"
> > > - javax.inject
> > > - resolver api
> > > - etc as today
> > >
> > > consider that MANY plugins have components, and creating components in
> > > MAJORITY of plugins is easy and should remain easy (and offered "out of
> > the
> > > box").
> >
> > Sounds good to me.
>
>
> > > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin
> realm
> > > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> > > plugin can do whatever it wants, but still has access to m4 API (that
> is
> > > heaven vs earth when compared to m3 state of affairs).
> >
> > Not sure there's any benefit. If we use a custom package for a few DI
> annotation,
> there will be no conflict, so if there's no maven component defined,
> nothing will be done
> and the plugin is still free to use its own DI if it needs.
>
>
> > > ===
> > >
> > > in future, when we drop m3 support, this could mean:
> > >
> > > false (default)
> > > - m4 API
> > > - javax.inject
> > >
> > > true
> > > -m4 API
> > >
> > > ===
> > >
> > > Dreaming: but what if not a flag, but some filter(s) for
> "capabilities"?
> > > values:
> > > - * <- plugin classrealm should have all "capabilities" current Maven
> > > runtime provides
> > > - m4api <- I want maven 4 api ONLY
> > > - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
> > drops
> > > m3 backward compat), slf4j logging and would use jsr330 components
> > > "capability"
> > >
> > > But this is getting too wild maybe :)
> >
>
> Simple is good.
>
> Not touching maven 3 plugins or they way they are loaded at all, I'd
> propose:
> * define a few annotations in org.apache.maven.api.di package, we really
> don't need many, maybe just @Inject, @Bean
> * make sure the plugin classloader does only expose the api to maven
> plugins
> * write a simplistic DI framework
> * make sure plugin can use a different DI framework if they need
>
> Guillaume
>
> > T
> > >
> > > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> > >
> > >> Howdy,
> > >>
> > >> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> > >> downloads the whole world", at least latest plugins by putting Maven
> and
> > >> friends in provided scope will not download dozens of versions of
> > >> maven-core and friends... If we do this, at one point we would end up
> > with
> > >> plugins downloading dozens of DI container (or their versions), as
> even
> > ASF
> > >> plugins would not be in "lockstep".
> > >>
> > >> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > >> that would say maven "I will be in charge of my components" (defaults
> to
> > >> false, Maven behaves as today). When true, it would mean Mojo wants to
> > >> bootstrap some DI/whatever container of its own, and then, for plugins
> > like
> > >> these, Maven could even "narrow" the list of exported classes? (like
> > >> javax.inject?)
> > >>
> > >> T
> > >>
> > >> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >>
> > >>> Following up on my previous response, and in a more realistic way
> than
> > >>> switching to OSGi, I wonder if we should let maven 4 plugins do their
> > own
> > >>> DI injection and only care about the mojos, i.e. not rely on
> > sisu/plexus
> > >>> to
> > >>> create and inject the mojo. Mojos using the v4 api do not need to be
> > >>> injected with other components from maven, they should all come from
> > the
> > >>> api and should be retrieved using Session.getService(xx), or simply
> > using
> > >>> session's shortcut methods. The injection of Project and Session is
> > not
> > >>> controlled by sisu. For the ComponentConfigurator, we could change
> the
> > >>> mojo
> > >>> descriptor to have the full configuration class name for mojos that
> > >>> require
> > >>> custom configuration injection, the plugin manager being in charge of
> > >>> instantiating this class and using it as a ComponentConfigurator
> > (which is
> > >>> not part yet of the api btw).
> > >>>
> > >>> Complex plugins which rely on plexus/sisu to do some custom injection
> > >>> would
> > >>> have to be changed to do their own DI, maybe using a simple Guice
> > setup.
> > >>>
> > >>> If that sounds like too big a change for those plugins, we may be
> able
> > to
> > >>> add a flag on the mojo descriptor so that those v4-enabled mojos
> would
> > >>> trigger a DI injection on behalf of the plugin. But if we have to
> > >>> implement something like that, I would go for a plain CDI-like api,
> > either
> > >>> using guice or another DI library supporting the javax.inject
> package,
> > or
> > >>> rather the jakarta.inject package, as it would be nice to switch to
> the
> > >>> jakarta version at the same time. Or maybe even plexus if we really
> > need
> > >>> to, but with a limited scope, i.e. no visibility on the maven
> > components,
> > >>> so that plugins are better decoupled from maven-core.
> > >>>
> > >>> Thoughts ?
> > >>>
> > >>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> > >>> écrit :
> > >>>
> > >>>> I do agree that debugging the provisioning side is *very*
> complicated
> > >>> when
> > >>>> there's a problem.
> > >>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> > >>> framework,
> > >>>> at least for simple plugins.
> > >>>> However, I definitely don't think pushing OSGi to plugins would be a
> > >>> good
> > >>>> idea : the cost and burden on plugin developers would outweigh the
> > >>> benefits.
> > >>>>
> > >>>> For extensions, and for maven itself, that is a different story
> > though.
> > >>>> Maven and extensions could definitely benefit from OSGi, but this
> > would
> > >>> be
> > >>>> a complete breakage and it would be hard to keep some level of
> > >>>> compatibility.
> > >>>>
> > >>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> mail@laeubi-soft.de
> > >
> > >>> a
> > >>>> écrit :
> > >>>>
> > >>>>> > Guess classrealm is fine for maven, it does not bring much
> issues
> > >>>>>
> > >>>>> As long as it works, maybe, maybe even if you write a simple maven
> > >>>>> plugin, but for any more complex it is just a complete mess.
> > >>>>>
> > >>>>> Last time I asked on the mailing list how to debug that stuff ...
> > >>>>> complete silence ...
> > >>>>>
> > >>>>> Today I tried to refactor the name of one module of a more complex
> > >>>>> maven-plugin (with core extension), now I end up with
> > >>>>>
> > >>>>> org.apache.maven.InternalErrorException: Internal error:
> > >>>>> com.google.inject.ProvisionException: Unable to provision, see the
> > >>>>> following errors:
> > >>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> > bound.
> > >>>>>
> > >>>>> A whole bunch of stack trace but not a little info why the ***** it
> > is
> > >>>>> not happy. Now I need to add random "exportedArtifact" /
> > >>>>> "exportedPackage" stuff to hope finding out where it has lost a
> > >>>>> transitive dependency, also here absolutely no documentation what
> > this
> > >>>>> is supposed to do/work exactly beside some introduction that these
> > xml
> > >>>>> tags exits and reading the code... or probably add maven-compat
> > >>>>> anywhere... or change provided to compile scope (even maven is
> > jelling
> > >>>>> at me that's bad and I will be punished soon)... not counting the
> > many
> > >>>>> times where I messed up the realms because I accidentally trying to
> > use
> > >>>>> XppDom objects in extensions and plugins and something between got
> > >>>>> messed up.
> > >>>>>
> > >>>>> With OSGi i get clear errors for missing requirements, I can
> clearly
> > >>>>> share API (or declare I don't want to share it) and can reliable
> use
> > it
> > >>>>> without classlaoding problems.
> > >>>>> If one wan't can even implement service filtering that would hide
> all
> > >>>>> "illegal implemented API" ... and you can even make sure API is
> > >>>>> (backward) compatible with implementation without waiting for a
> > method
> > >>>>> not found exception or alike.
> > >>>>>
> > >>>>> Beside that I find it often more clear to distinguish between API
> > (that
> > >>>>> is only implemented by the framework) and SPI (that might be
> > >>> implemented
> > >>>>> by extenders). So probably it would be good to have maven-api and
> > >>>>> maven-spi (instead of "maven-core") to make this clear.
> > >>>>>
> > >>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> Guess classrealm is fine for maven, it does not bring much issues
> > >>> (less
> > >>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
> > of
> > >>>>> the
> > >>>>>> exposed API.
> > >>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it
> is
> > >>>>> mainly
> > >>>>>> a matter of deciding what we do for maven 3.
> > >>>>>> Due to the resources and work needed I assume we can just play the
> > >>>>>> status-quo for maven 3.
> > >>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> > >>> don't
> > >>>>> like
> > >>>>>> much the idea but a compat layer can solve that smoothly for maven
> > >>>> = 4
> > >>>>> and
> > >>>>>> limit the work needed, no?
> > >>>>>>
> > >>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> > >>> mail@laeubi-soft.de>
> > >>>>> a
> > >>>>>> écrit :
> > >>>>>>
> > >>>>>>> If you really like to separate API and get out of the
> > >>> ClassRealm-Hell
> > >>>>>>> OSGi would be much more suitable:
> > >>>>>>>
> > >>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> > >>>>>>>
> > >>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > >>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java
> 9
> > >>> or
> > >>>>> 11
> > >>>>>>> and
> > >>>>>>>> adopt JPMS to better define its public APIs.
> > >>>>>>>>
> > >>>>>>>> Gary
> > >>>>>>>>
> > >>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> tamas@cservenak.net>
> > >>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Yes, to define rules is quite easy, but to make our users to
> obey
> > >>>>> them
> > >>>>>>> is
> > >>>>>>>>> tricky :D
> > >>>>>>>>>
> > >>>>>>>>> In general, I guess, we should. For this reason JapiCmp has
> been
> > >>>>> used in
> > >>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> > >>>>>>>>>
> > >>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> > >>> really
> > >>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> > >>>>>>>>>
> > >>>>>>>>> Ultimately, this was the whole reason for API:
> > >>>>>>>>> - users "grabbed" whatever could get hold on and used
> > >>>>>>>>> - maven progress was really hindered by this, as that meant
> > >>> modifying
> > >>>>>>> (even
> > >>>>>>>>> internal) interfaces without breaking clients was impossible,
> so
> > >>> we
> > >>>>> went
> > >>>>>>>>> with tricks, and more tricks and even more tricks that now pays
> > >>> back.
> > >>>>>>>>>
> > >>>>>>>>> The other day we had a question on ML about 4-alpha
> compatibility
> > >>>>>>> breakage,
> > >>>>>>>>> and from mail it was clear that the package of the referred
> class
> > >>> was
> > >>>>>>>>> having "internal" in it. I mean, developers should really take
> > >>> care
> > >>>>> of
> > >>>>>>> what
> > >>>>>>>>> they import.
> > >>>>>>>>>
> > >>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> > >>>>> compilation
> > >>>>>>>>> against "encapsulated" internal classes....
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> > >>>>>>>>>
> > >>>>>>>>> T
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> > kwin@apache.org
> > >>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
> > we
> > >>>>> need
> > >>>>>>> to
> > >>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> > >>>>> backwards
> > >>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> > >>>>>>>>>>
> > >>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
> > >>>>> classes
> > >>>>>>>>>> generated from
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > >>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> > >>>>>>>>>> My change in
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > >>>>>>>>>> was not backwards compatible (removed a method on an interface
> > >>> which
> > >>>>>>> may
> > >>>>>>>>>> have been implemented by extensions...)
> > >>>>>>>>>>
> > >>>>>>>>>> Konrad
> > >>>>>>>>>>
> > >>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > >>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> > >>>>>>>>>>>
> > >>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> > >>> grab"
> > >>>>>>>>> sadly,
> > >>>>>>>>>>> and is probably our major source of problems and reason we
> > >>> started
> > >>>>>>>>> Maven
> > >>>>>>>>>> 4
> > >>>>>>>>>>> API.
> > >>>>>>>>>>>
> > >>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting
> with
> > >>>>> Maven
> > >>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> NOT
> > >>>>>>>>>> ACCESSIBLE
> > >>>>>>>>>>> ANYMORE FROM PLUGINS.
> > >>>>>>>>>>> And done.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> > about
> > >>>>> same
> > >>>>>>>>>> topic
> > >>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > >>>>>>>>>>>
> > >>>>>>>>>>> HTH
> > >>>>>>>>>>> T
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> > >>> kwin@apache.org>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>> I see now there is already
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > >>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
> state:
> > >>>>> Only
> > >>>>>>>>>> Maven
> > >>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Konrad
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > >>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> > >>>>>>>>>> everything
> > >>>>>>>>>>>> somehow exposed through class loaders was considered API by
> > >>>>>>>>>>>> plugin/extension developers.
> > >>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> > >>> package
> > >>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
> > >>> and
> > >>>>>>>>>> exported
> > >>>>>>>>>>>> in Maven 3?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> For example in the context of
> > >>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> > >>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> > >>> evolve
> > >>>>> the
> > >>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> > >>>>>>>>>>>>> We already figured out that this particular package
> (although
> > >>> not
> > >>>>>>>>>> part
> > >>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> > >>> Maven
> > >>>>>>>>>> Plugin
> > >>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> > >>> compatible.
> > >>>>>>>>>>>>> What about others like
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > >>>>>>>>>> ?
> > >>>>>>>>>>>> <
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > >>>>>>>>>>>> ?>
> > >>>>>>>>>>>>> This interface should IMHO never been implemented outside
> > >>> Maven
> > >>>>>>>>> Core
> > >>>>>>>>>> but
> > >>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >>>>>>>>>>>> <
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >>>>>>>>>>>>> ).
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> There are three options coming to my mind:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> create
> > >>> new
> > >>>>>>>>> ones
> > >>>>>>>>>>>> for Maven 4 which are not exported!
> > >>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> > >>> way
> > >>>>>>>>> (but
> > >>>>>>>>>>>> somehow add a marker that they should not be implemented
> > >>> outside
> > >>>>>>>>> core)
> > >>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards
> compatible
> > >>> way
> > >>>>>>>>> (but
> > >>>>>>>>>>>> somehow add a marker that they should not be implemented
> > >>> outside
> > >>>>>>>>> core)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> For all three options we somehow need to come up with a
> list
> > >>> of
> > >>>>>>>>>>>> classes/interfaces currently being exported through the API
> > >>> class
> > >>>>>>>>>> loader,
> > >>>>>>>>>>>> which should be considered private and agree on an
> > >>>>> Annotation/Javadoc
> > >>>>>>>>>> for
> > >>>>>>>>>>>> that (something like
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >>>>>>>>>>>> <
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >>>>>>>>>>>
> > >>>>>>>>>>>> or
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> > >>> <
> > >>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> WDYT?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Konrad
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>> ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>> ------------------------
> > >>>> Guillaume Nodet
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> ------------------------
> > >>> Guillaume Nodet
> > >>>
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Guillaume Nodet <gn...@apache.org>.
Requiring OSGi for anything user facing in maven is a no-go for me.
Le sam. 19 nov. 2022 à 05:01, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
>
> OSGi support generic capabilities/requirements model:
> https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
>
> Just mentioning it ... for sure we one can re-implement this (again) in
> maven as well, as a prime goal seems not to reuse existing techniques ;-)
>
I've been working full time on OSGi for 10 years or so. So I'm quite aware
of the benefits... and the costs.
I don't think we need maven to provide any choice here.
>
> With all this perfect "only m4api" world I'm just wondering how will
> this work together with extensions (either core or project ones) and how
> is it supposed to allow different plugins to interact?
>
That's a good question. Plugins currently don't interact. Is that really
something we want ?
I'd rather keep things simple if possible. They can use the Session
> Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
> > Howdy,
> >
> > just to describe a bit what I meant under "reversed flag":
> >
> > default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
> > Plugin classrealm gets (from memory, might be incomplete or wrong):
> > - m4 API
> > - m3 "plugin-api"
> > - javax.inject
> > - resolver api
> > - etc as today
> >
> > consider that MANY plugins have components, and creating components in
> > MAJORITY of plugins is easy and should remain easy (and offered "out of
> the
> > box").
>
> Sounds good to me.
> > but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
> > that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> > plugin can do whatever it wants, but still has access to m4 API (that is
> > heaven vs earth when compared to m3 state of affairs).
>
> Not sure there's any benefit. If we use a custom package for a few DI
annotation,
there will be no conflict, so if there's no maven component defined,
nothing will be done
and the plugin is still free to use its own DI if it needs.
> > ===
> >
> > in future, when we drop m3 support, this could mean:
> >
> > false (default)
> > - m4 API
> > - javax.inject
> >
> > true
> > -m4 API
> >
> > ===
> >
> > Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
> > values:
> > - * <- plugin classrealm should have all "capabilities" current Maven
> > runtime provides
> > - m4api <- I want maven 4 api ONLY
> > - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that
> drops
> > m3 backward compat), slf4j logging and would use jsr330 components
> > "capability"
> >
> > But this is getting too wild maybe :)
>
Simple is good.
Not touching maven 3 plugins or they way they are loaded at all, I'd
propose:
* define a few annotations in org.apache.maven.api.di package, we really
don't need many, maybe just @Inject, @Bean
* make sure the plugin classloader does only expose the api to maven
plugins
* write a simplistic DI framework
* make sure plugin can use a different DI framework if they need
Guillaume
> T
> >
> > On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> >> Howdy,
> >>
> >> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> >> downloads the whole world", at least latest plugins by putting Maven and
> >> friends in provided scope will not download dozens of versions of
> >> maven-core and friends... If we do this, at one point we would end up
> with
> >> plugins downloading dozens of DI container (or their versions), as even
> ASF
> >> plugins would not be in "lockstep".
> >>
> >> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> >> that would say maven "I will be in charge of my components" (defaults to
> >> false, Maven behaves as today). When true, it would mean Mojo wants to
> >> bootstrap some DI/whatever container of its own, and then, for plugins
> like
> >> these, Maven could even "narrow" the list of exported classes? (like
> >> javax.inject?)
> >>
> >> T
> >>
> >> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> >>
> >>> Following up on my previous response, and in a more realistic way than
> >>> switching to OSGi, I wonder if we should let maven 4 plugins do their
> own
> >>> DI injection and only care about the mojos, i.e. not rely on
> sisu/plexus
> >>> to
> >>> create and inject the mojo. Mojos using the v4 api do not need to be
> >>> injected with other components from maven, they should all come from
> the
> >>> api and should be retrieved using Session.getService(xx), or simply
> using
> >>> session's shortcut methods. The injection of Project and Session is
> not
> >>> controlled by sisu. For the ComponentConfigurator, we could change the
> >>> mojo
> >>> descriptor to have the full configuration class name for mojos that
> >>> require
> >>> custom configuration injection, the plugin manager being in charge of
> >>> instantiating this class and using it as a ComponentConfigurator
> (which is
> >>> not part yet of the api btw).
> >>>
> >>> Complex plugins which rely on plexus/sisu to do some custom injection
> >>> would
> >>> have to be changed to do their own DI, maybe using a simple Guice
> setup.
> >>>
> >>> If that sounds like too big a change for those plugins, we may be able
> to
> >>> add a flag on the mojo descriptor so that those v4-enabled mojos would
> >>> trigger a DI injection on behalf of the plugin. But if we have to
> >>> implement something like that, I would go for a plain CDI-like api,
> either
> >>> using guice or another DI library supporting the javax.inject package,
> or
> >>> rather the jakarta.inject package, as it would be nice to switch to the
> >>> jakarta version at the same time. Or maybe even plexus if we really
> need
> >>> to, but with a limited scope, i.e. no visibility on the maven
> components,
> >>> so that plugins are better decoupled from maven-core.
> >>>
> >>> Thoughts ?
> >>>
> >>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> >>> écrit :
> >>>
> >>>> I do agree that debugging the provisioning side is *very* complicated
> >>> when
> >>>> there's a problem.
> >>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >>> framework,
> >>>> at least for simple plugins.
> >>>> However, I definitely don't think pushing OSGi to plugins would be a
> >>> good
> >>>> idea : the cost and burden on plugin developers would outweigh the
> >>> benefits.
> >>>>
> >>>> For extensions, and for maven itself, that is a different story
> though.
> >>>> Maven and extensions could definitely benefit from OSGi, but this
> would
> >>> be
> >>>> a complete breakage and it would be hard to keep some level of
> >>>> compatibility.
> >>>>
> >>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <mail@laeubi-soft.de
> >
> >>> a
> >>>> écrit :
> >>>>
> >>>>> > Guess classrealm is fine for maven, it does not bring much issues
> >>>>>
> >>>>> As long as it works, maybe, maybe even if you write a simple maven
> >>>>> plugin, but for any more complex it is just a complete mess.
> >>>>>
> >>>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>>> complete silence ...
> >>>>>
> >>>>> Today I tried to refactor the name of one module of a more complex
> >>>>> maven-plugin (with core extension), now I end up with
> >>>>>
> >>>>> org.apache.maven.InternalErrorException: Internal error:
> >>>>> com.google.inject.ProvisionException: Unable to provision, see the
> >>>>> following errors:
> >>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> bound.
> >>>>>
> >>>>> A whole bunch of stack trace but not a little info why the ***** it
> is
> >>>>> not happy. Now I need to add random "exportedArtifact" /
> >>>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>>> transitive dependency, also here absolutely no documentation what
> this
> >>>>> is supposed to do/work exactly beside some introduction that these
> xml
> >>>>> tags exits and reading the code... or probably add maven-compat
> >>>>> anywhere... or change provided to compile scope (even maven is
> jelling
> >>>>> at me that's bad and I will be punished soon)... not counting the
> many
> >>>>> times where I messed up the realms because I accidentally trying to
> use
> >>>>> XppDom objects in extensions and plugins and something between got
> >>>>> messed up.
> >>>>>
> >>>>> With OSGi i get clear errors for missing requirements, I can clearly
> >>>>> share API (or declare I don't want to share it) and can reliable use
> it
> >>>>> without classlaoding problems.
> >>>>> If one wan't can even implement service filtering that would hide all
> >>>>> "illegal implemented API" ... and you can even make sure API is
> >>>>> (backward) compatible with implementation without waiting for a
> method
> >>>>> not found exception or alike.
> >>>>>
> >>>>> Beside that I find it often more clear to distinguish between API
> (that
> >>>>> is only implemented by the framework) and SPI (that might be
> >>> implemented
> >>>>> by extenders). So probably it would be good to have maven-api and
> >>>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>>
> >>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Guess classrealm is fine for maven, it does not bring much issues
> >>> (less
> >>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
> of
> >>>>> the
> >>>>>> exposed API.
> >>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
> >>>>> mainly
> >>>>>> a matter of deciding what we do for maven 3.
> >>>>>> Due to the resources and work needed I assume we can just play the
> >>>>>> status-quo for maven 3.
> >>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> >>> don't
> >>>>> like
> >>>>>> much the idea but a compat layer can solve that smoothly for maven
> >>>> = 4
> >>>>> and
> >>>>>> limit the work needed, no?
> >>>>>>
> >>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >>> mail@laeubi-soft.de>
> >>>>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>> If you really like to separate API and get out of the
> >>> ClassRealm-Hell
> >>>>>>> OSGi would be much more suitable:
> >>>>>>>
> >>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>>
> >>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
> >>> or
> >>>>> 11
> >>>>>>> and
> >>>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>>
> >>>>>>>> Gary
> >>>>>>>>
> >>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
> >>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Yes, to define rules is quite easy, but to make our users to obey
> >>>>> them
> >>>>>>> is
> >>>>>>>>> tricky :D
> >>>>>>>>>
> >>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
> >>>>> used in
> >>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>>
> >>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> >>> really
> >>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>>
> >>>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>>> - maven progress was really hindered by this, as that meant
> >>> modifying
> >>>>>>> (even
> >>>>>>>>> internal) interfaces without breaking clients was impossible, so
> >>> we
> >>>>> went
> >>>>>>>>> with tricks, and more tricks and even more tricks that now pays
> >>> back.
> >>>>>>>>>
> >>>>>>>>> The other day we had a question on ML about 4-alpha compatibility
> >>>>>>> breakage,
> >>>>>>>>> and from mail it was clear that the package of the referred class
> >>> was
> >>>>>>>>> having "internal" in it. I mean, developers should really take
> >>> care
> >>>>> of
> >>>>>>> what
> >>>>>>>>> they import.
> >>>>>>>>>
> >>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >>>>> compilation
> >>>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>>
> >>>>>>>>> T
> >>>>>>>>>
> >>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> kwin@apache.org
> >>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
> we
> >>>>> need
> >>>>>>> to
> >>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >>>>> backwards
> >>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>>
> >>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
> >>>>> classes
> >>>>>>>>>> generated from
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>>> My change in
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>>> was not backwards compatible (removed a method on an interface
> >>> which
> >>>>>>> may
> >>>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>>
> >>>>>>>>>> Konrad
> >>>>>>>>>>
> >>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>>
> >>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> >>> grab"
> >>>>>>>>> sadly,
> >>>>>>>>>>> and is probably our major source of problems and reason we
> >>> started
> >>>>>>>>> Maven
> >>>>>>>>>> 4
> >>>>>>>>>>> API.
> >>>>>>>>>>>
> >>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
> >>>>> Maven
> >>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >>>>>>>>>> ACCESSIBLE
> >>>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>>> And done.
> >>>>>>>>>>>
> >>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> about
> >>>>> same
> >>>>>>>>>> topic
> >>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>>
> >>>>>>>>>>> HTH
> >>>>>>>>>>> T
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >>> kwin@apache.org>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I see now there is already
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>>> but to me the javadoc is not explicit enough. It should state:
> >>>>> Only
> >>>>>>>>>> Maven
> >>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Konrad
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>>>>>>>>> everything
> >>>>>>>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> >>> package
> >>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
> >>> and
> >>>>>>>>>> exported
> >>>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For example in the context of
> >>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >>> evolve
> >>>>> the
> >>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>>> We already figured out that this particular package (although
> >>> not
> >>>>>>>>>> part
> >>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> >>> Maven
> >>>>>>>>>> Plugin
> >>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >>> compatible.
> >>>>>>>>>>>>> What about others like
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>> ?
> >>>>>>>>>>>> <
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>> ?>
> >>>>>>>>>>>>> This interface should IMHO never been implemented outside
> >>> Maven
> >>>>>>>>> Core
> >>>>>>>>>> but
> >>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>> <
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>> ).
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
> >>> new
> >>>>>>>>> ones
> >>>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> >>> way
> >>>>>>>>> (but
> >>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>> outside
> >>>>>>>>> core)
> >>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
> >>> way
> >>>>>>>>> (but
> >>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>> outside
> >>>>>>>>> core)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For all three options we somehow need to come up with a list
> >>> of
> >>>>>>>>>>>> classes/interfaces currently being exported through the API
> >>> class
> >>>>>>>>>> loader,
> >>>>>>>>>>>> which should be considered private and agree on an
> >>>>> Annotation/Javadoc
> >>>>>>>>>> for
> >>>>>>>>>>>> that (something like
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>> <
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>
> >>>>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >>> <
> >>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> ------------------------
> >>>> Guillaume Nodet
> >>>>
> >>>>
> >>>
> >>> --
> >>> ------------------------
> >>> Guillaume Nodet
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
> Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
OSGi support generic capabilities/requirements model:
https://blog.osgi.org/2015/12/using-requirements-and-capabilities.html
Just mentioning it ... for sure we one can re-implement this (again) in
maven as well, as a prime goal seems not to reuse existing techniques ;-)
With all this perfect "only m4api" world I'm just wondering how will
this work together with extensions (either core or project ones) and how
is it supposed to allow different plugins to interact?
Am 18.11.22 um 19:10 schrieb Tamás Cservenák:
> Howdy,
>
> just to describe a bit what I meant under "reversed flag":
>
> default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
> Plugin classrealm gets (from memory, might be incomplete or wrong):
> - m4 API
> - m3 "plugin-api"
> - javax.inject
> - resolver api
> - etc as today
>
> consider that MANY plugins have components, and creating components in
> MAJORITY of plugins is easy and should remain easy (and offered "out of the
> box").
>
> but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
> that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
> plugin can do whatever it wants, but still has access to m4 API (that is
> heaven vs earth when compared to m3 state of affairs).
>
> ===
>
> in future, when we drop m3 support, this could mean:
>
> false (default)
> - m4 API
> - javax.inject
>
> true
> -m4 API
>
> ===
>
> Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
> values:
> - * <- plugin classrealm should have all "capabilities" current Maven
> runtime provides
> - m4api <- I want maven 4 api ONLY
> - m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that drops
> m3 backward compat), slf4j logging and would use jsr330 components
> "capability"
>
> But this is getting too wild maybe :)
>
>
> T
>
> On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
>> Howdy,
>>
>> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
>> downloads the whole world", at least latest plugins by putting Maven and
>> friends in provided scope will not download dozens of versions of
>> maven-core and friends... If we do this, at one point we would end up with
>> plugins downloading dozens of DI container (or their versions), as even ASF
>> plugins would not be in "lockstep".
>>
>> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
>> that would say maven "I will be in charge of my components" (defaults to
>> false, Maven behaves as today). When true, it would mean Mojo wants to
>> bootstrap some DI/whatever container of its own, and then, for plugins like
>> these, Maven could even "narrow" the list of exported classes? (like
>> javax.inject?)
>>
>> T
>>
>> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org> wrote:
>>
>>> Following up on my previous response, and in a more realistic way than
>>> switching to OSGi, I wonder if we should let maven 4 plugins do their own
>>> DI injection and only care about the mojos, i.e. not rely on sisu/plexus
>>> to
>>> create and inject the mojo. Mojos using the v4 api do not need to be
>>> injected with other components from maven, they should all come from the
>>> api and should be retrieved using Session.getService(xx), or simply using
>>> session's shortcut methods. The injection of Project and Session is not
>>> controlled by sisu. For the ComponentConfigurator, we could change the
>>> mojo
>>> descriptor to have the full configuration class name for mojos that
>>> require
>>> custom configuration injection, the plugin manager being in charge of
>>> instantiating this class and using it as a ComponentConfigurator (which is
>>> not part yet of the api btw).
>>>
>>> Complex plugins which rely on plexus/sisu to do some custom injection
>>> would
>>> have to be changed to do their own DI, maybe using a simple Guice setup.
>>>
>>> If that sounds like too big a change for those plugins, we may be able to
>>> add a flag on the mojo descriptor so that those v4-enabled mojos would
>>> trigger a DI injection on behalf of the plugin. But if we have to
>>> implement something like that, I would go for a plain CDI-like api, either
>>> using guice or another DI library supporting the javax.inject package, or
>>> rather the jakarta.inject package, as it would be nice to switch to the
>>> jakarta version at the same time. Or maybe even plexus if we really need
>>> to, but with a limited scope, i.e. no visibility on the maven components,
>>> so that plugins are better decoupled from maven-core.
>>>
>>> Thoughts ?
>>>
>>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
>>> écrit :
>>>
>>>> I do agree that debugging the provisioning side is *very* complicated
>>> when
>>>> there's a problem.
>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
>>> framework,
>>>> at least for simple plugins.
>>>> However, I definitely don't think pushing OSGi to plugins would be a
>>> good
>>>> idea : the cost and burden on plugin developers would outweigh the
>>> benefits.
>>>>
>>>> For extensions, and for maven itself, that is a different story though.
>>>> Maven and extensions could definitely benefit from OSGi, but this would
>>> be
>>>> a complete breakage and it would be hard to keep some level of
>>>> compatibility.
>>>>
>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de>
>>> a
>>>> écrit :
>>>>
>>>>> > Guess classrealm is fine for maven, it does not bring much issues
>>>>>
>>>>> As long as it works, maybe, maybe even if you write a simple maven
>>>>> plugin, but for any more complex it is just a complete mess.
>>>>>
>>>>> Last time I asked on the mailing list how to debug that stuff ...
>>>>> complete silence ...
>>>>>
>>>>> Today I tried to refactor the name of one module of a more complex
>>>>> maven-plugin (with core extension), now I end up with
>>>>>
>>>>> org.apache.maven.InternalErrorException: Internal error:
>>>>> com.google.inject.ProvisionException: Unable to provision, see the
>>>>> following errors:
>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>>>>>
>>>>> A whole bunch of stack trace but not a little info why the ***** it is
>>>>> not happy. Now I need to add random "exportedArtifact" /
>>>>> "exportedPackage" stuff to hope finding out where it has lost a
>>>>> transitive dependency, also here absolutely no documentation what this
>>>>> is supposed to do/work exactly beside some introduction that these xml
>>>>> tags exits and reading the code... or probably add maven-compat
>>>>> anywhere... or change provided to compile scope (even maven is jelling
>>>>> at me that's bad and I will be punished soon)... not counting the many
>>>>> times where I messed up the realms because I accidentally trying to use
>>>>> XppDom objects in extensions and plugins and something between got
>>>>> messed up.
>>>>>
>>>>> With OSGi i get clear errors for missing requirements, I can clearly
>>>>> share API (or declare I don't want to share it) and can reliable use it
>>>>> without classlaoding problems.
>>>>> If one wan't can even implement service filtering that would hide all
>>>>> "illegal implemented API" ... and you can even make sure API is
>>>>> (backward) compatible with implementation without waiting for a method
>>>>> not found exception or alike.
>>>>>
>>>>> Beside that I find it often more clear to distinguish between API (that
>>>>> is only implemented by the framework) and SPI (that might be
>>> implemented
>>>>> by extenders). So probably it would be good to have maven-api and
>>>>> maven-spi (instead of "maven-core") to make this clear.
>>>>>
>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>>>>> Hi,
>>>>>>
>>>>>> Guess classrealm is fine for maven, it does not bring much issues
>>> (less
>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability of
>>>>> the
>>>>>> exposed API.
>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
>>>>> mainly
>>>>>> a matter of deciding what we do for maven 3.
>>>>>> Due to the resources and work needed I assume we can just play the
>>>>>> status-quo for maven 3.
>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
>>> don't
>>>>> like
>>>>>> much the idea but a compat layer can solve that smoothly for maven
>>>> = 4
>>>>> and
>>>>>> limit the work needed, no?
>>>>>>
>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>>> mail@laeubi-soft.de>
>>>>> a
>>>>>> écrit :
>>>>>>
>>>>>>> If you really like to separate API and get out of the
>>> ClassRealm-Hell
>>>>>>> OSGi would be much more suitable:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>>>>
>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
>>> or
>>>>> 11
>>>>>>> and
>>>>>>>> adopt JPMS to better define its public APIs.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>>>>> wrote:
>>>>>>>>
>>>>>>>>> Yes, to define rules is quite easy, but to make our users to obey
>>>>> them
>>>>>>> is
>>>>>>>>> tricky :D
>>>>>>>>>
>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
>>>>> used in
>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>>>>
>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
>>> really
>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>>>>
>>>>>>>>> Ultimately, this was the whole reason for API:
>>>>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>>>>> - maven progress was really hindered by this, as that meant
>>> modifying
>>>>>>> (even
>>>>>>>>> internal) interfaces without breaking clients was impossible, so
>>> we
>>>>> went
>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
>>> back.
>>>>>>>>>
>>>>>>>>> The other day we had a question on ML about 4-alpha compatibility
>>>>>>> breakage,
>>>>>>>>> and from mail it was clear that the package of the referred class
>>> was
>>>>>>>>> having "internal" in it. I mean, developers should really take
>>> care
>>>>> of
>>>>>>> what
>>>>>>>>> they import.
>>>>>>>>>
>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
>>>>> compilation
>>>>>>>>> against "encapsulated" internal classes....
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>>>>
>>>>>>>>> T
>>>>>>>>>
>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kwin@apache.org
>>>>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do we
>>>>> need
>>>>>>> to
>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>>>>> backwards
>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>>>>
>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
>>>>> classes
>>>>>>>>>> generated from
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>>>>> My change in
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>>>>> was not backwards compatible (removed a method on an interface
>>> which
>>>>>>> may
>>>>>>>>>> have been implemented by extensions...)
>>>>>>>>>>
>>>>>>>>>> Konrad
>>>>>>>>>>
>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>>>>
>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
>>> grab"
>>>>>>>>> sadly,
>>>>>>>>>>> and is probably our major source of problems and reason we
>>> started
>>>>>>>>> Maven
>>>>>>>>>> 4
>>>>>>>>>>> API.
>>>>>>>>>>>
>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
>>>>> Maven
>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>>>>>>>>> ACCESSIBLE
>>>>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>>>>> And done.
>>>>>>>>>>>
>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say about
>>>>> same
>>>>>>>>>> topic
>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>>>>
>>>>>>>>>>> HTH
>>>>>>>>>>> T
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>>> kwin@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I see now there is already
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should state:
>>>>> Only
>>>>>>>>>> Maven
>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>>>>
>>>>>>>>>>>> Konrad
>>>>>>>>>>>>
>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>>>>> everything
>>>>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>>>>> plugin/extension developers.
>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
>>> package
>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
>>> and
>>>>>>>>>> exported
>>>>>>>>>>>> in Maven 3?
>>>>>>>>>>>>>
>>>>>>>>>>>>> For example in the context of
>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>>> evolve
>>>>> the
>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>>>>> We already figured out that this particular package (although
>>> not
>>>>>>>>>> part
>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
>>> Maven
>>>>>>>>>> Plugin
>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
>>> compatible.
>>>>>>>>>>>>> What about others like
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>> ?
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>> ?>
>>>>>>>>>>>>> This interface should IMHO never been implemented outside
>>> Maven
>>>>>>>>> Core
>>>>>>>>>> but
>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>> ).
>>>>>>>>>>>>>
>>>>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
>>> new
>>>>>>>>> ones
>>>>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
>>> way
>>>>>>>>> (but
>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>> outside
>>>>>>>>> core)
>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
>>> way
>>>>>>>>> (but
>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>> outside
>>>>>>>>> core)
>>>>>>>>>>>>>
>>>>>>>>>>>>> For all three options we somehow need to come up with a list
>>> of
>>>>>>>>>>>> classes/interfaces currently being exported through the API
>>> class
>>>>>>>>>> loader,
>>>>>>>>>>>> which should be considered private and agree on an
>>>>> Annotation/Javadoc
>>>>>>>>>> for
>>>>>>>>>>>> that (something like
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>
>>>>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>>> <
>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>>
>>>>
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
just to describe a bit what I meant under "reversed flag":
default is iWillBeInChargeOfMyComponents=false, Maven4 behaves as today.
Plugin classrealm gets (from memory, might be incomplete or wrong):
- m4 API
- m3 "plugin-api"
- javax.inject
- resolver api
- etc as today
consider that MANY plugins have components, and creating components in
MAJORITY of plugins is easy and should remain easy (and offered "out of the
box").
but IF iWillBeInChargeOfMyComponents=true, Maven 4 creates a plugin realm
that has m4 API accessible ONLY, NOTHING MORE. And in that sandbox, the
plugin can do whatever it wants, but still has access to m4 API (that is
heaven vs earth when compared to m3 state of affairs).
===
in future, when we drop m3 support, this could mean:
false (default)
- m4 API
- javax.inject
true
-m4 API
===
Dreaming: but what if not a flag, but some filter(s) for "capabilities"?
values:
- * <- plugin classrealm should have all "capabilities" current Maven
runtime provides
- m4api <- I want maven 4 api ONLY
- m3api, slf4j, jsr330 <- I want to m3 api (would break in m4+ that drops
m3 backward compat), slf4j logging and would use jsr330 components
"capability"
But this is getting too wild maybe :)
T
On Fri, Nov 18, 2022 at 6:34 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> downloads the whole world", at least latest plugins by putting Maven and
> friends in provided scope will not download dozens of versions of
> maven-core and friends... If we do this, at one point we would end up with
> plugins downloading dozens of DI container (or their versions), as even ASF
> plugins would not be in "lockstep".
>
> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> that would say maven "I will be in charge of my components" (defaults to
> false, Maven behaves as today). When true, it would mean Mojo wants to
> bootstrap some DI/whatever container of its own, and then, for plugins like
> these, Maven could even "narrow" the list of exported classes? (like
> javax.inject?)
>
> T
>
> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org> wrote:
>
>> Following up on my previous response, and in a more realistic way than
>> switching to OSGi, I wonder if we should let maven 4 plugins do their own
>> DI injection and only care about the mojos, i.e. not rely on sisu/plexus
>> to
>> create and inject the mojo. Mojos using the v4 api do not need to be
>> injected with other components from maven, they should all come from the
>> api and should be retrieved using Session.getService(xx), or simply using
>> session's shortcut methods. The injection of Project and Session is not
>> controlled by sisu. For the ComponentConfigurator, we could change the
>> mojo
>> descriptor to have the full configuration class name for mojos that
>> require
>> custom configuration injection, the plugin manager being in charge of
>> instantiating this class and using it as a ComponentConfigurator (which is
>> not part yet of the api btw).
>>
>> Complex plugins which rely on plexus/sisu to do some custom injection
>> would
>> have to be changed to do their own DI, maybe using a simple Guice setup.
>>
>> If that sounds like too big a change for those plugins, we may be able to
>> add a flag on the mojo descriptor so that those v4-enabled mojos would
>> trigger a DI injection on behalf of the plugin. But if we have to
>> implement something like that, I would go for a plain CDI-like api, either
>> using guice or another DI library supporting the javax.inject package, or
>> rather the jakarta.inject package, as it would be nice to switch to the
>> jakarta version at the same time. Or maybe even plexus if we really need
>> to, but with a limited scope, i.e. no visibility on the maven components,
>> so that plugins are better decoupled from maven-core.
>>
>> Thoughts ?
>>
>> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
>> écrit :
>>
>> > I do agree that debugging the provisioning side is *very* complicated
>> when
>> > there's a problem.
>> > I'd be happy to get rid of sisu/plexus and use a more simple DI
>> framework,
>> > at least for simple plugins.
>> > However, I definitely don't think pushing OSGi to plugins would be a
>> good
>> > idea : the cost and burden on plugin developers would outweigh the
>> benefits.
>> >
>> > For extensions, and for maven itself, that is a different story though.
>> > Maven and extensions could definitely benefit from OSGi, but this would
>> be
>> > a complete breakage and it would be hard to keep some level of
>> > compatibility.
>> >
>> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de>
>> a
>> > écrit :
>> >
>> >> > Guess classrealm is fine for maven, it does not bring much issues
>> >>
>> >> As long as it works, maybe, maybe even if you write a simple maven
>> >> plugin, but for any more complex it is just a complete mess.
>> >>
>> >> Last time I asked on the mailing list how to debug that stuff ...
>> >> complete silence ...
>> >>
>> >> Today I tried to refactor the name of one module of a more complex
>> >> maven-plugin (with core extension), now I end up with
>> >>
>> >> org.apache.maven.InternalErrorException: Internal error:
>> >> com.google.inject.ProvisionException: Unable to provision, see the
>> >> following errors:
>> >> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>> >>
>> >> A whole bunch of stack trace but not a little info why the ***** it is
>> >> not happy. Now I need to add random "exportedArtifact" /
>> >> "exportedPackage" stuff to hope finding out where it has lost a
>> >> transitive dependency, also here absolutely no documentation what this
>> >> is supposed to do/work exactly beside some introduction that these xml
>> >> tags exits and reading the code... or probably add maven-compat
>> >> anywhere... or change provided to compile scope (even maven is jelling
>> >> at me that's bad and I will be punished soon)... not counting the many
>> >> times where I messed up the realms because I accidentally trying to use
>> >> XppDom objects in extensions and plugins and something between got
>> >> messed up.
>> >>
>> >> With OSGi i get clear errors for missing requirements, I can clearly
>> >> share API (or declare I don't want to share it) and can reliable use it
>> >> without classlaoding problems.
>> >> If one wan't can even implement service filtering that would hide all
>> >> "illegal implemented API" ... and you can even make sure API is
>> >> (backward) compatible with implementation without waiting for a method
>> >> not found exception or alike.
>> >>
>> >> Beside that I find it often more clear to distinguish between API (that
>> >> is only implemented by the framework) and SPI (that might be
>> implemented
>> >> by extenders). So probably it would be good to have maven-api and
>> >> maven-spi (instead of "maven-core") to make this clear.
>> >>
>> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>> >> > Hi,
>> >> >
>> >> > Guess classrealm is fine for maven, it does not bring much issues
>> (less
>> >> > than OSGi or JPMS to be concrete), the real issue is the stability of
>> >> the
>> >> > exposed API.
>> >> > Thanks the hard work Guillaume did on that for maven 4 I guess it is
>> >> mainly
>> >> > a matter of deciding what we do for maven 3.
>> >> > Due to the resources and work needed I assume we can just play the
>> >> > status-quo for maven 3.
>> >> > Remaining question is for maven 4 do we drop the compatibilty. I
>> don't
>> >> like
>> >> > much the idea but a compat layer can solve that smoothly for maven
>> >= 4
>> >> and
>> >> > limit the work needed, no?
>> >> >
>> >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>> mail@laeubi-soft.de>
>> >> a
>> >> > écrit :
>> >> >
>> >> >> If you really like to separate API and get out of the
>> ClassRealm-Hell
>> >> >> OSGi would be much more suitable:
>> >> >>
>> >> >> https://issues.apache.org/jira/browse/MNG-7518
>> >> >>
>> >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>> >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
>> or
>> >> 11
>> >> >> and
>> >> >>> adopt JPMS to better define its public APIs.
>> >> >>>
>> >> >>> Gary
>> >> >>>
>> >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>> >> wrote:
>> >> >>>
>> >> >>>> Yes, to define rules is quite easy, but to make our users to obey
>> >> them
>> >> >> is
>> >> >>>> tricky :D
>> >> >>>>
>> >> >>>> In general, I guess, we should. For this reason JapiCmp has been
>> >> used in
>> >> >>>> Resolver since 1.9.0 (as noted on refd page end).
>> >> >>>>
>> >> >>>> But while this was "kinda simple" to achieve in Resolver, I am
>> really
>> >> >>>> unsure if it is doable in Maven (sans 4 API) :(
>> >> >>>>
>> >> >>>> Ultimately, this was the whole reason for API:
>> >> >>>> - users "grabbed" whatever could get hold on and used
>> >> >>>> - maven progress was really hindered by this, as that meant
>> modifying
>> >> >> (even
>> >> >>>> internal) interfaces without breaking clients was impossible, so
>> we
>> >> went
>> >> >>>> with tricks, and more tricks and even more tricks that now pays
>> back.
>> >> >>>>
>> >> >>>> The other day we had a question on ML about 4-alpha compatibility
>> >> >> breakage,
>> >> >>>> and from mail it was clear that the package of the referred class
>> was
>> >> >>>> having "internal" in it. I mean, developers should really take
>> care
>> >> of
>> >> >> what
>> >> >>>> they import.
>> >> >>>>
>> >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
>> >> compilation
>> >> >>>> against "encapsulated" internal classes....
>> >> >>>>
>> >> >>>>
>> >> >>
>> >>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>> >> >>>>
>> >> >>>> T
>> >> >>>>
>> >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kwin@apache.org
>> >
>> >> >> wrote:
>> >> >>>>
>> >> >>>>> I guess this is the easy part, the tricky question remains: Do we
>> >> need
>> >> >> to
>> >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>> >> backwards
>> >> >>>>> compatible until we reach 4.100/5.0/whatever?
>> >> >>>>>
>> >> >>>>> This wasn't handled consistently in master till now, e.g. the
>> >> classes
>> >> >>>>> generated from
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>> >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
>> >> >>>>> My change in
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>> >> >>>>> was not backwards compatible (removed a method on an interface
>> which
>> >> >> may
>> >> >>>>> have been implemented by extensions...)
>> >> >>>>>
>> >> >>>>> Konrad
>> >> >>>>>
>> >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>> >> >>>>>> Unsure we want to deprecate all of Maven :)
>> >> >>>>>>
>> >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can
>> grab"
>> >> >>>> sadly,
>> >> >>>>>> and is probably our major source of problems and reason we
>> started
>> >> >>>> Maven
>> >> >>>>> 4
>> >> >>>>>> API.
>> >> >>>>>>
>> >> >>>>>> IMO, I'd consider them as "whole", and just say "starting with
>> >> Maven
>> >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>> >> >>>>> ACCESSIBLE
>> >> >>>>>> ANYMORE FROM PLUGINS.
>> >> >>>>>> And done.
>> >> >>>>>>
>> >> >>>>>> Just as an example, here is what Maven Resolver has to say about
>> >> same
>> >> >>>>> topic
>> >> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>> >> >>>>>>
>> >> >>>>>> HTH
>> >> >>>>>> T
>> >> >>>>>>
>> >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>> kwin@apache.org>
>> >> >>>>> wrote:
>> >> >>>>>>
>> >> >>>>>>> I see now there is already
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>> >> >>>>>>> but to me the javadoc is not explicit enough. It should state:
>> >> Only
>> >> >>>>> Maven
>> >> >>>>>>> is allowed to implement/extend types with this annotation.
>> >> >>>>>>>
>> >> >>>>>>> Konrad
>> >> >>>>>>>
>> >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>> >> >>>>>>>> Hi,
>> >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>> >> >>>>> everything
>> >> >>>>>>> somehow exposed through class loaders was considered API by
>> >> >>>>>>> plugin/extension developers.
>> >> >>>>>>>> For Maven 4 a completely separate API was established in
>> package
>> >> >>>>>>> “org.apache.maven.api”, but what about the old packages used
>> and
>> >> >>>>> exported
>> >> >>>>>>> in Maven 3?
>> >> >>>>>>>>
>> >> >>>>>>>> For example in the context of
>> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>> evolve
>> >> the
>> >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
>> >> >>>>>>>> We already figured out that this particular package (although
>> not
>> >> >>>>> part
>> >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as
>> Maven
>> >> >>>>> Plugin
>> >> >>>>>>> Tools, therefore this probably needs to stay backwards
>> compatible.
>> >> >>>>>>>> What about others like
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> >> >>>>> ?
>> >> >>>>>>> <
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> >> >>>>>>> ?>
>> >> >>>>>>>> This interface should IMHO never been implemented outside
>> Maven
>> >> >>>> Core
>> >> >>>>> but
>> >> >>>>>>> in fact it was exposed to all plugins/extensions (via
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> >> >>>>>>> <
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> >> >>>>>>>> ).
>> >> >>>>>>>>
>> >> >>>>>>>> There are three options coming to my mind:
>> >> >>>>>>>>
>> >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
>> new
>> >> >>>> ones
>> >> >>>>>>> for Maven 4 which are not exported!
>> >> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible
>> way
>> >> >>>> (but
>> >> >>>>>>> somehow add a marker that they should not be implemented
>> outside
>> >> >>>> core)
>> >> >>>>>>>> 3. Modify the existing interfaces in a backwards compatible
>> way
>> >> >>>> (but
>> >> >>>>>>> somehow add a marker that they should not be implemented
>> outside
>> >> >>>> core)
>> >> >>>>>>>>
>> >> >>>>>>>> For all three options we somehow need to come up with a list
>> of
>> >> >>>>>>> classes/interfaces currently being exported through the API
>> class
>> >> >>>>> loader,
>> >> >>>>>>> which should be considered private and agree on an
>> >> Annotation/Javadoc
>> >> >>>>> for
>> >> >>>>>>> that (something like
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> >> >>>>>>> <
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>
>> >>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> >> >>>>>>
>> >> >>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>> <
>> >> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>> >> >>>>>>>>
>> >> >>>>>>>> WDYT?
>> >> >>>>>>>>
>> >> >>>>>>>> Konrad
>> >> >>>>>>>>
>> >> >>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> ---------------------------------------------------------------------
>> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> > --
>> > ------------------------
>> > Guillaume Nodet
>> >
>> >
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Guillaume Nodet <gn...@apache.org>.
My point was to get rid of sisu/plexus. In my mind, having the plugin do
its own DI was a simple way to achieve that for maven4 plugins. But if
that's not something we want, I'm certainly not advocating for additional
complexity.
I propose to have maven4 plugins be bootstrapped by maven with a simple
(compared to sisu/plexus) DI that would support jakarta.inject package (the
javax.inject package being deprecated) or maybe even better, maven's own
annotations which would then be part of the maven4 API. This could be a
pure Guice container, a simple adhoc framework, or whatever. We just need
to clearly define that API. The goal is to isolate plugins from any maven
service and get rid of the sisu additional complexity with realms,
descriptors and such.
And for maven4 plugin class loaders, I think we should only expose the
maven4 API + the DI package if we don't use our own.
Le ven. 18 nov. 2022, 21:26, Tamás Cservenák <ta...@cservenak.net> a écrit :
> No, I don't think so, the "capabilities" is just a "dream" piggybacked onto
> your story :)
>
> All in all, I think a flag but with reversed logic would be good: default
> is remain as-is (maven DI), and if flipped, then plugin DI.
>
> But again, "plugin DI" would not make much sense, if core still exposes all
> of javax.inject, does it?
> For me the two are somehow connected => "capabilities"
>
> T
>
> On Fri, Nov 18, 2022 at 8:59 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > You misunderstood me.
> > I wasn't thinking about changing the way the classloader is built, just
> the
> > way the dependency injection mechanism is done for plugins (and/or
> > maven-core).
> >
> > Le ven. 18 nov. 2022 à 18:35, Tamás Cservenák <ta...@cservenak.net> a
> > écrit :
> >
> > > Howdy,
> > >
> > > Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> > > downloads the whole world", at least latest plugins by putting Maven
> and
> > > friends in provided scope will not download dozens of versions of
> > > maven-core and friends... If we do this, at one point we would end up
> > with
> > > plugins downloading dozens of DI container (or their versions), as even
> > ASF
> > > plugins would not be in "lockstep".
> > >
> > > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> > that
> > > would say maven "I will be in charge of my components" (defaults to
> > false,
> > > Maven behaves as today). When true, it would mean Mojo wants to
> > > bootstrap some DI/whatever container of its own, and then, for plugins
> > like
> > > these, Maven could even "narrow" the list of exported classes? (like
> > > javax.inject?)
> > >
> > > T
> > >
> > > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > > > Following up on my previous response, and in a more realistic way
> than
> > > > switching to OSGi, I wonder if we should let maven 4 plugins do their
> > own
> > > > DI injection and only care about the mojos, i.e. not rely on
> > sisu/plexus
> > > to
> > > > create and inject the mojo. Mojos using the v4 api do not need to be
> > > > injected with other components from maven, they should all come from
> > the
> > > > api and should be retrieved using Session.getService(xx), or simply
> > using
> > > > session's shortcut methods. The injection of Project and Session is
> > not
> > > > controlled by sisu. For the ComponentConfigurator, we could change
> the
> > > mojo
> > > > descriptor to have the full configuration class name for mojos that
> > > require
> > > > custom configuration injection, the plugin manager being in charge of
> > > > instantiating this class and using it as a ComponentConfigurator
> (which
> > > is
> > > > not part yet of the api btw).
> > > >
> > > > Complex plugins which rely on plexus/sisu to do some custom injection
> > > would
> > > > have to be changed to do their own DI, maybe using a simple Guice
> > setup.
> > > >
> > > > If that sounds like too big a change for those plugins, we may be
> able
> > to
> > > > add a flag on the mojo descriptor so that those v4-enabled mojos
> would
> > > > trigger a DI injection on behalf of the plugin. But if we have to
> > > > implement something like that, I would go for a plain CDI-like api,
> > > either
> > > > using guice or another DI library supporting the javax.inject
> package,
> > or
> > > > rather the jakarta.inject package, as it would be nice to switch to
> the
> > > > jakarta version at the same time. Or maybe even plexus if we really
> > need
> > > > to, but with a limited scope, i.e. no visibility on the maven
> > components,
> > > > so that plugins are better decoupled from maven-core.
> > > >
> > > > Thoughts ?
> > > >
> > > > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> > > écrit
> > > > :
> > > >
> > > > > I do agree that debugging the provisioning side is *very*
> complicated
> > > > when
> > > > > there's a problem.
> > > > > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > > > framework,
> > > > > at least for simple plugins.
> > > > > However, I definitely don't think pushing OSGi to plugins would be
> a
> > > good
> > > > > idea : the cost and burden on plugin developers would outweigh the
> > > > benefits.
> > > > >
> > > > > For extensions, and for maven itself, that is a different story
> > though.
> > > > > Maven and extensions could definitely benefit from OSGi, but this
> > would
> > > > be
> > > > > a complete breakage and it would be hard to keep some level of
> > > > > compatibility.
> > > > >
> > > > > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> > mail@laeubi-soft.de>
> > > a
> > > > > écrit :
> > > > >
> > > > >> > Guess classrealm is fine for maven, it does not bring much
> issues
> > > > >>
> > > > >> As long as it works, maybe, maybe even if you write a simple maven
> > > > >> plugin, but for any more complex it is just a complete mess.
> > > > >>
> > > > >> Last time I asked on the mailing list how to debug that stuff ...
> > > > >> complete silence ...
> > > > >>
> > > > >> Today I tried to refactor the name of one module of a more complex
> > > > >> maven-plugin (with core extension), now I end up with
> > > > >>
> > > > >> org.apache.maven.InternalErrorException: Internal error:
> > > > >> com.google.inject.ProvisionException: Unable to provision, see the
> > > > >> following errors:
> > > > >> 1) No implementation for org.eclipse.aether.RepositorySystem was
> > > bound.
> > > > >>
> > > > >> A whole bunch of stack trace but not a little info why the *****
> it
> > is
> > > > >> not happy. Now I need to add random "exportedArtifact" /
> > > > >> "exportedPackage" stuff to hope finding out where it has lost a
> > > > >> transitive dependency, also here absolutely no documentation what
> > this
> > > > >> is supposed to do/work exactly beside some introduction that these
> > xml
> > > > >> tags exits and reading the code... or probably add maven-compat
> > > > >> anywhere... or change provided to compile scope (even maven is
> > jelling
> > > > >> at me that's bad and I will be punished soon)... not counting the
> > many
> > > > >> times where I messed up the realms because I accidentally trying
> to
> > > use
> > > > >> XppDom objects in extensions and plugins and something between got
> > > > >> messed up.
> > > > >>
> > > > >> With OSGi i get clear errors for missing requirements, I can
> clearly
> > > > >> share API (or declare I don't want to share it) and can reliable
> use
> > > it
> > > > >> without classlaoding problems.
> > > > >> If one wan't can even implement service filtering that would hide
> > all
> > > > >> "illegal implemented API" ... and you can even make sure API is
> > > > >> (backward) compatible with implementation without waiting for a
> > method
> > > > >> not found exception or alike.
> > > > >>
> > > > >> Beside that I find it often more clear to distinguish between API
> > > (that
> > > > >> is only implemented by the framework) and SPI (that might be
> > > implemented
> > > > >> by extenders). So probably it would be good to have maven-api and
> > > > >> maven-spi (instead of "maven-core") to make this clear.
> > > > >>
> > > > >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> > > > >> > Hi,
> > > > >> >
> > > > >> > Guess classrealm is fine for maven, it does not bring much
> issues
> > > > (less
> > > > >> > than OSGi or JPMS to be concrete), the real issue is the
> stability
> > > of
> > > > >> the
> > > > >> > exposed API.
> > > > >> > Thanks the hard work Guillaume did on that for maven 4 I guess
> it
> > is
> > > > >> mainly
> > > > >> > a matter of deciding what we do for maven 3.
> > > > >> > Due to the resources and work needed I assume we can just play
> the
> > > > >> > status-quo for maven 3.
> > > > >> > Remaining question is for maven 4 do we drop the compatibilty. I
> > > don't
> > > > >> like
> > > > >> > much the idea but a compat layer can solve that smoothly for
> maven
> > > >=
> > > > 4
> > > > >> and
> > > > >> > limit the work needed, no?
> > > > >> >
> > > > >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> > > mail@laeubi-soft.de
> > > > >
> > > > >> a
> > > > >> > écrit :
> > > > >> >
> > > > >> >> If you really like to separate API and get out of the
> > > ClassRealm-Hell
> > > > >> >> OSGi would be much more suitable:
> > > > >> >>
> > > > >> >> https://issues.apache.org/jira/browse/MNG-7518
> > > > >> >>
> > > > >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > > > >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to
> Java
> > 9
> > > or
> > > > >> 11
> > > > >> >> and
> > > > >> >>> adopt JPMS to better define its public APIs.
> > > > >> >>>
> > > > >> >>> Gary
> > > > >> >>>
> > > > >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> > tamas@cservenak.net>
> > > > >> wrote:
> > > > >> >>>
> > > > >> >>>> Yes, to define rules is quite easy, but to make our users to
> > obey
> > > > >> them
> > > > >> >> is
> > > > >> >>>> tricky :D
> > > > >> >>>>
> > > > >> >>>> In general, I guess, we should. For this reason JapiCmp has
> > been
> > > > >> used in
> > > > >> >>>> Resolver since 1.9.0 (as noted on refd page end).
> > > > >> >>>>
> > > > >> >>>> But while this was "kinda simple" to achieve in Resolver, I
> am
> > > > really
> > > > >> >>>> unsure if it is doable in Maven (sans 4 API) :(
> > > > >> >>>>
> > > > >> >>>> Ultimately, this was the whole reason for API:
> > > > >> >>>> - users "grabbed" whatever could get hold on and used
> > > > >> >>>> - maven progress was really hindered by this, as that meant
> > > > modifying
> > > > >> >> (even
> > > > >> >>>> internal) interfaces without breaking clients was impossible,
> > so
> > > we
> > > > >> went
> > > > >> >>>> with tricks, and more tricks and even more tricks that now
> pays
> > > > back.
> > > > >> >>>>
> > > > >> >>>> The other day we had a question on ML about 4-alpha
> > compatibility
> > > > >> >> breakage,
> > > > >> >>>> and from mail it was clear that the package of the referred
> > class
> > > > was
> > > > >> >>>> having "internal" in it. I mean, developers should really
> take
> > > care
> > > > >> of
> > > > >> >> what
> > > > >> >>>> they import.
> > > > >> >>>>
> > > > >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
> > > > >> compilation
> > > > >> >>>> against "encapsulated" internal classes....
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> > > > >> >>>>
> > > > >> >>>> T
> > > > >> >>>>
> > > > >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> > > kwin@apache.org>
> > > > >> >> wrote:
> > > > >> >>>>
> > > > >> >>>>> I guess this is the easy part, the tricky question remains:
> Do
> > > we
> > > > >> need
> > > > >> >> to
> > > > >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> > > > >> backwards
> > > > >> >>>>> compatible until we reach 4.100/5.0/whatever?
> > > > >> >>>>>
> > > > >> >>>>> This wasn't handled consistently in master till now, e.g.
> the
> > > > >> classes
> > > > >> >>>>> generated from
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > > > >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> > > > >> >>>>> My change in
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > > > >> >>>>> was not backwards compatible (removed a method on an
> interface
> > > > which
> > > > >> >> may
> > > > >> >>>>> have been implemented by extensions...)
> > > > >> >>>>>
> > > > >> >>>>> Konrad
> > > > >> >>>>>
> > > > >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > > > >> >>>>>> Unsure we want to deprecate all of Maven :)
> > > > >> >>>>>>
> > > > >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users
> can
> > > > grab"
> > > > >> >>>> sadly,
> > > > >> >>>>>> and is probably our major source of problems and reason we
> > > > started
> > > > >> >>>> Maven
> > > > >> >>>>> 4
> > > > >> >>>>>> API.
> > > > >> >>>>>>
> > > > >> >>>>>> IMO, I'd consider them as "whole", and just say "starting
> > with
> > > > >> Maven
> > > > >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> > NOT
> > > > >> >>>>> ACCESSIBLE
> > > > >> >>>>>> ANYMORE FROM PLUGINS.
> > > > >> >>>>>> And done.
> > > > >> >>>>>>
> > > > >> >>>>>> Just as an example, here is what Maven Resolver has to say
> > > about
> > > > >> same
> > > > >> >>>>> topic
> > > > >> >>>>>> (part of not-yet-released, vote is in process 1.9.1
> version):
> > > > >> >>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > > > >> >>>>>>
> > > > >> >>>>>> HTH
> > > > >> >>>>>> T
> > > > >> >>>>>>
> > > > >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> > > > kwin@apache.org>
> > > > >> >>>>> wrote:
> > > > >> >>>>>>
> > > > >> >>>>>>> I see now there is already
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > > > >> >>>>>>> but to me the javadoc is not explicit enough. It should
> > state:
> > > > >> Only
> > > > >> >>>>> Maven
> > > > >> >>>>>>> is allowed to implement/extend types with this annotation.
> > > > >> >>>>>>>
> > > > >> >>>>>>> Konrad
> > > > >> >>>>>>>
> > > > >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > > >> >>>>>>>> Hi,
> > > > >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In
> effect
> > > > >> >>>>> everything
> > > > >> >>>>>>> somehow exposed through class loaders was considered API
> by
> > > > >> >>>>>>> plugin/extension developers.
> > > > >> >>>>>>>> For Maven 4 a completely separate API was established in
> > > > package
> > > > >> >>>>>>> “org.apache.maven.api”, but what about the old packages
> used
> > > and
> > > > >> >>>>> exported
> > > > >> >>>>>>> in Maven 3?
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> For example in the context of
> > > > >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> > > > >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> > > > evolve
> > > > >> the
> > > > >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> > > > >> >>>>>>>> We already figured out that this particular package
> > (although
> > > > not
> > > > >> >>>>> part
> > > > >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well
> as
> > > > Maven
> > > > >> >>>>> Plugin
> > > > >> >>>>>>> Tools, therefore this probably needs to stay backwards
> > > > compatible.
> > > > >> >>>>>>>> What about others like
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > > >> >>>>> ?
> > > > >> >>>>>>> <
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > > >> >>>>>>> ?>
> > > > >> >>>>>>>> This interface should IMHO never been implemented outside
> > > Maven
> > > > >> >>>> Core
> > > > >> >>>>> but
> > > > >> >>>>>>> in fact it was exposed to all plugins/extensions (via
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > >> >>>>>>> <
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > >> >>>>>>>> ).
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> There are three options coming to my mind:
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> > create
> > > > new
> > > > >> >>>> ones
> > > > >> >>>>>>> for Maven 4 which are not exported!
> > > > >> >>>>>>>> 2. Modify the existing interfaces in a backwards
> compatible
> > > way
> > > > >> >>>> (but
> > > > >> >>>>>>> somehow add a marker that they should not be implemented
> > > outside
> > > > >> >>>> core)
> > > > >> >>>>>>>> 3. Modify the existing interfaces in a backwards
> > compatible
> > > > way
> > > > >> >>>> (but
> > > > >> >>>>>>> somehow add a marker that they should not be implemented
> > > outside
> > > > >> >>>> core)
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> For all three options we somehow need to come up with a
> > list
> > > of
> > > > >> >>>>>>> classes/interfaces currently being exported through the
> API
> > > > class
> > > > >> >>>>> loader,
> > > > >> >>>>>>> which should be considered private and agree on an
> > > > >> Annotation/Javadoc
> > > > >> >>>>> for
> > > > >> >>>>>>> that (something like
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > > >> >>>>>>> <
> > > > >> >>>>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>
> > > > >>
> > > >
> > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > > >> >>>>>>
> > > > >> >>>>>>> or
> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> > > <
> > > > >> >>>>>>>
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> WDYT?
> > > > >> >>>>>>>>
> > > > >> >>>>>>>> Konrad
> > > > >> >>>>>>>>
> > > > >> >>>>>>>>
> > > > >> >>>>>>>
> > > > >> >>>>>>>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> >>>>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> > > > >> >>>>>>>
> > > > >> >>>>>>>
> > > > >> >>>>>>
> > > > >> >>>>>
> > > > >> >>>>>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >> >>>>>
> > > > >> >>>>>
> > > > >> >>>>
> > > > >> >>>
> > > > >> >>
> > > > >> >>
> > > ---------------------------------------------------------------------
> > > > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> > ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > >
> > > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Tamás Cservenák <ta...@cservenak.net>.
No, I don't think so, the "capabilities" is just a "dream" piggybacked onto
your story :)
All in all, I think a flag but with reversed logic would be good: default
is remain as-is (maven DI), and if flipped, then plugin DI.
But again, "plugin DI" would not make much sense, if core still exposes all
of javax.inject, does it?
For me the two are somehow connected => "capabilities"
T
On Fri, Nov 18, 2022 at 8:59 PM Guillaume Nodet <gn...@apache.org> wrote:
> You misunderstood me.
> I wasn't thinking about changing the way the classloader is built, just the
> way the dependency injection mechanism is done for plugins (and/or
> maven-core).
>
> Le ven. 18 nov. 2022 à 18:35, Tamás Cservenák <ta...@cservenak.net> a
> écrit :
>
> > Howdy,
> >
> > Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> > downloads the whole world", at least latest plugins by putting Maven and
> > friends in provided scope will not download dozens of versions of
> > maven-core and friends... If we do this, at one point we would end up
> with
> > plugins downloading dozens of DI container (or their versions), as even
> ASF
> > plugins would not be in "lockstep".
> >
> > OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag
> that
> > would say maven "I will be in charge of my components" (defaults to
> false,
> > Maven behaves as today). When true, it would mean Mojo wants to
> > bootstrap some DI/whatever container of its own, and then, for plugins
> like
> > these, Maven could even "narrow" the list of exported classes? (like
> > javax.inject?)
> >
> > T
> >
> > On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> > > Following up on my previous response, and in a more realistic way than
> > > switching to OSGi, I wonder if we should let maven 4 plugins do their
> own
> > > DI injection and only care about the mojos, i.e. not rely on
> sisu/plexus
> > to
> > > create and inject the mojo. Mojos using the v4 api do not need to be
> > > injected with other components from maven, they should all come from
> the
> > > api and should be retrieved using Session.getService(xx), or simply
> using
> > > session's shortcut methods. The injection of Project and Session is
> not
> > > controlled by sisu. For the ComponentConfigurator, we could change the
> > mojo
> > > descriptor to have the full configuration class name for mojos that
> > require
> > > custom configuration injection, the plugin manager being in charge of
> > > instantiating this class and using it as a ComponentConfigurator (which
> > is
> > > not part yet of the api btw).
> > >
> > > Complex plugins which rely on plexus/sisu to do some custom injection
> > would
> > > have to be changed to do their own DI, maybe using a simple Guice
> setup.
> > >
> > > If that sounds like too big a change for those plugins, we may be able
> to
> > > add a flag on the mojo descriptor so that those v4-enabled mojos would
> > > trigger a DI injection on behalf of the plugin. But if we have to
> > > implement something like that, I would go for a plain CDI-like api,
> > either
> > > using guice or another DI library supporting the javax.inject package,
> or
> > > rather the jakarta.inject package, as it would be nice to switch to the
> > > jakarta version at the same time. Or maybe even plexus if we really
> need
> > > to, but with a limited scope, i.e. no visibility on the maven
> components,
> > > so that plugins are better decoupled from maven-core.
> > >
> > > Thoughts ?
> > >
> > > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> > écrit
> > > :
> > >
> > > > I do agree that debugging the provisioning side is *very* complicated
> > > when
> > > > there's a problem.
> > > > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > > framework,
> > > > at least for simple plugins.
> > > > However, I definitely don't think pushing OSGi to plugins would be a
> > good
> > > > idea : the cost and burden on plugin developers would outweigh the
> > > benefits.
> > > >
> > > > For extensions, and for maven itself, that is a different story
> though.
> > > > Maven and extensions could definitely benefit from OSGi, but this
> would
> > > be
> > > > a complete breakage and it would be hard to keep some level of
> > > > compatibility.
> > > >
> > > > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> mail@laeubi-soft.de>
> > a
> > > > écrit :
> > > >
> > > >> > Guess classrealm is fine for maven, it does not bring much issues
> > > >>
> > > >> As long as it works, maybe, maybe even if you write a simple maven
> > > >> plugin, but for any more complex it is just a complete mess.
> > > >>
> > > >> Last time I asked on the mailing list how to debug that stuff ...
> > > >> complete silence ...
> > > >>
> > > >> Today I tried to refactor the name of one module of a more complex
> > > >> maven-plugin (with core extension), now I end up with
> > > >>
> > > >> org.apache.maven.InternalErrorException: Internal error:
> > > >> com.google.inject.ProvisionException: Unable to provision, see the
> > > >> following errors:
> > > >> 1) No implementation for org.eclipse.aether.RepositorySystem was
> > bound.
> > > >>
> > > >> A whole bunch of stack trace but not a little info why the ***** it
> is
> > > >> not happy. Now I need to add random "exportedArtifact" /
> > > >> "exportedPackage" stuff to hope finding out where it has lost a
> > > >> transitive dependency, also here absolutely no documentation what
> this
> > > >> is supposed to do/work exactly beside some introduction that these
> xml
> > > >> tags exits and reading the code... or probably add maven-compat
> > > >> anywhere... or change provided to compile scope (even maven is
> jelling
> > > >> at me that's bad and I will be punished soon)... not counting the
> many
> > > >> times where I messed up the realms because I accidentally trying to
> > use
> > > >> XppDom objects in extensions and plugins and something between got
> > > >> messed up.
> > > >>
> > > >> With OSGi i get clear errors for missing requirements, I can clearly
> > > >> share API (or declare I don't want to share it) and can reliable use
> > it
> > > >> without classlaoding problems.
> > > >> If one wan't can even implement service filtering that would hide
> all
> > > >> "illegal implemented API" ... and you can even make sure API is
> > > >> (backward) compatible with implementation without waiting for a
> method
> > > >> not found exception or alike.
> > > >>
> > > >> Beside that I find it often more clear to distinguish between API
> > (that
> > > >> is only implemented by the framework) and SPI (that might be
> > implemented
> > > >> by extenders). So probably it would be good to have maven-api and
> > > >> maven-spi (instead of "maven-core") to make this clear.
> > > >>
> > > >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> > > >> > Hi,
> > > >> >
> > > >> > Guess classrealm is fine for maven, it does not bring much issues
> > > (less
> > > >> > than OSGi or JPMS to be concrete), the real issue is the stability
> > of
> > > >> the
> > > >> > exposed API.
> > > >> > Thanks the hard work Guillaume did on that for maven 4 I guess it
> is
> > > >> mainly
> > > >> > a matter of deciding what we do for maven 3.
> > > >> > Due to the resources and work needed I assume we can just play the
> > > >> > status-quo for maven 3.
> > > >> > Remaining question is for maven 4 do we drop the compatibilty. I
> > don't
> > > >> like
> > > >> > much the idea but a compat layer can solve that smoothly for maven
> > >=
> > > 4
> > > >> and
> > > >> > limit the work needed, no?
> > > >> >
> > > >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> > mail@laeubi-soft.de
> > > >
> > > >> a
> > > >> > écrit :
> > > >> >
> > > >> >> If you really like to separate API and get out of the
> > ClassRealm-Hell
> > > >> >> OSGi would be much more suitable:
> > > >> >>
> > > >> >> https://issues.apache.org/jira/browse/MNG-7518
> > > >> >>
> > > >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > > >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java
> 9
> > or
> > > >> 11
> > > >> >> and
> > > >> >>> adopt JPMS to better define its public APIs.
> > > >> >>>
> > > >> >>> Gary
> > > >> >>>
> > > >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> tamas@cservenak.net>
> > > >> wrote:
> > > >> >>>
> > > >> >>>> Yes, to define rules is quite easy, but to make our users to
> obey
> > > >> them
> > > >> >> is
> > > >> >>>> tricky :D
> > > >> >>>>
> > > >> >>>> In general, I guess, we should. For this reason JapiCmp has
> been
> > > >> used in
> > > >> >>>> Resolver since 1.9.0 (as noted on refd page end).
> > > >> >>>>
> > > >> >>>> But while this was "kinda simple" to achieve in Resolver, I am
> > > really
> > > >> >>>> unsure if it is doable in Maven (sans 4 API) :(
> > > >> >>>>
> > > >> >>>> Ultimately, this was the whole reason for API:
> > > >> >>>> - users "grabbed" whatever could get hold on and used
> > > >> >>>> - maven progress was really hindered by this, as that meant
> > > modifying
> > > >> >> (even
> > > >> >>>> internal) interfaces without breaking clients was impossible,
> so
> > we
> > > >> went
> > > >> >>>> with tricks, and more tricks and even more tricks that now pays
> > > back.
> > > >> >>>>
> > > >> >>>> The other day we had a question on ML about 4-alpha
> compatibility
> > > >> >> breakage,
> > > >> >>>> and from mail it was clear that the package of the referred
> class
> > > was
> > > >> >>>> having "internal" in it. I mean, developers should really take
> > care
> > > >> of
> > > >> >> what
> > > >> >>>> they import.
> > > >> >>>>
> > > >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
> > > >> compilation
> > > >> >>>> against "encapsulated" internal classes....
> > > >> >>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> > > >> >>>>
> > > >> >>>> T
> > > >> >>>>
> > > >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> > kwin@apache.org>
> > > >> >> wrote:
> > > >> >>>>
> > > >> >>>>> I guess this is the easy part, the tricky question remains: Do
> > we
> > > >> need
> > > >> >> to
> > > >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> > > >> backwards
> > > >> >>>>> compatible until we reach 4.100/5.0/whatever?
> > > >> >>>>>
> > > >> >>>>> This wasn't handled consistently in master till now, e.g. the
> > > >> classes
> > > >> >>>>> generated from
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > > >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> > > >> >>>>> My change in
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > > >> >>>>> was not backwards compatible (removed a method on an interface
> > > which
> > > >> >> may
> > > >> >>>>> have been implemented by extensions...)
> > > >> >>>>>
> > > >> >>>>> Konrad
> > > >> >>>>>
> > > >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > > >> >>>>>> Unsure we want to deprecate all of Maven :)
> > > >> >>>>>>
> > > >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> > > grab"
> > > >> >>>> sadly,
> > > >> >>>>>> and is probably our major source of problems and reason we
> > > started
> > > >> >>>> Maven
> > > >> >>>>> 4
> > > >> >>>>>> API.
> > > >> >>>>>>
> > > >> >>>>>> IMO, I'd consider them as "whole", and just say "starting
> with
> > > >> Maven
> > > >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> NOT
> > > >> >>>>> ACCESSIBLE
> > > >> >>>>>> ANYMORE FROM PLUGINS.
> > > >> >>>>>> And done.
> > > >> >>>>>>
> > > >> >>>>>> Just as an example, here is what Maven Resolver has to say
> > about
> > > >> same
> > > >> >>>>> topic
> > > >> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> > > >> >>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > > >> >>>>>>
> > > >> >>>>>> HTH
> > > >> >>>>>> T
> > > >> >>>>>>
> > > >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> > > kwin@apache.org>
> > > >> >>>>> wrote:
> > > >> >>>>>>
> > > >> >>>>>>> I see now there is already
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > > >> >>>>>>> but to me the javadoc is not explicit enough. It should
> state:
> > > >> Only
> > > >> >>>>> Maven
> > > >> >>>>>>> is allowed to implement/extend types with this annotation.
> > > >> >>>>>>>
> > > >> >>>>>>> Konrad
> > > >> >>>>>>>
> > > >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > >> >>>>>>>> Hi,
> > > >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> > > >> >>>>> everything
> > > >> >>>>>>> somehow exposed through class loaders was considered API by
> > > >> >>>>>>> plugin/extension developers.
> > > >> >>>>>>>> For Maven 4 a completely separate API was established in
> > > package
> > > >> >>>>>>> “org.apache.maven.api”, but what about the old packages used
> > and
> > > >> >>>>> exported
> > > >> >>>>>>> in Maven 3?
> > > >> >>>>>>>>
> > > >> >>>>>>>> For example in the context of
> > > >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> > > >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> > > evolve
> > > >> the
> > > >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> > > >> >>>>>>>> We already figured out that this particular package
> (although
> > > not
> > > >> >>>>> part
> > > >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> > > Maven
> > > >> >>>>> Plugin
> > > >> >>>>>>> Tools, therefore this probably needs to stay backwards
> > > compatible.
> > > >> >>>>>>>> What about others like
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > >> >>>>> ?
> > > >> >>>>>>> <
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > >> >>>>>>> ?>
> > > >> >>>>>>>> This interface should IMHO never been implemented outside
> > Maven
> > > >> >>>> Core
> > > >> >>>>> but
> > > >> >>>>>>> in fact it was exposed to all plugins/extensions (via
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > >> >>>>>>> <
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > >> >>>>>>>> ).
> > > >> >>>>>>>>
> > > >> >>>>>>>> There are three options coming to my mind:
> > > >> >>>>>>>>
> > > >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> create
> > > new
> > > >> >>>> ones
> > > >> >>>>>>> for Maven 4 which are not exported!
> > > >> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> > way
> > > >> >>>> (but
> > > >> >>>>>>> somehow add a marker that they should not be implemented
> > outside
> > > >> >>>> core)
> > > >> >>>>>>>> 3. Modify the existing interfaces in a backwards
> compatible
> > > way
> > > >> >>>> (but
> > > >> >>>>>>> somehow add a marker that they should not be implemented
> > outside
> > > >> >>>> core)
> > > >> >>>>>>>>
> > > >> >>>>>>>> For all three options we somehow need to come up with a
> list
> > of
> > > >> >>>>>>> classes/interfaces currently being exported through the API
> > > class
> > > >> >>>>> loader,
> > > >> >>>>>>> which should be considered private and agree on an
> > > >> Annotation/Javadoc
> > > >> >>>>> for
> > > >> >>>>>>> that (something like
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > >> >>>>>>> <
> > > >> >>>>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>
> > > >>
> > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > >> >>>>>>
> > > >> >>>>>>> or
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> > <
> > > >> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > > >> >>>>>>>>
> > > >> >>>>>>>> WDYT?
> > > >> >>>>>>>>
> > > >> >>>>>>>> Konrad
> > > >> >>>>>>>>
> > > >> >>>>>>>>
> > > >> >>>>>>>
> > > >> >>>>>>>
> > > >>
> ---------------------------------------------------------------------
> > > >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >>>>>>>
> > > >> >>>>>>>
> > > >> >>>>>>
> > > >> >>>>>
> > > >> >>>>>
> > > >>
> ---------------------------------------------------------------------
> > > >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >>>>>
> > > >> >>>>>
> > > >> >>>>
> > > >> >>>
> > > >> >>
> > > >> >>
> > ---------------------------------------------------------------------
> > > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >> >>
> > > >> >>
> > > >> >
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >>
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Guillaume Nodet <gn...@apache.org>.
You misunderstood me.
I wasn't thinking about changing the way the classloader is built, just the
way the dependency injection mechanism is done for plugins (and/or
maven-core).
Le ven. 18 nov. 2022 à 18:35, Tamás Cservenák <ta...@cservenak.net> a
écrit :
> Howdy,
>
> Am -1 on this. We just reached the point to (somewhat) undo the "Maven
> downloads the whole world", at least latest plugins by putting Maven and
> friends in provided scope will not download dozens of versions of
> maven-core and friends... If we do this, at one point we would end up with
> plugins downloading dozens of DI container (or their versions), as even ASF
> plugins would not be in "lockstep".
>
> OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag that
> would say maven "I will be in charge of my components" (defaults to false,
> Maven behaves as today). When true, it would mean Mojo wants to
> bootstrap some DI/whatever container of its own, and then, for plugins like
> these, Maven could even "narrow" the list of exported classes? (like
> javax.inject?)
>
> T
>
> On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > Following up on my previous response, and in a more realistic way than
> > switching to OSGi, I wonder if we should let maven 4 plugins do their own
> > DI injection and only care about the mojos, i.e. not rely on sisu/plexus
> to
> > create and inject the mojo. Mojos using the v4 api do not need to be
> > injected with other components from maven, they should all come from the
> > api and should be retrieved using Session.getService(xx), or simply using
> > session's shortcut methods. The injection of Project and Session is not
> > controlled by sisu. For the ComponentConfigurator, we could change the
> mojo
> > descriptor to have the full configuration class name for mojos that
> require
> > custom configuration injection, the plugin manager being in charge of
> > instantiating this class and using it as a ComponentConfigurator (which
> is
> > not part yet of the api btw).
> >
> > Complex plugins which rely on plexus/sisu to do some custom injection
> would
> > have to be changed to do their own DI, maybe using a simple Guice setup.
> >
> > If that sounds like too big a change for those plugins, we may be able to
> > add a flag on the mojo descriptor so that those v4-enabled mojos would
> > trigger a DI injection on behalf of the plugin. But if we have to
> > implement something like that, I would go for a plain CDI-like api,
> either
> > using guice or another DI library supporting the javax.inject package, or
> > rather the jakarta.inject package, as it would be nice to switch to the
> > jakarta version at the same time. Or maybe even plexus if we really need
> > to, but with a limited scope, i.e. no visibility on the maven components,
> > so that plugins are better decoupled from maven-core.
> >
> > Thoughts ?
> >
> > Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a
> écrit
> > :
> >
> > > I do agree that debugging the provisioning side is *very* complicated
> > when
> > > there's a problem.
> > > I'd be happy to get rid of sisu/plexus and use a more simple DI
> > framework,
> > > at least for simple plugins.
> > > However, I definitely don't think pushing OSGi to plugins would be a
> good
> > > idea : the cost and burden on plugin developers would outweigh the
> > benefits.
> > >
> > > For extensions, and for maven itself, that is a different story though.
> > > Maven and extensions could definitely benefit from OSGi, but this would
> > be
> > > a complete breakage and it would be hard to keep some level of
> > > compatibility.
> > >
> > > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> > > écrit :
> > >
> > >> > Guess classrealm is fine for maven, it does not bring much issues
> > >>
> > >> As long as it works, maybe, maybe even if you write a simple maven
> > >> plugin, but for any more complex it is just a complete mess.
> > >>
> > >> Last time I asked on the mailing list how to debug that stuff ...
> > >> complete silence ...
> > >>
> > >> Today I tried to refactor the name of one module of a more complex
> > >> maven-plugin (with core extension), now I end up with
> > >>
> > >> org.apache.maven.InternalErrorException: Internal error:
> > >> com.google.inject.ProvisionException: Unable to provision, see the
> > >> following errors:
> > >> 1) No implementation for org.eclipse.aether.RepositorySystem was
> bound.
> > >>
> > >> A whole bunch of stack trace but not a little info why the ***** it is
> > >> not happy. Now I need to add random "exportedArtifact" /
> > >> "exportedPackage" stuff to hope finding out where it has lost a
> > >> transitive dependency, also here absolutely no documentation what this
> > >> is supposed to do/work exactly beside some introduction that these xml
> > >> tags exits and reading the code... or probably add maven-compat
> > >> anywhere... or change provided to compile scope (even maven is jelling
> > >> at me that's bad and I will be punished soon)... not counting the many
> > >> times where I messed up the realms because I accidentally trying to
> use
> > >> XppDom objects in extensions and plugins and something between got
> > >> messed up.
> > >>
> > >> With OSGi i get clear errors for missing requirements, I can clearly
> > >> share API (or declare I don't want to share it) and can reliable use
> it
> > >> without classlaoding problems.
> > >> If one wan't can even implement service filtering that would hide all
> > >> "illegal implemented API" ... and you can even make sure API is
> > >> (backward) compatible with implementation without waiting for a method
> > >> not found exception or alike.
> > >>
> > >> Beside that I find it often more clear to distinguish between API
> (that
> > >> is only implemented by the framework) and SPI (that might be
> implemented
> > >> by extenders). So probably it would be good to have maven-api and
> > >> maven-spi (instead of "maven-core") to make this clear.
> > >>
> > >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> > >> > Hi,
> > >> >
> > >> > Guess classrealm is fine for maven, it does not bring much issues
> > (less
> > >> > than OSGi or JPMS to be concrete), the real issue is the stability
> of
> > >> the
> > >> > exposed API.
> > >> > Thanks the hard work Guillaume did on that for maven 4 I guess it is
> > >> mainly
> > >> > a matter of deciding what we do for maven 3.
> > >> > Due to the resources and work needed I assume we can just play the
> > >> > status-quo for maven 3.
> > >> > Remaining question is for maven 4 do we drop the compatibilty. I
> don't
> > >> like
> > >> > much the idea but a compat layer can solve that smoothly for maven
> >=
> > 4
> > >> and
> > >> > limit the work needed, no?
> > >> >
> > >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> mail@laeubi-soft.de
> > >
> > >> a
> > >> > écrit :
> > >> >
> > >> >> If you really like to separate API and get out of the
> ClassRealm-Hell
> > >> >> OSGi would be much more suitable:
> > >> >>
> > >> >> https://issues.apache.org/jira/browse/MNG-7518
> > >> >>
> > >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
> or
> > >> 11
> > >> >> and
> > >> >>> adopt JPMS to better define its public APIs.
> > >> >>>
> > >> >>> Gary
> > >> >>>
> > >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
> > >> wrote:
> > >> >>>
> > >> >>>> Yes, to define rules is quite easy, but to make our users to obey
> > >> them
> > >> >> is
> > >> >>>> tricky :D
> > >> >>>>
> > >> >>>> In general, I guess, we should. For this reason JapiCmp has been
> > >> used in
> > >> >>>> Resolver since 1.9.0 (as noted on refd page end).
> > >> >>>>
> > >> >>>> But while this was "kinda simple" to achieve in Resolver, I am
> > really
> > >> >>>> unsure if it is doable in Maven (sans 4 API) :(
> > >> >>>>
> > >> >>>> Ultimately, this was the whole reason for API:
> > >> >>>> - users "grabbed" whatever could get hold on and used
> > >> >>>> - maven progress was really hindered by this, as that meant
> > modifying
> > >> >> (even
> > >> >>>> internal) interfaces without breaking clients was impossible, so
> we
> > >> went
> > >> >>>> with tricks, and more tricks and even more tricks that now pays
> > back.
> > >> >>>>
> > >> >>>> The other day we had a question on ML about 4-alpha compatibility
> > >> >> breakage,
> > >> >>>> and from mail it was clear that the package of the referred class
> > was
> > >> >>>> having "internal" in it. I mean, developers should really take
> care
> > >> of
> > >> >> what
> > >> >>>> they import.
> > >> >>>>
> > >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
> > >> compilation
> > >> >>>> against "encapsulated" internal classes....
> > >> >>>>
> > >> >>>>
> > >> >>
> > >>
> >
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> > >> >>>>
> > >> >>>> T
> > >> >>>>
> > >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> kwin@apache.org>
> > >> >> wrote:
> > >> >>>>
> > >> >>>>> I guess this is the easy part, the tricky question remains: Do
> we
> > >> need
> > >> >> to
> > >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> > >> backwards
> > >> >>>>> compatible until we reach 4.100/5.0/whatever?
> > >> >>>>>
> > >> >>>>> This wasn't handled consistently in master till now, e.g. the
> > >> classes
> > >> >>>>> generated from
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> > >> >>>>> My change in
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > >> >>>>> was not backwards compatible (removed a method on an interface
> > which
> > >> >> may
> > >> >>>>> have been implemented by extensions...)
> > >> >>>>>
> > >> >>>>> Konrad
> > >> >>>>>
> > >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > >> >>>>>> Unsure we want to deprecate all of Maven :)
> > >> >>>>>>
> > >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> > grab"
> > >> >>>> sadly,
> > >> >>>>>> and is probably our major source of problems and reason we
> > started
> > >> >>>> Maven
> > >> >>>>> 4
> > >> >>>>>> API.
> > >> >>>>>>
> > >> >>>>>> IMO, I'd consider them as "whole", and just say "starting with
> > >> Maven
> > >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> > >> >>>>> ACCESSIBLE
> > >> >>>>>> ANYMORE FROM PLUGINS.
> > >> >>>>>> And done.
> > >> >>>>>>
> > >> >>>>>> Just as an example, here is what Maven Resolver has to say
> about
> > >> same
> > >> >>>>> topic
> > >> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > >> >>>>>>
> > >> >>>>>> HTH
> > >> >>>>>> T
> > >> >>>>>>
> > >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> > kwin@apache.org>
> > >> >>>>> wrote:
> > >> >>>>>>
> > >> >>>>>>> I see now there is already
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > >> >>>>>>> but to me the javadoc is not explicit enough. It should state:
> > >> Only
> > >> >>>>> Maven
> > >> >>>>>>> is allowed to implement/extend types with this annotation.
> > >> >>>>>>>
> > >> >>>>>>> Konrad
> > >> >>>>>>>
> > >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > >> >>>>>>>> Hi,
> > >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> > >> >>>>> everything
> > >> >>>>>>> somehow exposed through class loaders was considered API by
> > >> >>>>>>> plugin/extension developers.
> > >> >>>>>>>> For Maven 4 a completely separate API was established in
> > package
> > >> >>>>>>> “org.apache.maven.api”, but what about the old packages used
> and
> > >> >>>>> exported
> > >> >>>>>>> in Maven 3?
> > >> >>>>>>>>
> > >> >>>>>>>> For example in the context of
> > >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> > >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> > evolve
> > >> the
> > >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> > >> >>>>>>>> We already figured out that this particular package (although
> > not
> > >> >>>>> part
> > >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> > Maven
> > >> >>>>> Plugin
> > >> >>>>>>> Tools, therefore this probably needs to stay backwards
> > compatible.
> > >> >>>>>>>> What about others like
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > >> >>>>> ?
> > >> >>>>>>> <
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > >> >>>>>>> ?>
> > >> >>>>>>>> This interface should IMHO never been implemented outside
> Maven
> > >> >>>> Core
> > >> >>>>> but
> > >> >>>>>>> in fact it was exposed to all plugins/extensions (via
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >> >>>>>>> <
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >> >>>>>>>> ).
> > >> >>>>>>>>
> > >> >>>>>>>> There are three options coming to my mind:
> > >> >>>>>>>>
> > >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
> > new
> > >> >>>> ones
> > >> >>>>>>> for Maven 4 which are not exported!
> > >> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> way
> > >> >>>> (but
> > >> >>>>>>> somehow add a marker that they should not be implemented
> outside
> > >> >>>> core)
> > >> >>>>>>>> 3. Modify the existing interfaces in a backwards compatible
> > way
> > >> >>>> (but
> > >> >>>>>>> somehow add a marker that they should not be implemented
> outside
> > >> >>>> core)
> > >> >>>>>>>>
> > >> >>>>>>>> For all three options we somehow need to come up with a list
> of
> > >> >>>>>>> classes/interfaces currently being exported through the API
> > class
> > >> >>>>> loader,
> > >> >>>>>>> which should be considered private and agree on an
> > >> Annotation/Javadoc
> > >> >>>>> for
> > >> >>>>>>> that (something like
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >> >>>>>>> <
> > >> >>>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>
> > >>
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >> >>>>>>
> > >> >>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> <
> > >> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > >> >>>>>>>>
> > >> >>>>>>>> WDYT?
> > >> >>>>>>>>
> > >> >>>>>>>> Konrad
> > >> >>>>>>>>
> > >> >>>>>>>>
> > >> >>>>>>>
> > >> >>>>>>>
> > >> ---------------------------------------------------------------------
> > >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>>>>>>
> > >> >>>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>>
> > >> ---------------------------------------------------------------------
> > >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> >> For additional commands, e-mail: dev-help@maven.apache.org
> > >> >>
> > >> >>
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
--
------------------------
Guillaume Nodet
Re: Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
Am -1 on this. We just reached the point to (somewhat) undo the "Maven
downloads the whole world", at least latest plugins by putting Maven and
friends in provided scope will not download dozens of versions of
maven-core and friends... If we do this, at one point we would end up with
plugins downloading dozens of DI container (or their versions), as even ASF
plugins would not be in "lockstep".
OTOH, that said, I like the idea of a flag, but I'd reverse it: a flag that
would say maven "I will be in charge of my components" (defaults to false,
Maven behaves as today). When true, it would mean Mojo wants to
bootstrap some DI/whatever container of its own, and then, for plugins like
these, Maven could even "narrow" the list of exported classes? (like
javax.inject?)
T
On Fri, Nov 18, 2022 at 4:57 PM Guillaume Nodet <gn...@apache.org> wrote:
> Following up on my previous response, and in a more realistic way than
> switching to OSGi, I wonder if we should let maven 4 plugins do their own
> DI injection and only care about the mojos, i.e. not rely on sisu/plexus to
> create and inject the mojo. Mojos using the v4 api do not need to be
> injected with other components from maven, they should all come from the
> api and should be retrieved using Session.getService(xx), or simply using
> session's shortcut methods. The injection of Project and Session is not
> controlled by sisu. For the ComponentConfigurator, we could change the mojo
> descriptor to have the full configuration class name for mojos that require
> custom configuration injection, the plugin manager being in charge of
> instantiating this class and using it as a ComponentConfigurator (which is
> not part yet of the api btw).
>
> Complex plugins which rely on plexus/sisu to do some custom injection would
> have to be changed to do their own DI, maybe using a simple Guice setup.
>
> If that sounds like too big a change for those plugins, we may be able to
> add a flag on the mojo descriptor so that those v4-enabled mojos would
> trigger a DI injection on behalf of the plugin. But if we have to
> implement something like that, I would go for a plain CDI-like api, either
> using guice or another DI library supporting the javax.inject package, or
> rather the jakarta.inject package, as it would be nice to switch to the
> jakarta version at the same time. Or maybe even plexus if we really need
> to, but with a limited scope, i.e. no visibility on the maven components,
> so that plugins are better decoupled from maven-core.
>
> Thoughts ?
>
> Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a écrit
> :
>
> > I do agree that debugging the provisioning side is *very* complicated
> when
> > there's a problem.
> > I'd be happy to get rid of sisu/plexus and use a more simple DI
> framework,
> > at least for simple plugins.
> > However, I definitely don't think pushing OSGi to plugins would be a good
> > idea : the cost and burden on plugin developers would outweigh the
> benefits.
> >
> > For extensions, and for maven itself, that is a different story though.
> > Maven and extensions could definitely benefit from OSGi, but this would
> be
> > a complete breakage and it would be hard to keep some level of
> > compatibility.
> >
> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> > Guess classrealm is fine for maven, it does not bring much issues
> >>
> >> As long as it works, maybe, maybe even if you write a simple maven
> >> plugin, but for any more complex it is just a complete mess.
> >>
> >> Last time I asked on the mailing list how to debug that stuff ...
> >> complete silence ...
> >>
> >> Today I tried to refactor the name of one module of a more complex
> >> maven-plugin (with core extension), now I end up with
> >>
> >> org.apache.maven.InternalErrorException: Internal error:
> >> com.google.inject.ProvisionException: Unable to provision, see the
> >> following errors:
> >> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
> >>
> >> A whole bunch of stack trace but not a little info why the ***** it is
> >> not happy. Now I need to add random "exportedArtifact" /
> >> "exportedPackage" stuff to hope finding out where it has lost a
> >> transitive dependency, also here absolutely no documentation what this
> >> is supposed to do/work exactly beside some introduction that these xml
> >> tags exits and reading the code... or probably add maven-compat
> >> anywhere... or change provided to compile scope (even maven is jelling
> >> at me that's bad and I will be punished soon)... not counting the many
> >> times where I messed up the realms because I accidentally trying to use
> >> XppDom objects in extensions and plugins and something between got
> >> messed up.
> >>
> >> With OSGi i get clear errors for missing requirements, I can clearly
> >> share API (or declare I don't want to share it) and can reliable use it
> >> without classlaoding problems.
> >> If one wan't can even implement service filtering that would hide all
> >> "illegal implemented API" ... and you can even make sure API is
> >> (backward) compatible with implementation without waiting for a method
> >> not found exception or alike.
> >>
> >> Beside that I find it often more clear to distinguish between API (that
> >> is only implemented by the framework) and SPI (that might be implemented
> >> by extenders). So probably it would be good to have maven-api and
> >> maven-spi (instead of "maven-core") to make this clear.
> >>
> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >> > Hi,
> >> >
> >> > Guess classrealm is fine for maven, it does not bring much issues
> (less
> >> > than OSGi or JPMS to be concrete), the real issue is the stability of
> >> the
> >> > exposed API.
> >> > Thanks the hard work Guillaume did on that for maven 4 I guess it is
> >> mainly
> >> > a matter of deciding what we do for maven 3.
> >> > Due to the resources and work needed I assume we can just play the
> >> > status-quo for maven 3.
> >> > Remaining question is for maven 4 do we drop the compatibilty. I don't
> >> like
> >> > much the idea but a compat layer can solve that smoothly for maven >=
> 4
> >> and
> >> > limit the work needed, no?
> >> >
> >> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <mail@laeubi-soft.de
> >
> >> a
> >> > écrit :
> >> >
> >> >> If you really like to separate API and get out of the ClassRealm-Hell
> >> >> OSGi would be much more suitable:
> >> >>
> >> >> https://issues.apache.org/jira/browse/MNG-7518
> >> >>
> >> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or
> >> 11
> >> >> and
> >> >>> adopt JPMS to better define its public APIs.
> >> >>>
> >> >>> Gary
> >> >>>
> >> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
> >> wrote:
> >> >>>
> >> >>>> Yes, to define rules is quite easy, but to make our users to obey
> >> them
> >> >> is
> >> >>>> tricky :D
> >> >>>>
> >> >>>> In general, I guess, we should. For this reason JapiCmp has been
> >> used in
> >> >>>> Resolver since 1.9.0 (as noted on refd page end).
> >> >>>>
> >> >>>> But while this was "kinda simple" to achieve in Resolver, I am
> really
> >> >>>> unsure if it is doable in Maven (sans 4 API) :(
> >> >>>>
> >> >>>> Ultimately, this was the whole reason for API:
> >> >>>> - users "grabbed" whatever could get hold on and used
> >> >>>> - maven progress was really hindered by this, as that meant
> modifying
> >> >> (even
> >> >>>> internal) interfaces without breaking clients was impossible, so we
> >> went
> >> >>>> with tricks, and more tricks and even more tricks that now pays
> back.
> >> >>>>
> >> >>>> The other day we had a question on ML about 4-alpha compatibility
> >> >> breakage,
> >> >>>> and from mail it was clear that the package of the referred class
> was
> >> >>>> having "internal" in it. I mean, developers should really take care
> >> of
> >> >> what
> >> >>>> they import.
> >> >>>>
> >> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >> compilation
> >> >>>> against "encapsulated" internal classes....
> >> >>>>
> >> >>>>
> >> >>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >> >>>>
> >> >>>> T
> >> >>>>
> >> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
> >> >> wrote:
> >> >>>>
> >> >>>>> I guess this is the easy part, the tricky question remains: Do we
> >> need
> >> >> to
> >> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >> backwards
> >> >>>>> compatible until we reach 4.100/5.0/whatever?
> >> >>>>>
> >> >>>>> This wasn't handled consistently in master till now, e.g. the
> >> classes
> >> >>>>> generated from
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >> >>>>> My change in
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >> >>>>> was not backwards compatible (removed a method on an interface
> which
> >> >> may
> >> >>>>> have been implemented by extensions...)
> >> >>>>>
> >> >>>>> Konrad
> >> >>>>>
> >> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >> >>>>>> Unsure we want to deprecate all of Maven :)
> >> >>>>>>
> >> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> grab"
> >> >>>> sadly,
> >> >>>>>> and is probably our major source of problems and reason we
> started
> >> >>>> Maven
> >> >>>>> 4
> >> >>>>>> API.
> >> >>>>>>
> >> >>>>>> IMO, I'd consider them as "whole", and just say "starting with
> >> Maven
> >> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >> >>>>> ACCESSIBLE
> >> >>>>>> ANYMORE FROM PLUGINS.
> >> >>>>>> And done.
> >> >>>>>>
> >> >>>>>> Just as an example, here is what Maven Resolver has to say about
> >> same
> >> >>>>> topic
> >> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >> >>>>>>
> >> >>>>>> HTH
> >> >>>>>> T
> >> >>>>>>
> >> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> kwin@apache.org>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>>> I see now there is already
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >> >>>>>>> but to me the javadoc is not explicit enough. It should state:
> >> Only
> >> >>>>> Maven
> >> >>>>>>> is allowed to implement/extend types with this annotation.
> >> >>>>>>>
> >> >>>>>>> Konrad
> >> >>>>>>>
> >> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >> >>>>>>>> Hi,
> >> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >> >>>>> everything
> >> >>>>>>> somehow exposed through class loaders was considered API by
> >> >>>>>>> plugin/extension developers.
> >> >>>>>>>> For Maven 4 a completely separate API was established in
> package
> >> >>>>>>> “org.apache.maven.api”, but what about the old packages used and
> >> >>>>> exported
> >> >>>>>>> in Maven 3?
> >> >>>>>>>>
> >> >>>>>>>> For example in the context of
> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> evolve
> >> the
> >> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> >> >>>>>>>> We already figured out that this particular package (although
> not
> >> >>>>> part
> >> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> Maven
> >> >>>>> Plugin
> >> >>>>>>> Tools, therefore this probably needs to stay backwards
> compatible.
> >> >>>>>>>> What about others like
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >> >>>>> ?
> >> >>>>>>> <
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >> >>>>>>> ?>
> >> >>>>>>>> This interface should IMHO never been implemented outside Maven
> >> >>>> Core
> >> >>>>> but
> >> >>>>>>> in fact it was exposed to all plugins/extensions (via
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >> >>>>>>> <
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >> >>>>>>>> ).
> >> >>>>>>>>
> >> >>>>>>>> There are three options coming to my mind:
> >> >>>>>>>>
> >> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
> new
> >> >>>> ones
> >> >>>>>>> for Maven 4 which are not exported!
> >> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
> >> >>>> (but
> >> >>>>>>> somehow add a marker that they should not be implemented outside
> >> >>>> core)
> >> >>>>>>>> 3. Modify the existing interfaces in a backwards compatible
> way
> >> >>>> (but
> >> >>>>>>> somehow add a marker that they should not be implemented outside
> >> >>>> core)
> >> >>>>>>>>
> >> >>>>>>>> For all three options we somehow need to come up with a list of
> >> >>>>>>> classes/interfaces currently being exported through the API
> class
> >> >>>>> loader,
> >> >>>>>>> which should be considered private and agree on an
> >> Annotation/Javadoc
> >> >>>>> for
> >> >>>>>>> that (something like
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >> >>>>>>> <
> >> >>>>>>>
> >> >>>>>
> >> >>>>
> >> >>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >> >>>>>>
> >> >>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> >> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >> >>>>>>>>
> >> >>>>>>>> WDYT?
> >> >>>>>>>>
> >> >>>>>>>> Konrad
> >> >>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> >
>
> --
> ------------------------
> Guillaume Nodet
>
Mojo injection with maven 4 (was Re: Maven 3 API, backwards compatibility)
Posted by Guillaume Nodet <gn...@apache.org>.
Following up on my previous response, and in a more realistic way than
switching to OSGi, I wonder if we should let maven 4 plugins do their own
DI injection and only care about the mojos, i.e. not rely on sisu/plexus to
create and inject the mojo. Mojos using the v4 api do not need to be
injected with other components from maven, they should all come from the
api and should be retrieved using Session.getService(xx), or simply using
session's shortcut methods. The injection of Project and Session is not
controlled by sisu. For the ComponentConfigurator, we could change the mojo
descriptor to have the full configuration class name for mojos that require
custom configuration injection, the plugin manager being in charge of
instantiating this class and using it as a ComponentConfigurator (which is
not part yet of the api btw).
Complex plugins which rely on plexus/sisu to do some custom injection would
have to be changed to do their own DI, maybe using a simple Guice setup.
If that sounds like too big a change for those plugins, we may be able to
add a flag on the mojo descriptor so that those v4-enabled mojos would
trigger a DI injection on behalf of the plugin. But if we have to
implement something like that, I would go for a plain CDI-like api, either
using guice or another DI library supporting the javax.inject package, or
rather the jakarta.inject package, as it would be nice to switch to the
jakarta version at the same time. Or maybe even plexus if we really need
to, but with a limited scope, i.e. no visibility on the maven components,
so that plugins are better decoupled from maven-core.
Thoughts ?
Le jeu. 17 nov. 2022 à 17:48, Guillaume Nodet <gn...@apache.org> a écrit :
> I do agree that debugging the provisioning side is *very* complicated when
> there's a problem.
> I'd be happy to get rid of sisu/plexus and use a more simple DI framework,
> at least for simple plugins.
> However, I definitely don't think pushing OSGi to plugins would be a good
> idea : the cost and burden on plugin developers would outweigh the benefits.
>
> For extensions, and for maven itself, that is a different story though.
> Maven and extensions could definitely benefit from OSGi, but this would be
> a complete breakage and it would be hard to keep some level of
> compatibility.
>
> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> > Guess classrealm is fine for maven, it does not bring much issues
>>
>> As long as it works, maybe, maybe even if you write a simple maven
>> plugin, but for any more complex it is just a complete mess.
>>
>> Last time I asked on the mailing list how to debug that stuff ...
>> complete silence ...
>>
>> Today I tried to refactor the name of one module of a more complex
>> maven-plugin (with core extension), now I end up with
>>
>> org.apache.maven.InternalErrorException: Internal error:
>> com.google.inject.ProvisionException: Unable to provision, see the
>> following errors:
>> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>>
>> A whole bunch of stack trace but not a little info why the ***** it is
>> not happy. Now I need to add random "exportedArtifact" /
>> "exportedPackage" stuff to hope finding out where it has lost a
>> transitive dependency, also here absolutely no documentation what this
>> is supposed to do/work exactly beside some introduction that these xml
>> tags exits and reading the code... or probably add maven-compat
>> anywhere... or change provided to compile scope (even maven is jelling
>> at me that's bad and I will be punished soon)... not counting the many
>> times where I messed up the realms because I accidentally trying to use
>> XppDom objects in extensions and plugins and something between got
>> messed up.
>>
>> With OSGi i get clear errors for missing requirements, I can clearly
>> share API (or declare I don't want to share it) and can reliable use it
>> without classlaoding problems.
>> If one wan't can even implement service filtering that would hide all
>> "illegal implemented API" ... and you can even make sure API is
>> (backward) compatible with implementation without waiting for a method
>> not found exception or alike.
>>
>> Beside that I find it often more clear to distinguish between API (that
>> is only implemented by the framework) and SPI (that might be implemented
>> by extenders). So probably it would be good to have maven-api and
>> maven-spi (instead of "maven-core") to make this clear.
>>
>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>> > Hi,
>> >
>> > Guess classrealm is fine for maven, it does not bring much issues (less
>> > than OSGi or JPMS to be concrete), the real issue is the stability of
>> the
>> > exposed API.
>> > Thanks the hard work Guillaume did on that for maven 4 I guess it is
>> mainly
>> > a matter of deciding what we do for maven 3.
>> > Due to the resources and work needed I assume we can just play the
>> > status-quo for maven 3.
>> > Remaining question is for maven 4 do we drop the compatibilty. I don't
>> like
>> > much the idea but a compat layer can solve that smoothly for maven >= 4
>> and
>> > limit the work needed, no?
>> >
>> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de>
>> a
>> > écrit :
>> >
>> >> If you really like to separate API and get out of the ClassRealm-Hell
>> >> OSGi would be much more suitable:
>> >>
>> >> https://issues.apache.org/jira/browse/MNG-7518
>> >>
>> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or
>> 11
>> >> and
>> >>> adopt JPMS to better define its public APIs.
>> >>>
>> >>> Gary
>> >>>
>> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>> >>>
>> >>>> Yes, to define rules is quite easy, but to make our users to obey
>> them
>> >> is
>> >>>> tricky :D
>> >>>>
>> >>>> In general, I guess, we should. For this reason JapiCmp has been
>> used in
>> >>>> Resolver since 1.9.0 (as noted on refd page end).
>> >>>>
>> >>>> But while this was "kinda simple" to achieve in Resolver, I am really
>> >>>> unsure if it is doable in Maven (sans 4 API) :(
>> >>>>
>> >>>> Ultimately, this was the whole reason for API:
>> >>>> - users "grabbed" whatever could get hold on and used
>> >>>> - maven progress was really hindered by this, as that meant modifying
>> >> (even
>> >>>> internal) interfaces without breaking clients was impossible, so we
>> went
>> >>>> with tricks, and more tricks and even more tricks that now pays back.
>> >>>>
>> >>>> The other day we had a question on ML about 4-alpha compatibility
>> >> breakage,
>> >>>> and from mail it was clear that the package of the referred class was
>> >>>> having "internal" in it. I mean, developers should really take care
>> of
>> >> what
>> >>>> they import.
>> >>>>
>> >>>> This is another huge plus for Takari lifecycle, it FORBIDS
>> compilation
>> >>>> against "encapsulated" internal classes....
>> >>>>
>> >>>>
>> >>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>> >>>>
>> >>>> T
>> >>>>
>> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
>> >> wrote:
>> >>>>
>> >>>>> I guess this is the easy part, the tricky question remains: Do we
>> need
>> >> to
>> >>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>> backwards
>> >>>>> compatible until we reach 4.100/5.0/whatever?
>> >>>>>
>> >>>>> This wasn't handled consistently in master till now, e.g. the
>> classes
>> >>>>> generated from
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
>> >>>>> My change in
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>> >>>>> was not backwards compatible (removed a method on an interface which
>> >> may
>> >>>>> have been implemented by extensions...)
>> >>>>>
>> >>>>> Konrad
>> >>>>>
>> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>> >>>>>> Unsure we want to deprecate all of Maven :)
>> >>>>>>
>> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
>> >>>> sadly,
>> >>>>>> and is probably our major source of problems and reason we started
>> >>>> Maven
>> >>>>> 4
>> >>>>>> API.
>> >>>>>>
>> >>>>>> IMO, I'd consider them as "whole", and just say "starting with
>> Maven
>> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>> >>>>> ACCESSIBLE
>> >>>>>> ANYMORE FROM PLUGINS.
>> >>>>>> And done.
>> >>>>>>
>> >>>>>> Just as an example, here is what Maven Resolver has to say about
>> same
>> >>>>> topic
>> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>> >>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>> >>>>>>
>> >>>>>> HTH
>> >>>>>> T
>> >>>>>>
>> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>> I see now there is already
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>> >>>>>>> but to me the javadoc is not explicit enough. It should state:
>> Only
>> >>>>> Maven
>> >>>>>>> is allowed to implement/extend types with this annotation.
>> >>>>>>>
>> >>>>>>> Konrad
>> >>>>>>>
>> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>> >>>>>>>> Hi,
>> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>> >>>>> everything
>> >>>>>>> somehow exposed through class loaders was considered API by
>> >>>>>>> plugin/extension developers.
>> >>>>>>>> For Maven 4 a completely separate API was established in package
>> >>>>>>> “org.apache.maven.api”, but what about the old packages used and
>> >>>>> exported
>> >>>>>>> in Maven 3?
>> >>>>>>>>
>> >>>>>>>> For example in the context of
>> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve
>> the
>> >>>>>>> package “org.apache.maven.plugin.descriptor”.
>> >>>>>>>> We already figured out that this particular package (although not
>> >>>>> part
>> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
>> >>>>> Plugin
>> >>>>>>> Tools, therefore this probably needs to stay backwards compatible.
>> >>>>>>>> What about others like
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> >>>>> ?
>> >>>>>>> <
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> >>>>>>> ?>
>> >>>>>>>> This interface should IMHO never been implemented outside Maven
>> >>>> Core
>> >>>>> but
>> >>>>>>> in fact it was exposed to all plugins/extensions (via
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> >>>>>>> <
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> >>>>>>>> ).
>> >>>>>>>>
>> >>>>>>>> There are three options coming to my mind:
>> >>>>>>>>
>> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
>> >>>> ones
>> >>>>>>> for Maven 4 which are not exported!
>> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
>> >>>> (but
>> >>>>>>> somehow add a marker that they should not be implemented outside
>> >>>> core)
>> >>>>>>>> 3. Modify the existing interfaces in a backwards compatible way
>> >>>> (but
>> >>>>>>> somehow add a marker that they should not be implemented outside
>> >>>> core)
>> >>>>>>>>
>> >>>>>>>> For all three options we somehow need to come up with a list of
>> >>>>>>> classes/interfaces currently being exported through the API class
>> >>>>> loader,
>> >>>>>>> which should be considered private and agree on an
>> Annotation/Javadoc
>> >>>>> for
>> >>>>>>> that (something like
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> >>>>>>> <
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> >>>>>>
>> >>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
>> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>> >>>>>>>>
>> >>>>>>>> WDYT?
>> >>>>>>>>
>> >>>>>>>> Konrad
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> ---------------------------------------------------------------------
>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> --
> ------------------------
> Guillaume Nodet
>
>
--
------------------------
Guillaume Nodet
Re: Maven 3 API, backwards compatibility
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 18 nov. 2022 à 08:57, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> > I fully understand the "under the hood" idea but once again,
> > classrealm usage in maven is a tree which is very close to a flat
> > classpath behavior whereas OSGi is a graph requiring all libs to have
> > metadata -
>
> This is no longer be the case with OSGi connect. A connect framework can
> install bundles that have a custom classloader (in contrast to an OSGi
> managed one) that can use whatever classloader model you want (including
> class realms), Tycho uses this to shaddow current realms inside an
> embedded framework.
>
connect is to run code aside OSGi and integrates with OSGi.
Thread is not about a bridge.
So I agree with you OSGi has great solutions but I fail to see how it can
fit maven ecosystem in any way.
>
> So in a simplified case you can take the "plugin realm" as a
> classlaoder, and use the groupid:artifactid:version as bundle symbolic
> name and you have converted a traditional maven-plugin into a
> connect-bundle. Neither the OSGi will notice that nor the maven-plugin
> will ... just that now it possibly *could* access the OSGi framework if
> desired, and one can allow that if a maven-plugin actually is a bundle
> you do simply install it as such and do not shaddow that by a
> connect-bundle.
>
Ok, what did you gain compared to what we have today?
But you lost the simplicity and the standard testing until you just rely on
IT even for mojo just creating a folder, dont think it is that great.
>
> > and making it accessible means enabling mojo or
> > extensions to reload bundle so break others
>
> Well I currently can easily break "others" as well, I think a maven
> build was never meant as a secured sand-box where nothing bad can happen
> if you like so ... but as said, OSGi is flexible even to that point that
> you can "shield" others, e.g. in embedded environments it is common that
> a "consumer" bundle can not do everything but only certain well defined
> actions, e.g you can even prevent it from doing "bad stuff" or things
> you think should be forbidden (e.g. resister maven-core services) ...
> something that currently you cannot really prevent, as plexus has no way
> for such fine grained control, it will just load whatever it finds in
> the linear classpath.
>
Not in the same way, the tree structure is really more reliable because it
is not as dynamic as OSGi can be so no surprise.
>
>
> > Indeed OSGi is done to be dynamic but it requires all the code
> > to be - which is where random testing must happen and from what
> > you answer you just dont test that so your deployment is random
> > and can get concurrencies issues,
>
> We probably have a different understanding about "randomness", nothing
> in OSGi is random ... and concurrency is not a concern of OSGi itself
> but of any java application. That's why maven has 'isThreadsafe'
> annotations ... what actually means nothing than getting a strange
> warning most users have no clue at.
>
Ok, not random but not deterministic.
OSGi start can never be replayed even if you relaunch it after dumps
because it is fully depending on timing issues and assumes all the code
relies on listeners which is not the case of 10% of the stack - even aries
and karaf have issues to catch up as soon as you need to integrate 3rd
parties.
>
> So from maven POV if you taken maven cli and say it starts the framework
> and publish the core services then starts the plugin bundles and then
> executes the maven life-cycle, it is completely static, nothing will
> change "random" and concurrency will just work on the java level as it
> works today! And if you are using a DI framework like DS you even have
> not to worry about if something would change (again here, nothing
> changes random) dynamically, what at laest from my POV I would not see
> as something even usefull in context of maven (e.g. no one will install
> a new bundle on the fly while the maven build is running...)
>
This is true if you don't use OSGi for this code as explained before there
so why adding it?
>
> > Anyway, if we try to be concrete on your proposal: do you propose to
> > do the work for maven-core, testing and all mojos?
>
> If there is enough interest I defiantly can help with that, the
> mentioned JIRA issue already includes some remarks and possible
> implementation paths, but of course it is a bit too much to came up with
> a code-proposal if no one likes to really take it into consideration
> because one thinks its "wrong" (for whatever reason).
>
> If one likes to can take a look at what Tycho does with its
> sisu-osgi-connect[1] or more specifically where it maps realms to
> connect bundles [2], the code is just a bit more complex than necessary
> because it need to recover all data after-the-fact because maven (or
> plexus?) obviously do not expose those internals in an extender-friendly
> way :-)
>
> Also note that in sisu-osgi-connect even multiple frameworks can / will
> be started (one for each plugin realm) so even that is possible if one
> want to separate things even more and "shield" different actors.
>
If it comes with a full transparent and complete stack (api, dev,
packaging, testing) and user does not have to see OSGi (bnd) I have to
admit I don't care much what we use until it makes the distro of maven and
the mojo fatter but have to also admit technically it will likely always
surface - we did the exercise on other projects multiple times - until you
don't rely on OSGi (connect) and therefore do not need to do that
investment at all.
So don't get my doubts as a "no" but more as a high level expectations in
terms of results.
>
>
> [1]
>
> https://github.com/eclipse-tycho/tycho/tree/master/sisu-osgi/sisu-osgi-connect/src/main/java/org/eclipse/sisu/osgi/connect
> [2]
>
> https://github.com/eclipse-tycho/tycho/blob/master/sisu-osgi/sisu-osgi-connect/src/main/java/org/eclipse/sisu/osgi/connect/PlexusModuleConnector.java#L107
>
>
> Am 18.11.22 um 08:19 schrieb Romain Manni-Bucau:
> > I fully understand the "under the hood" idea but once again, classrealm
> > usage in maven is a tree which is very close to a flat classpath behavior
> > whereas OSGi is a graph requiring all libs to have metadata - none have
> > correct one as of today - and making it accessible means enabling mojo or
> > extensions to reload bundle so break others not using a full OSGi
> mecanism
> > (listeners). Indeed OSGi is done to be dynamic but it requires all the
> code
> > to be - which is where random testing must happen and from what you
> answer
> > you just dont test that so your deployment is random and can get
> > concurrencies issues, thing I'd like to avoid for maven core but more
> > particular for end users who will probably never understand why the
> import
> > was not resolved or why a dependency is missing being in libs/system.
> > Anyway, if we try to be concrete on your proposal: do you propose to do
> the
> > work for maven-core, testing and all mojos?
> >
> >
> > Le ven. 18 nov. 2022 à 06:57, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> > A new more modern spec was created because existing one(s) was not
> >> > sufficient.
> >>
> >> DS is still widely used and much more lightweight, CDI is not
> >> "superseeding" DS, beside that you can use CDI if you think it fits you
> >> more, you can even use Blueprint if you more like "spring-xml" or any
> >> other famous technique that might came up without the need for maven to
> >> change a single line of code or any other plugin.
> >>
> >> The question just was "isn't it too complex" and I showed that there are
> >> techniques that completely hide that and even are close to what people
> >> know of today. Still this do not limit us to what was shown.
> >>
> >> > In IT you can always make everything working but does it help
> >> > the ecosystem or users?
> >>
> >> At least it would help the most common pitfalls when it comes to more
> >> than a simple mojo. Ans especially if it comes to API evolution and
> >> alike like core-extensions versus project extensions ...
> >>
> >> > The defined lifecycle of OSGi is for a system with no linear
> lifecycle
> >> > but maven has one and this is what people tend to understand
> >>
> >> As said this is nothing where you have to choose one over the other its
> >> even unclear to me what "the maven lifcycle" refers to? Maven CLI? How
> >> many people can really explain/understand how it works with all the
> >> setup of the realms and a like?
> >>
> >>
> >> > (one reason no ee lib is really osgi friendly if you look closer)
> >> > so the issue is not osgi -i like this system - but its people target
> >> > for a build system I think.
> >>
> >> OSGi is a specification, and you can use as much (or less) as you desire
> >> and with OSGi-Connect you can mix this with whatever you like, even JPMS
> >> can be modeled as OSGi (see Felix Atomos).
> >>
> >> > Agree we can enhance maven but yout point about osgi is to not test
> it
> >> > (you forgot all the cases of this random lifecycle to cite just a
> >> > trivial pitfall).
> >>
> >> I really don't get the point about "random lifecycle", there is nothing
> >> "random" in OSGi (as it would be devastating in any software if it where
> >> behaving random).
> >>
> >> > At least maven does not have that kind of issues and does not
> >> > need to document the best you can fo is either not test or
> >> > use some kind of chaos testing.
> >>
> >> Same here, in > 10 years of OSGi I never used "chaos testing" (what ever
> >> that means), of course it always depend how testable you write your
> >> code... and wasn't there recently a thread on the ML about the "chaos"
> >> in Maven? Maven Invoker, vs Verifier, Maven-plugin-test requiring
> >> discouraged maven-compat and then there are "more alternative
> >> approaches" so I think maven is still far a way from been all
> >> green-grasses and sunshine...
> >>
> >> Also please carefully read what was written in the Jira issue (and on
> >> this thread), I never suggested to "trow all away and let people use
> >> OSGi), the suggestion was to use OSGI under the hood to replace the
> >> (hard to manage) realm concept for API handling, make it accessible to
> >> the ones who likes to use it...
> >>
> >>
> >>
> >> Am 17.11.22 um 21:28 schrieb Romain Manni-Bucau:
> >>> Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> >>> écrit :
> >>>
> >>>> The great thing is that DS is not an "API" you use, it is just a
> >>>> convenient way to express what you provide and what you need, so you
> >>>> will never have any runtime dependency and thus can always choose
> >>>> another, you can even code all this "by hand" ... anyways I never
> heard
> >>>> it is "superseeded" or "legacy" do you have any normative statement
> >>>> about that?
> >>>>
> >>>
> >>> A new more modern spec was created because existing one(s) was not
> >>> sufficient.
> >>> Phrase it as you want but DS is no more a default choice as of today
> and
> >> if
> >>> you get back to the topic it is far to cover maven need.
> >>>
> >>>
> >>>
> >>>> > maven has a well defined lifecycle whereas OSGi wants to be ultra
> >>>> dynamic
> >>>>
> >>>> OSGi can be used in a dynamic way but still has "well defined
> lifecycle"
> >>>> and you are not forced to use the dynamics. and you can define the
> >>>> maven-lifecycle on top of it OSGi do not mandates any specific way to
> >>>> use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the
> other
> >>>> way round: Running in OSGi and embedding maven ...
> >>>>
> >>>
> >>> In IT you can always make everything working but does it help the
> >> ecosystem
> >>> or users?
> >>> The defined lifecycle of OSGi is for a system with no linear lifecycle
> >> but
> >>> maven has one and this is what people tend to understand (one reason no
> >> ee
> >>> lib is really osgi friendly if you look closer) so the issue is not
> osgi
> >> -
> >>> i like this system - but its people target for a build system I think.
> >>>
> >>>
> >>>
> >>>> > but almost untestable without sophisticated
> >>>> > solutions for enterprises apps)
> >>>>
> >>>> OSGi actually allows better testing (through DI and service layer),
> >>>> while the official maven-plugin-test still suffers from being bound to
> >>>> maven-compat and JUnit 3 .... so I can't really say testing "maven" is
> >>>> really anything I would call easy ;-)
> >>>>
> >>>
> >>> Agree we can enhance maven but yout point about osgi is to not test it
> >> (you
> >>> forgot all the cases of this random lifecycle to cite just a trivial
> >>> pitfall). At least maven does not have that kind of issues and does not
> >>> need to document the best you can fo is either not test or use some
> kind
> >> of
> >>> chaos testing.
> >>>
> >>>
> >>>
> >>>> > we should just stick to the excellent work Guillaume did and keep
> >>>> > decoupling our internal impls/deps from the exposed API we should
> >>>> > keep control now we have a real API we lacked for years.
> >>>>
> >>>> This work is actually nothing contradictory or "different" if one
> would
> >>>> use OSGi ...
> >>>>
> >>>
> >>> Right but it is opposed to your sample using ds @Reference for ex.
> >>>
> >>> Anyway, guess nobody will spend time on making it so no need to discuss
> >> it
> >>> much, no?
> >>>
> >>>
> >>>>
> >>>> Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau:
> >>>>> Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <
> mail@laeubi-soft.de>
> >> a
> >>>>> écrit :
> >>>>>
> >>>>>> For OSGi there is a DI framework name "Declarative Services", that
> is
> >>>>>> (from users POV) not any "complex" or different than Plexus, e.g a
> >> Mojo
> >>>>>> might simply look like:
> >>>>>>
> >>>>>> @Component
> >>>>>> MyMojo implements Mojo {
> >>>>>>
> >>>>>> @Reference
> >>>>>> Logger logger;
> >>>>>>
> >>>>>> @Overide
> >>>>>> void execute() {
> >>>>>> ... do it ! ...
> >>>>>> }
> >>>>>> }
> >>>>>>
> >>>>>> for the rest, you simply has a maven plugin that generates all the
> >> rest
> >>>>>> for you ... so very similar to what we have today, but with much
> more
> >>>>>> flexibility (not shown here as not required for most cases).
> >>>>>>
> >>>>>> And for the "breakage", as outlined in the linked issue [1], Tycho
> >>>>>> already use a Maven <-> OSGi bridge, so actually one can even
> combine
> >>>>>> both "worlds" ...
> >>>>>>
> >>>>>
> >>>>> We saw multiple times by the past we shouldn't expose any used API
> >> cause
> >>>> it
> >>>>> leads to conflicts, API incompatibilities etc... so reuse DS sounds
> >> like
> >>>>> redoing some previous errors (we got bitten by a single annotation
> from
> >>>>> cdi-api.jar so imagine if we use more ;)).
> >>>>> Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI
> so
> >>>> not
> >>>>> sure it is better than going back to plexus for end users.
> >>>>> Last issue is that it has a whole set of API for dynamism maven will
> >> not
> >>>>> get (to not make the system overcomplex and since it has no real need
> >> of
> >>>> it
> >>>>> - maven has a well defined lifecycle whereas OSGi wants to be ultra
> >>>> dynamic
> >>>>> which is good for some systems but almost untestable without
> >>>> sophisticated
> >>>>> solutions for enterprises apps) so think we should just stick to the
> >>>>> excellent work Guillaume did and keep decoupling our internal
> >> impls/deps
> >>>>> from the exposed API we should keep control now we have a real API we
> >>>>> lacked for years.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> [1] https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>
> >>>>>> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
> >>>>>>> I do agree that debugging the provisioning side is *very*
> complicated
> >>>>>> when
> >>>>>>> there's a problem.
> >>>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >>>>>> framework,
> >>>>>>> at least for simple plugins.
> >>>>>>> However, I definitely don't think pushing OSGi to plugins would be
> a
> >>>> good
> >>>>>>> idea : the cost and burden on plugin developers would outweigh the
> >>>>>> benefits.
> >>>>>>>
> >>>>>>> For extensions, and for maven itself, that is a different story
> >> though.
> >>>>>>> Maven and extensions could definitely benefit from OSGi, but this
> >> would
> >>>>>> be
> >>>>>>> a complete breakage and it would be hard to keep some level of
> >>>>>>> compatibility.
> >>>>>>>
> >>>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> >> mail@laeubi-soft.de>
> >>>> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> > Guess classrealm is fine for maven, it does not bring much
> >> issues
> >>>>>>>>
> >>>>>>>> As long as it works, maybe, maybe even if you write a simple maven
> >>>>>>>> plugin, but for any more complex it is just a complete mess.
> >>>>>>>>
> >>>>>>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>>>>>> complete silence ...
> >>>>>>>>
> >>>>>>>> Today I tried to refactor the name of one module of a more complex
> >>>>>>>> maven-plugin (with core extension), now I end up with
> >>>>>>>>
> >>>>>>>> org.apache.maven.InternalErrorException: Internal error:
> >>>>>>>> com.google.inject.ProvisionException: Unable to provision, see the
> >>>>>>>> following errors:
> >>>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> >>>> bound.
> >>>>>>>>
> >>>>>>>> A whole bunch of stack trace but not a little info why the *****
> it
> >> is
> >>>>>>>> not happy. Now I need to add random "exportedArtifact" /
> >>>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>>>>>> transitive dependency, also here absolutely no documentation what
> >> this
> >>>>>>>> is supposed to do/work exactly beside some introduction that these
> >> xml
> >>>>>>>> tags exits and reading the code... or probably add maven-compat
> >>>>>>>> anywhere... or change provided to compile scope (even maven is
> >> jelling
> >>>>>>>> at me that's bad and I will be punished soon)... not counting the
> >> many
> >>>>>>>> times where I messed up the realms because I accidentally trying
> to
> >>>> use
> >>>>>>>> XppDom objects in extensions and plugins and something between got
> >>>>>>>> messed up.
> >>>>>>>>
> >>>>>>>> With OSGi i get clear errors for missing requirements, I can
> clearly
> >>>>>>>> share API (or declare I don't want to share it) and can reliable
> use
> >>>> it
> >>>>>>>> without classlaoding problems.
> >>>>>>>> If one wan't can even implement service filtering that would hide
> >> all
> >>>>>>>> "illegal implemented API" ... and you can even make sure API is
> >>>>>>>> (backward) compatible with implementation without waiting for a
> >> method
> >>>>>>>> not found exception or alike.
> >>>>>>>>
> >>>>>>>> Beside that I find it often more clear to distinguish between API
> >>>> (that
> >>>>>>>> is only implemented by the framework) and SPI (that might be
> >>>> implemented
> >>>>>>>> by extenders). So probably it would be good to have maven-api and
> >>>>>>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>>>>>
> >>>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> Guess classrealm is fine for maven, it does not bring much issues
> >>>> (less
> >>>>>>>>> than OSGi or JPMS to be concrete), the real issue is the
> stability
> >> of
> >>>>>> the
> >>>>>>>>> exposed API.
> >>>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it
> >> is
> >>>>>>>> mainly
> >>>>>>>>> a matter of deciding what we do for maven 3.
> >>>>>>>>> Due to the resources and work needed I assume we can just play
> the
> >>>>>>>>> status-quo for maven 3.
> >>>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> >>>> don't
> >>>>>>>> like
> >>>>>>>>> much the idea but a compat layer can solve that smoothly for
> maven
> >>>>> = 4
> >>>>>>>> and
> >>>>>>>>> limit the work needed, no?
> >>>>>>>>>
> >>>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >>>> mail@laeubi-soft.de>
> >>>>>> a
> >>>>>>>>> écrit :
> >>>>>>>>>
> >>>>>>>>>> If you really like to separate API and get out of the
> >>>> ClassRealm-Hell
> >>>>>>>>>> OSGi would be much more suitable:
> >>>>>>>>>>
> >>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>>>>>
> >>>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to
> Java 9
> >>>> or
> >>>>>> 11
> >>>>>>>>>> and
> >>>>>>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>>>>>
> >>>>>>>>>>> Gary
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <
> tamas@cservenak.net
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
> >> obey
> >>>>>> them
> >>>>>>>>>> is
> >>>>>>>>>>>> tricky :D
> >>>>>>>>>>>>
> >>>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has
> been
> >>>>>> used
> >>>>>>>> in
> >>>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>>>>>
> >>>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> >>>>>> really
> >>>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>>>>>
> >>>>>>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>>>>>> - maven progress was really hindered by this, as that meant
> >>>>>> modifying
> >>>>>>>>>> (even
> >>>>>>>>>>>> internal) interfaces without breaking clients was impossible,
> so
> >>>> we
> >>>>>>>> went
> >>>>>>>>>>>> with tricks, and more tricks and even more tricks that now
> pays
> >>>>>> back.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The other day we had a question on ML about 4-alpha
> >> compatibility
> >>>>>>>>>> breakage,
> >>>>>>>>>>>> and from mail it was clear that the package of the referred
> >> class
> >>>>>> was
> >>>>>>>>>>>> having "internal" in it. I mean, developers should really take
> >>>> care
> >>>>>> of
> >>>>>>>>>> what
> >>>>>>>>>>>> they import.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >>>>>> compilation
> >>>>>>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>>>>>
> >>>>>>>>>>>> T
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> >> kwin@apache.org
> >>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I guess this is the easy part, the tricky question remains:
> Do
> >> we
> >>>>>>>> need
> >>>>>>>>>> to
> >>>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >>>>>> backwards
> >>>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
> >>>>>> classes
> >>>>>>>>>>>>> generated from
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>>>>>> My change in
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>>>>>> was not backwards compatible (removed a method on an
> interface
> >>>>>> which
> >>>>>>>>>> may
> >>>>>>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> >>>> grab"
> >>>>>>>>>>>> sadly,
> >>>>>>>>>>>>>> and is probably our major source of problems and reason we
> >>>> started
> >>>>>>>>>>>> Maven
> >>>>>>>>>>>>> 4
> >>>>>>>>>>>>>> API.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting
> with
> >>>>>> Maven
> >>>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> >> NOT
> >>>>>>>>>>>>> ACCESSIBLE
> >>>>>>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>>>>>> And done.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> >> about
> >>>>>>>> same
> >>>>>>>>>>>>> topic
> >>>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1
> version):
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> HTH
> >>>>>>>>>>>>>> T
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >>>> kwin@apache.org
> >>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I see now there is already
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
> >> state:
> >>>>>> Only
> >>>>>>>>>>>>> Maven
> >>>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In
> effect
> >>>>>>>>>>>>> everything
> >>>>>>>>>>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> >>>> package
> >>>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages
> used
> >>>> and
> >>>>>>>>>>>>> exported
> >>>>>>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> For example in the context of
> >>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >>>> evolve
> >>>>>>>> the
> >>>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>>>>>> We already figured out that this particular package
> >> (although
> >>>>>> not
> >>>>>>>>>>>>> part
> >>>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> >>>> Maven
> >>>>>>>>>>>>> Plugin
> >>>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >>>>>> compatible.
> >>>>>>>>>>>>>>>> What about others like
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>> ?
> >>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>>>> ?>
> >>>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
> >>>> Maven
> >>>>>>>>>>>> Core
> >>>>>>>>>>>>> but
> >>>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>>>> ).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and
> create
> >>>> new
> >>>>>>>>>>>> ones
> >>>>>>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards
> compatible
> >>>> way
> >>>>>>>>>>>> (but
> >>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>> outside
> >>>>>>>>>>>> core)
> >>>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards
> compatible
> >>>> way
> >>>>>>>>>>>> (but
> >>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >>>> outside
> >>>>>>>>>>>> core)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> For all three options we somehow need to come up with a
> list
> >>>> of
> >>>>>>>>>>>>>>> classes/interfaces currently being exported through the API
> >>>> class
> >>>>>>>>>>>>> loader,
> >>>>>>>>>>>>>>> which should be considered private and agree on an
> >>>>>>>> Annotation/Javadoc
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>> that (something like
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> or
> >> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >>>> <
> >>>>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
> I fully understand the "under the hood" idea but once again,
> classrealm usage in maven is a tree which is very close to a flat
> classpath behavior whereas OSGi is a graph requiring all libs to have
> metadata -
This is no longer be the case with OSGi connect. A connect framework can
install bundles that have a custom classloader (in contrast to an OSGi
managed one) that can use whatever classloader model you want (including
class realms), Tycho uses this to shaddow current realms inside an
embedded framework.
So in a simplified case you can take the "plugin realm" as a
classlaoder, and use the groupid:artifactid:version as bundle symbolic
name and you have converted a traditional maven-plugin into a
connect-bundle. Neither the OSGi will notice that nor the maven-plugin
will ... just that now it possibly *could* access the OSGi framework if
desired, and one can allow that if a maven-plugin actually is a bundle
you do simply install it as such and do not shaddow that by a
connect-bundle.
> and making it accessible means enabling mojo or
> extensions to reload bundle so break others
Well I currently can easily break "others" as well, I think a maven
build was never meant as a secured sand-box where nothing bad can happen
if you like so ... but as said, OSGi is flexible even to that point that
you can "shield" others, e.g. in embedded environments it is common that
a "consumer" bundle can not do everything but only certain well defined
actions, e.g you can even prevent it from doing "bad stuff" or things
you think should be forbidden (e.g. resister maven-core services) ...
something that currently you cannot really prevent, as plexus has no way
for such fine grained control, it will just load whatever it finds in
the linear classpath.
> Indeed OSGi is done to be dynamic but it requires all the code
> to be - which is where random testing must happen and from what
> you answer you just dont test that so your deployment is random
> and can get concurrencies issues,
We probably have a different understanding about "randomness", nothing
in OSGi is random ... and concurrency is not a concern of OSGi itself
but of any java application. That's why maven has 'isThreadsafe'
annotations ... what actually means nothing than getting a strange
warning most users have no clue at.
So from maven POV if you taken maven cli and say it starts the framework
and publish the core services then starts the plugin bundles and then
executes the maven life-cycle, it is completely static, nothing will
change "random" and concurrency will just work on the java level as it
works today! And if you are using a DI framework like DS you even have
not to worry about if something would change (again here, nothing
changes random) dynamically, what at laest from my POV I would not see
as something even usefull in context of maven (e.g. no one will install
a new bundle on the fly while the maven build is running...)
> Anyway, if we try to be concrete on your proposal: do you propose to
> do the work for maven-core, testing and all mojos?
If there is enough interest I defiantly can help with that, the
mentioned JIRA issue already includes some remarks and possible
implementation paths, but of course it is a bit too much to came up with
a code-proposal if no one likes to really take it into consideration
because one thinks its "wrong" (for whatever reason).
If one likes to can take a look at what Tycho does with its
sisu-osgi-connect[1] or more specifically where it maps realms to
connect bundles [2], the code is just a bit more complex than necessary
because it need to recover all data after-the-fact because maven (or
plexus?) obviously do not expose those internals in an extender-friendly
way :-)
Also note that in sisu-osgi-connect even multiple frameworks can / will
be started (one for each plugin realm) so even that is possible if one
want to separate things even more and "shield" different actors.
[1]
https://github.com/eclipse-tycho/tycho/tree/master/sisu-osgi/sisu-osgi-connect/src/main/java/org/eclipse/sisu/osgi/connect
[2]
https://github.com/eclipse-tycho/tycho/blob/master/sisu-osgi/sisu-osgi-connect/src/main/java/org/eclipse/sisu/osgi/connect/PlexusModuleConnector.java#L107
Am 18.11.22 um 08:19 schrieb Romain Manni-Bucau:
> I fully understand the "under the hood" idea but once again, classrealm
> usage in maven is a tree which is very close to a flat classpath behavior
> whereas OSGi is a graph requiring all libs to have metadata - none have
> correct one as of today - and making it accessible means enabling mojo or
> extensions to reload bundle so break others not using a full OSGi mecanism
> (listeners). Indeed OSGi is done to be dynamic but it requires all the code
> to be - which is where random testing must happen and from what you answer
> you just dont test that so your deployment is random and can get
> concurrencies issues, thing I'd like to avoid for maven core but more
> particular for end users who will probably never understand why the import
> was not resolved or why a dependency is missing being in libs/system.
> Anyway, if we try to be concrete on your proposal: do you propose to do the
> work for maven-core, testing and all mojos?
>
>
> Le ven. 18 nov. 2022 à 06:57, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> > A new more modern spec was created because existing one(s) was not
>> > sufficient.
>>
>> DS is still widely used and much more lightweight, CDI is not
>> "superseeding" DS, beside that you can use CDI if you think it fits you
>> more, you can even use Blueprint if you more like "spring-xml" or any
>> other famous technique that might came up without the need for maven to
>> change a single line of code or any other plugin.
>>
>> The question just was "isn't it too complex" and I showed that there are
>> techniques that completely hide that and even are close to what people
>> know of today. Still this do not limit us to what was shown.
>>
>> > In IT you can always make everything working but does it help
>> > the ecosystem or users?
>>
>> At least it would help the most common pitfalls when it comes to more
>> than a simple mojo. Ans especially if it comes to API evolution and
>> alike like core-extensions versus project extensions ...
>>
>> > The defined lifecycle of OSGi is for a system with no linear lifecycle
>> > but maven has one and this is what people tend to understand
>>
>> As said this is nothing where you have to choose one over the other its
>> even unclear to me what "the maven lifcycle" refers to? Maven CLI? How
>> many people can really explain/understand how it works with all the
>> setup of the realms and a like?
>>
>>
>> > (one reason no ee lib is really osgi friendly if you look closer)
>> > so the issue is not osgi -i like this system - but its people target
>> > for a build system I think.
>>
>> OSGi is a specification, and you can use as much (or less) as you desire
>> and with OSGi-Connect you can mix this with whatever you like, even JPMS
>> can be modeled as OSGi (see Felix Atomos).
>>
>> > Agree we can enhance maven but yout point about osgi is to not test it
>> > (you forgot all the cases of this random lifecycle to cite just a
>> > trivial pitfall).
>>
>> I really don't get the point about "random lifecycle", there is nothing
>> "random" in OSGi (as it would be devastating in any software if it where
>> behaving random).
>>
>> > At least maven does not have that kind of issues and does not
>> > need to document the best you can fo is either not test or
>> > use some kind of chaos testing.
>>
>> Same here, in > 10 years of OSGi I never used "chaos testing" (what ever
>> that means), of course it always depend how testable you write your
>> code... and wasn't there recently a thread on the ML about the "chaos"
>> in Maven? Maven Invoker, vs Verifier, Maven-plugin-test requiring
>> discouraged maven-compat and then there are "more alternative
>> approaches" so I think maven is still far a way from been all
>> green-grasses and sunshine...
>>
>> Also please carefully read what was written in the Jira issue (and on
>> this thread), I never suggested to "trow all away and let people use
>> OSGi), the suggestion was to use OSGI under the hood to replace the
>> (hard to manage) realm concept for API handling, make it accessible to
>> the ones who likes to use it...
>>
>>
>>
>> Am 17.11.22 um 21:28 schrieb Romain Manni-Bucau:
>>> Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich <ma...@laeubi-soft.de> a
>>> écrit :
>>>
>>>> The great thing is that DS is not an "API" you use, it is just a
>>>> convenient way to express what you provide and what you need, so you
>>>> will never have any runtime dependency and thus can always choose
>>>> another, you can even code all this "by hand" ... anyways I never heard
>>>> it is "superseeded" or "legacy" do you have any normative statement
>>>> about that?
>>>>
>>>
>>> A new more modern spec was created because existing one(s) was not
>>> sufficient.
>>> Phrase it as you want but DS is no more a default choice as of today and
>> if
>>> you get back to the topic it is far to cover maven need.
>>>
>>>
>>>
>>>> > maven has a well defined lifecycle whereas OSGi wants to be ultra
>>>> dynamic
>>>>
>>>> OSGi can be used in a dynamic way but still has "well defined lifecycle"
>>>> and you are not forced to use the dynamics. and you can define the
>>>> maven-lifecycle on top of it OSGi do not mandates any specific way to
>>>> use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the other
>>>> way round: Running in OSGi and embedding maven ...
>>>>
>>>
>>> In IT you can always make everything working but does it help the
>> ecosystem
>>> or users?
>>> The defined lifecycle of OSGi is for a system with no linear lifecycle
>> but
>>> maven has one and this is what people tend to understand (one reason no
>> ee
>>> lib is really osgi friendly if you look closer) so the issue is not osgi
>> -
>>> i like this system - but its people target for a build system I think.
>>>
>>>
>>>
>>>> > but almost untestable without sophisticated
>>>> > solutions for enterprises apps)
>>>>
>>>> OSGi actually allows better testing (through DI and service layer),
>>>> while the official maven-plugin-test still suffers from being bound to
>>>> maven-compat and JUnit 3 .... so I can't really say testing "maven" is
>>>> really anything I would call easy ;-)
>>>>
>>>
>>> Agree we can enhance maven but yout point about osgi is to not test it
>> (you
>>> forgot all the cases of this random lifecycle to cite just a trivial
>>> pitfall). At least maven does not have that kind of issues and does not
>>> need to document the best you can fo is either not test or use some kind
>> of
>>> chaos testing.
>>>
>>>
>>>
>>>> > we should just stick to the excellent work Guillaume did and keep
>>>> > decoupling our internal impls/deps from the exposed API we should
>>>> > keep control now we have a real API we lacked for years.
>>>>
>>>> This work is actually nothing contradictory or "different" if one would
>>>> use OSGi ...
>>>>
>>>
>>> Right but it is opposed to your sample using ds @Reference for ex.
>>>
>>> Anyway, guess nobody will spend time on making it so no need to discuss
>> it
>>> much, no?
>>>
>>>
>>>>
>>>> Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau:
>>>>> Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <ma...@laeubi-soft.de>
>> a
>>>>> écrit :
>>>>>
>>>>>> For OSGi there is a DI framework name "Declarative Services", that is
>>>>>> (from users POV) not any "complex" or different than Plexus, e.g a
>> Mojo
>>>>>> might simply look like:
>>>>>>
>>>>>> @Component
>>>>>> MyMojo implements Mojo {
>>>>>>
>>>>>> @Reference
>>>>>> Logger logger;
>>>>>>
>>>>>> @Overide
>>>>>> void execute() {
>>>>>> ... do it ! ...
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> for the rest, you simply has a maven plugin that generates all the
>> rest
>>>>>> for you ... so very similar to what we have today, but with much more
>>>>>> flexibility (not shown here as not required for most cases).
>>>>>>
>>>>>> And for the "breakage", as outlined in the linked issue [1], Tycho
>>>>>> already use a Maven <-> OSGi bridge, so actually one can even combine
>>>>>> both "worlds" ...
>>>>>>
>>>>>
>>>>> We saw multiple times by the past we shouldn't expose any used API
>> cause
>>>> it
>>>>> leads to conflicts, API incompatibilities etc... so reuse DS sounds
>> like
>>>>> redoing some previous errors (we got bitten by a single annotation from
>>>>> cdi-api.jar so imagine if we use more ;)).
>>>>> Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI so
>>>> not
>>>>> sure it is better than going back to plexus for end users.
>>>>> Last issue is that it has a whole set of API for dynamism maven will
>> not
>>>>> get (to not make the system overcomplex and since it has no real need
>> of
>>>> it
>>>>> - maven has a well defined lifecycle whereas OSGi wants to be ultra
>>>> dynamic
>>>>> which is good for some systems but almost untestable without
>>>> sophisticated
>>>>> solutions for enterprises apps) so think we should just stick to the
>>>>> excellent work Guillaume did and keep decoupling our internal
>> impls/deps
>>>>> from the exposed API we should keep control now we have a real API we
>>>>> lacked for years.
>>>>>
>>>>>
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/MNG-7518
>>>>>>
>>>>>> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
>>>>>>> I do agree that debugging the provisioning side is *very* complicated
>>>>>> when
>>>>>>> there's a problem.
>>>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
>>>>>> framework,
>>>>>>> at least for simple plugins.
>>>>>>> However, I definitely don't think pushing OSGi to plugins would be a
>>>> good
>>>>>>> idea : the cost and burden on plugin developers would outweigh the
>>>>>> benefits.
>>>>>>>
>>>>>>> For extensions, and for maven itself, that is a different story
>> though.
>>>>>>> Maven and extensions could definitely benefit from OSGi, but this
>> would
>>>>>> be
>>>>>>> a complete breakage and it would be hard to keep some level of
>>>>>>> compatibility.
>>>>>>>
>>>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
>> mail@laeubi-soft.de>
>>>> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> > Guess classrealm is fine for maven, it does not bring much
>> issues
>>>>>>>>
>>>>>>>> As long as it works, maybe, maybe even if you write a simple maven
>>>>>>>> plugin, but for any more complex it is just a complete mess.
>>>>>>>>
>>>>>>>> Last time I asked on the mailing list how to debug that stuff ...
>>>>>>>> complete silence ...
>>>>>>>>
>>>>>>>> Today I tried to refactor the name of one module of a more complex
>>>>>>>> maven-plugin (with core extension), now I end up with
>>>>>>>>
>>>>>>>> org.apache.maven.InternalErrorException: Internal error:
>>>>>>>> com.google.inject.ProvisionException: Unable to provision, see the
>>>>>>>> following errors:
>>>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
>>>> bound.
>>>>>>>>
>>>>>>>> A whole bunch of stack trace but not a little info why the ***** it
>> is
>>>>>>>> not happy. Now I need to add random "exportedArtifact" /
>>>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
>>>>>>>> transitive dependency, also here absolutely no documentation what
>> this
>>>>>>>> is supposed to do/work exactly beside some introduction that these
>> xml
>>>>>>>> tags exits and reading the code... or probably add maven-compat
>>>>>>>> anywhere... or change provided to compile scope (even maven is
>> jelling
>>>>>>>> at me that's bad and I will be punished soon)... not counting the
>> many
>>>>>>>> times where I messed up the realms because I accidentally trying to
>>>> use
>>>>>>>> XppDom objects in extensions and plugins and something between got
>>>>>>>> messed up.
>>>>>>>>
>>>>>>>> With OSGi i get clear errors for missing requirements, I can clearly
>>>>>>>> share API (or declare I don't want to share it) and can reliable use
>>>> it
>>>>>>>> without classlaoding problems.
>>>>>>>> If one wan't can even implement service filtering that would hide
>> all
>>>>>>>> "illegal implemented API" ... and you can even make sure API is
>>>>>>>> (backward) compatible with implementation without waiting for a
>> method
>>>>>>>> not found exception or alike.
>>>>>>>>
>>>>>>>> Beside that I find it often more clear to distinguish between API
>>>> (that
>>>>>>>> is only implemented by the framework) and SPI (that might be
>>>> implemented
>>>>>>>> by extenders). So probably it would be good to have maven-api and
>>>>>>>> maven-spi (instead of "maven-core") to make this clear.
>>>>>>>>
>>>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Guess classrealm is fine for maven, it does not bring much issues
>>>> (less
>>>>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
>> of
>>>>>> the
>>>>>>>>> exposed API.
>>>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it
>> is
>>>>>>>> mainly
>>>>>>>>> a matter of deciding what we do for maven 3.
>>>>>>>>> Due to the resources and work needed I assume we can just play the
>>>>>>>>> status-quo for maven 3.
>>>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
>>>> don't
>>>>>>>> like
>>>>>>>>> much the idea but a compat layer can solve that smoothly for maven
>>>>> = 4
>>>>>>>> and
>>>>>>>>> limit the work needed, no?
>>>>>>>>>
>>>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>>>> mail@laeubi-soft.de>
>>>>>> a
>>>>>>>>> écrit :
>>>>>>>>>
>>>>>>>>>> If you really like to separate API and get out of the
>>>> ClassRealm-Hell
>>>>>>>>>> OSGi would be much more suitable:
>>>>>>>>>>
>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>>>>>>>
>>>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
>>>> or
>>>>>> 11
>>>>>>>>>> and
>>>>>>>>>>> adopt JPMS to better define its public APIs.
>>>>>>>>>>>
>>>>>>>>>>> Gary
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <tamas@cservenak.net
>>>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
>> obey
>>>>>> them
>>>>>>>>>> is
>>>>>>>>>>>> tricky :D
>>>>>>>>>>>>
>>>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
>>>>>> used
>>>>>>>> in
>>>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>>>>>>>
>>>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
>>>>>> really
>>>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>>>>>>>
>>>>>>>>>>>> Ultimately, this was the whole reason for API:
>>>>>>>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>>>>>>>> - maven progress was really hindered by this, as that meant
>>>>>> modifying
>>>>>>>>>> (even
>>>>>>>>>>>> internal) interfaces without breaking clients was impossible, so
>>>> we
>>>>>>>> went
>>>>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
>>>>>> back.
>>>>>>>>>>>>
>>>>>>>>>>>> The other day we had a question on ML about 4-alpha
>> compatibility
>>>>>>>>>> breakage,
>>>>>>>>>>>> and from mail it was clear that the package of the referred
>> class
>>>>>> was
>>>>>>>>>>>> having "internal" in it. I mean, developers should really take
>>>> care
>>>>>> of
>>>>>>>>>> what
>>>>>>>>>>>> they import.
>>>>>>>>>>>>
>>>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
>>>>>> compilation
>>>>>>>>>>>> against "encapsulated" internal classes....
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>>>>>>>
>>>>>>>>>>>> T
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
>> kwin@apache.org
>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
>> we
>>>>>>>> need
>>>>>>>>>> to
>>>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>>>>>> backwards
>>>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>>>>>>>
>>>>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
>>>>>> classes
>>>>>>>>>>>>> generated from
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>>>>>>>> My change in
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>>>>>>>> was not backwards compatible (removed a method on an interface
>>>>>> which
>>>>>>>>>> may
>>>>>>>>>>>>> have been implemented by extensions...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
>>>> grab"
>>>>>>>>>>>> sadly,
>>>>>>>>>>>>>> and is probably our major source of problems and reason we
>>>> started
>>>>>>>>>>>> Maven
>>>>>>>>>>>>> 4
>>>>>>>>>>>>>> API.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
>>>>>> Maven
>>>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
>> NOT
>>>>>>>>>>>>> ACCESSIBLE
>>>>>>>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>>>>>>>> And done.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
>> about
>>>>>>>> same
>>>>>>>>>>>>> topic
>>>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HTH
>>>>>>>>>>>>>> T
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>>>> kwin@apache.org
>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I see now there is already
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
>> state:
>>>>>> Only
>>>>>>>>>>>>> Maven
>>>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>>>>>>>> everything
>>>>>>>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>>>>>>>> plugin/extension developers.
>>>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
>>>> package
>>>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
>>>> and
>>>>>>>>>>>>> exported
>>>>>>>>>>>>>>> in Maven 3?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For example in the context of
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>>>> evolve
>>>>>>>> the
>>>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>>>>>>>> We already figured out that this particular package
>> (although
>>>>>> not
>>>>>>>>>>>>> part
>>>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
>>>> Maven
>>>>>>>>>>>>> Plugin
>>>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
>>>>>> compatible.
>>>>>>>>>>>>>>>> What about others like
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>>>>> ?>
>>>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
>>>> Maven
>>>>>>>>>>>> Core
>>>>>>>>>>>>> but
>>>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
>>>> new
>>>>>>>>>>>> ones
>>>>>>>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
>>>> way
>>>>>>>>>>>> (but
>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>>> outside
>>>>>>>>>>>> core)
>>>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
>>>> way
>>>>>>>>>>>> (but
>>>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>>>> outside
>>>>>>>>>>>> core)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For all three options we somehow need to come up with a list
>>>> of
>>>>>>>>>>>>>>> classes/interfaces currently being exported through the API
>>>> class
>>>>>>>>>>>>> loader,
>>>>>>>>>>>>>>> which should be considered private and agree on an
>>>>>>>> Annotation/Javadoc
>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> that (something like
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> or
>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>>>> <
>>>>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I fully understand the "under the hood" idea but once again, classrealm
usage in maven is a tree which is very close to a flat classpath behavior
whereas OSGi is a graph requiring all libs to have metadata - none have
correct one as of today - and making it accessible means enabling mojo or
extensions to reload bundle so break others not using a full OSGi mecanism
(listeners). Indeed OSGi is done to be dynamic but it requires all the code
to be - which is where random testing must happen and from what you answer
you just dont test that so your deployment is random and can get
concurrencies issues, thing I'd like to avoid for maven core but more
particular for end users who will probably never understand why the import
was not resolved or why a dependency is missing being in libs/system.
Anyway, if we try to be concrete on your proposal: do you propose to do the
work for maven-core, testing and all mojos?
Le ven. 18 nov. 2022 à 06:57, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> > A new more modern spec was created because existing one(s) was not
> > sufficient.
>
> DS is still widely used and much more lightweight, CDI is not
> "superseeding" DS, beside that you can use CDI if you think it fits you
> more, you can even use Blueprint if you more like "spring-xml" or any
> other famous technique that might came up without the need for maven to
> change a single line of code or any other plugin.
>
> The question just was "isn't it too complex" and I showed that there are
> techniques that completely hide that and even are close to what people
> know of today. Still this do not limit us to what was shown.
>
> > In IT you can always make everything working but does it help
> > the ecosystem or users?
>
> At least it would help the most common pitfalls when it comes to more
> than a simple mojo. Ans especially if it comes to API evolution and
> alike like core-extensions versus project extensions ...
>
> > The defined lifecycle of OSGi is for a system with no linear lifecycle
> > but maven has one and this is what people tend to understand
>
> As said this is nothing where you have to choose one over the other its
> even unclear to me what "the maven lifcycle" refers to? Maven CLI? How
> many people can really explain/understand how it works with all the
> setup of the realms and a like?
>
>
> > (one reason no ee lib is really osgi friendly if you look closer)
> > so the issue is not osgi -i like this system - but its people target
> > for a build system I think.
>
> OSGi is a specification, and you can use as much (or less) as you desire
> and with OSGi-Connect you can mix this with whatever you like, even JPMS
> can be modeled as OSGi (see Felix Atomos).
>
> > Agree we can enhance maven but yout point about osgi is to not test it
> > (you forgot all the cases of this random lifecycle to cite just a
> > trivial pitfall).
>
> I really don't get the point about "random lifecycle", there is nothing
> "random" in OSGi (as it would be devastating in any software if it where
> behaving random).
>
> > At least maven does not have that kind of issues and does not
> > need to document the best you can fo is either not test or
> > use some kind of chaos testing.
>
> Same here, in > 10 years of OSGi I never used "chaos testing" (what ever
> that means), of course it always depend how testable you write your
> code... and wasn't there recently a thread on the ML about the "chaos"
> in Maven? Maven Invoker, vs Verifier, Maven-plugin-test requiring
> discouraged maven-compat and then there are "more alternative
> approaches" so I think maven is still far a way from been all
> green-grasses and sunshine...
>
> Also please carefully read what was written in the Jira issue (and on
> this thread), I never suggested to "trow all away and let people use
> OSGi), the suggestion was to use OSGI under the hood to replace the
> (hard to manage) realm concept for API handling, make it accessible to
> the ones who likes to use it...
>
>
>
> Am 17.11.22 um 21:28 schrieb Romain Manni-Bucau:
> > Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> The great thing is that DS is not an "API" you use, it is just a
> >> convenient way to express what you provide and what you need, so you
> >> will never have any runtime dependency and thus can always choose
> >> another, you can even code all this "by hand" ... anyways I never heard
> >> it is "superseeded" or "legacy" do you have any normative statement
> >> about that?
> >>
> >
> > A new more modern spec was created because existing one(s) was not
> > sufficient.
> > Phrase it as you want but DS is no more a default choice as of today and
> if
> > you get back to the topic it is far to cover maven need.
> >
> >
> >
> >> > maven has a well defined lifecycle whereas OSGi wants to be ultra
> >> dynamic
> >>
> >> OSGi can be used in a dynamic way but still has "well defined lifecycle"
> >> and you are not forced to use the dynamics. and you can define the
> >> maven-lifecycle on top of it OSGi do not mandates any specific way to
> >> use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the other
> >> way round: Running in OSGi and embedding maven ...
> >>
> >
> > In IT you can always make everything working but does it help the
> ecosystem
> > or users?
> > The defined lifecycle of OSGi is for a system with no linear lifecycle
> but
> > maven has one and this is what people tend to understand (one reason no
> ee
> > lib is really osgi friendly if you look closer) so the issue is not osgi
> -
> > i like this system - but its people target for a build system I think.
> >
> >
> >
> >> > but almost untestable without sophisticated
> >> > solutions for enterprises apps)
> >>
> >> OSGi actually allows better testing (through DI and service layer),
> >> while the official maven-plugin-test still suffers from being bound to
> >> maven-compat and JUnit 3 .... so I can't really say testing "maven" is
> >> really anything I would call easy ;-)
> >>
> >
> > Agree we can enhance maven but yout point about osgi is to not test it
> (you
> > forgot all the cases of this random lifecycle to cite just a trivial
> > pitfall). At least maven does not have that kind of issues and does not
> > need to document the best you can fo is either not test or use some kind
> of
> > chaos testing.
> >
> >
> >
> >> > we should just stick to the excellent work Guillaume did and keep
> >> > decoupling our internal impls/deps from the exposed API we should
> >> > keep control now we have a real API we lacked for years.
> >>
> >> This work is actually nothing contradictory or "different" if one would
> >> use OSGi ...
> >>
> >
> > Right but it is opposed to your sample using ds @Reference for ex.
> >
> > Anyway, guess nobody will spend time on making it so no need to discuss
> it
> > much, no?
> >
> >
> >>
> >> Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau:
> >>> Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> >>> écrit :
> >>>
> >>>> For OSGi there is a DI framework name "Declarative Services", that is
> >>>> (from users POV) not any "complex" or different than Plexus, e.g a
> Mojo
> >>>> might simply look like:
> >>>>
> >>>> @Component
> >>>> MyMojo implements Mojo {
> >>>>
> >>>> @Reference
> >>>> Logger logger;
> >>>>
> >>>> @Overide
> >>>> void execute() {
> >>>> ... do it ! ...
> >>>> }
> >>>> }
> >>>>
> >>>> for the rest, you simply has a maven plugin that generates all the
> rest
> >>>> for you ... so very similar to what we have today, but with much more
> >>>> flexibility (not shown here as not required for most cases).
> >>>>
> >>>> And for the "breakage", as outlined in the linked issue [1], Tycho
> >>>> already use a Maven <-> OSGi bridge, so actually one can even combine
> >>>> both "worlds" ...
> >>>>
> >>>
> >>> We saw multiple times by the past we shouldn't expose any used API
> cause
> >> it
> >>> leads to conflicts, API incompatibilities etc... so reuse DS sounds
> like
> >>> redoing some previous errors (we got bitten by a single annotation from
> >>> cdi-api.jar so imagine if we use more ;)).
> >>> Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI so
> >> not
> >>> sure it is better than going back to plexus for end users.
> >>> Last issue is that it has a whole set of API for dynamism maven will
> not
> >>> get (to not make the system overcomplex and since it has no real need
> of
> >> it
> >>> - maven has a well defined lifecycle whereas OSGi wants to be ultra
> >> dynamic
> >>> which is good for some systems but almost untestable without
> >> sophisticated
> >>> solutions for enterprises apps) so think we should just stick to the
> >>> excellent work Guillaume did and keep decoupling our internal
> impls/deps
> >>> from the exposed API we should keep control now we have a real API we
> >>> lacked for years.
> >>>
> >>>
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/MNG-7518
> >>>>
> >>>> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
> >>>>> I do agree that debugging the provisioning side is *very* complicated
> >>>> when
> >>>>> there's a problem.
> >>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >>>> framework,
> >>>>> at least for simple plugins.
> >>>>> However, I definitely don't think pushing OSGi to plugins would be a
> >> good
> >>>>> idea : the cost and burden on plugin developers would outweigh the
> >>>> benefits.
> >>>>>
> >>>>> For extensions, and for maven itself, that is a different story
> though.
> >>>>> Maven and extensions could definitely benefit from OSGi, but this
> would
> >>>> be
> >>>>> a complete breakage and it would be hard to keep some level of
> >>>>> compatibility.
> >>>>>
> >>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <
> mail@laeubi-soft.de>
> >> a
> >>>>> écrit :
> >>>>>
> >>>>>> > Guess classrealm is fine for maven, it does not bring much
> issues
> >>>>>>
> >>>>>> As long as it works, maybe, maybe even if you write a simple maven
> >>>>>> plugin, but for any more complex it is just a complete mess.
> >>>>>>
> >>>>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>>>> complete silence ...
> >>>>>>
> >>>>>> Today I tried to refactor the name of one module of a more complex
> >>>>>> maven-plugin (with core extension), now I end up with
> >>>>>>
> >>>>>> org.apache.maven.InternalErrorException: Internal error:
> >>>>>> com.google.inject.ProvisionException: Unable to provision, see the
> >>>>>> following errors:
> >>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> >> bound.
> >>>>>>
> >>>>>> A whole bunch of stack trace but not a little info why the ***** it
> is
> >>>>>> not happy. Now I need to add random "exportedArtifact" /
> >>>>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>>>> transitive dependency, also here absolutely no documentation what
> this
> >>>>>> is supposed to do/work exactly beside some introduction that these
> xml
> >>>>>> tags exits and reading the code... or probably add maven-compat
> >>>>>> anywhere... or change provided to compile scope (even maven is
> jelling
> >>>>>> at me that's bad and I will be punished soon)... not counting the
> many
> >>>>>> times where I messed up the realms because I accidentally trying to
> >> use
> >>>>>> XppDom objects in extensions and plugins and something between got
> >>>>>> messed up.
> >>>>>>
> >>>>>> With OSGi i get clear errors for missing requirements, I can clearly
> >>>>>> share API (or declare I don't want to share it) and can reliable use
> >> it
> >>>>>> without classlaoding problems.
> >>>>>> If one wan't can even implement service filtering that would hide
> all
> >>>>>> "illegal implemented API" ... and you can even make sure API is
> >>>>>> (backward) compatible with implementation without waiting for a
> method
> >>>>>> not found exception or alike.
> >>>>>>
> >>>>>> Beside that I find it often more clear to distinguish between API
> >> (that
> >>>>>> is only implemented by the framework) and SPI (that might be
> >> implemented
> >>>>>> by extenders). So probably it would be good to have maven-api and
> >>>>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>>>
> >>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Guess classrealm is fine for maven, it does not bring much issues
> >> (less
> >>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability
> of
> >>>> the
> >>>>>>> exposed API.
> >>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it
> is
> >>>>>> mainly
> >>>>>>> a matter of deciding what we do for maven 3.
> >>>>>>> Due to the resources and work needed I assume we can just play the
> >>>>>>> status-quo for maven 3.
> >>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> >> don't
> >>>>>> like
> >>>>>>> much the idea but a compat layer can solve that smoothly for maven
> >>> = 4
> >>>>>> and
> >>>>>>> limit the work needed, no?
> >>>>>>>
> >>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> >> mail@laeubi-soft.de>
> >>>> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> If you really like to separate API and get out of the
> >> ClassRealm-Hell
> >>>>>>>> OSGi would be much more suitable:
> >>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>>>
> >>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
> >> or
> >>>> 11
> >>>>>>>> and
> >>>>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>>>
> >>>>>>>>> Gary
> >>>>>>>>>
> >>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <tamas@cservenak.net
> >
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Yes, to define rules is quite easy, but to make our users to
> obey
> >>>> them
> >>>>>>>> is
> >>>>>>>>>> tricky :D
> >>>>>>>>>>
> >>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
> >>>> used
> >>>>>> in
> >>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>>>
> >>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> >>>> really
> >>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>>>
> >>>>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>>>> - maven progress was really hindered by this, as that meant
> >>>> modifying
> >>>>>>>> (even
> >>>>>>>>>> internal) interfaces without breaking clients was impossible, so
> >> we
> >>>>>> went
> >>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
> >>>> back.
> >>>>>>>>>>
> >>>>>>>>>> The other day we had a question on ML about 4-alpha
> compatibility
> >>>>>>>> breakage,
> >>>>>>>>>> and from mail it was clear that the package of the referred
> class
> >>>> was
> >>>>>>>>>> having "internal" in it. I mean, developers should really take
> >> care
> >>>> of
> >>>>>>>> what
> >>>>>>>>>> they import.
> >>>>>>>>>>
> >>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >>>> compilation
> >>>>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>>>
> >>>>>>>>>> T
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <
> kwin@apache.org
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do
> we
> >>>>>> need
> >>>>>>>> to
> >>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >>>> backwards
> >>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>>>
> >>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
> >>>> classes
> >>>>>>>>>>> generated from
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>>>> My change in
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>>>> was not backwards compatible (removed a method on an interface
> >>>> which
> >>>>>>>> may
> >>>>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>>>
> >>>>>>>>>>> Konrad
> >>>>>>>>>>>
> >>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> >> grab"
> >>>>>>>>>> sadly,
> >>>>>>>>>>>> and is probably our major source of problems and reason we
> >> started
> >>>>>>>>>> Maven
> >>>>>>>>>>> 4
> >>>>>>>>>>>> API.
> >>>>>>>>>>>>
> >>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
> >>>> Maven
> >>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is
> NOT
> >>>>>>>>>>> ACCESSIBLE
> >>>>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>>>> And done.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say
> about
> >>>>>> same
> >>>>>>>>>>> topic
> >>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>>>
> >>>>>>>>>>>> HTH
> >>>>>>>>>>>> T
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> >> kwin@apache.org
> >>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I see now there is already
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should
> state:
> >>>> Only
> >>>>>>>>>>> Maven
> >>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>>>>>>>>>> everything
> >>>>>>>>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
> >> package
> >>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
> >> and
> >>>>>>>>>>> exported
> >>>>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> For example in the context of
> >>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> >> evolve
> >>>>>> the
> >>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>>>> We already figured out that this particular package
> (although
> >>>> not
> >>>>>>>>>>> part
> >>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> >> Maven
> >>>>>>>>>>> Plugin
> >>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >>>> compatible.
> >>>>>>>>>>>>>> What about others like
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>> ?
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>>>> ?>
> >>>>>>>>>>>>>> This interface should IMHO never been implemented outside
> >> Maven
> >>>>>>>>>> Core
> >>>>>>>>>>> but
> >>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>>>> ).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
> >> new
> >>>>>>>>>> ones
> >>>>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> >> way
> >>>>>>>>>> (but
> >>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >> outside
> >>>>>>>>>> core)
> >>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
> >> way
> >>>>>>>>>> (but
> >>>>>>>>>>>>> somehow add a marker that they should not be implemented
> >> outside
> >>>>>>>>>> core)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> For all three options we somehow need to come up with a list
> >> of
> >>>>>>>>>>>>> classes/interfaces currently being exported through the API
> >> class
> >>>>>>>>>>> loader,
> >>>>>>>>>>>>> which should be considered private and agree on an
> >>>>>> Annotation/Javadoc
> >>>>>>>>>>> for
> >>>>>>>>>>>>> that (something like
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>>>
> >>>>>>>>>>>>> or
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> >> <
> >>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Konrad
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
> A new more modern spec was created because existing one(s) was not
> sufficient.
DS is still widely used and much more lightweight, CDI is not
"superseeding" DS, beside that you can use CDI if you think it fits you
more, you can even use Blueprint if you more like "spring-xml" or any
other famous technique that might came up without the need for maven to
change a single line of code or any other plugin.
The question just was "isn't it too complex" and I showed that there are
techniques that completely hide that and even are close to what people
know of today. Still this do not limit us to what was shown.
> In IT you can always make everything working but does it help
> the ecosystem or users?
At least it would help the most common pitfalls when it comes to more
than a simple mojo. Ans especially if it comes to API evolution and
alike like core-extensions versus project extensions ...
> The defined lifecycle of OSGi is for a system with no linear lifecycle
> but maven has one and this is what people tend to understand
As said this is nothing where you have to choose one over the other its
even unclear to me what "the maven lifcycle" refers to? Maven CLI? How
many people can really explain/understand how it works with all the
setup of the realms and a like?
> (one reason no ee lib is really osgi friendly if you look closer)
> so the issue is not osgi -i like this system - but its people target
> for a build system I think.
OSGi is a specification, and you can use as much (or less) as you desire
and with OSGi-Connect you can mix this with whatever you like, even JPMS
can be modeled as OSGi (see Felix Atomos).
> Agree we can enhance maven but yout point about osgi is to not test it
> (you forgot all the cases of this random lifecycle to cite just a
> trivial pitfall).
I really don't get the point about "random lifecycle", there is nothing
"random" in OSGi (as it would be devastating in any software if it where
behaving random).
> At least maven does not have that kind of issues and does not
> need to document the best you can fo is either not test or
> use some kind of chaos testing.
Same here, in > 10 years of OSGi I never used "chaos testing" (what ever
that means), of course it always depend how testable you write your
code... and wasn't there recently a thread on the ML about the "chaos"
in Maven? Maven Invoker, vs Verifier, Maven-plugin-test requiring
discouraged maven-compat and then there are "more alternative
approaches" so I think maven is still far a way from been all
green-grasses and sunshine...
Also please carefully read what was written in the Jira issue (and on
this thread), I never suggested to "trow all away and let people use
OSGi), the suggestion was to use OSGI under the hood to replace the
(hard to manage) realm concept for API handling, make it accessible to
the ones who likes to use it...
Am 17.11.22 um 21:28 schrieb Romain Manni-Bucau:
> Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> The great thing is that DS is not an "API" you use, it is just a
>> convenient way to express what you provide and what you need, so you
>> will never have any runtime dependency and thus can always choose
>> another, you can even code all this "by hand" ... anyways I never heard
>> it is "superseeded" or "legacy" do you have any normative statement
>> about that?
>>
>
> A new more modern spec was created because existing one(s) was not
> sufficient.
> Phrase it as you want but DS is no more a default choice as of today and if
> you get back to the topic it is far to cover maven need.
>
>
>
>> > maven has a well defined lifecycle whereas OSGi wants to be ultra
>> dynamic
>>
>> OSGi can be used in a dynamic way but still has "well defined lifecycle"
>> and you are not forced to use the dynamics. and you can define the
>> maven-lifecycle on top of it OSGi do not mandates any specific way to
>> use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the other
>> way round: Running in OSGi and embedding maven ...
>>
>
> In IT you can always make everything working but does it help the ecosystem
> or users?
> The defined lifecycle of OSGi is for a system with no linear lifecycle but
> maven has one and this is what people tend to understand (one reason no ee
> lib is really osgi friendly if you look closer) so the issue is not osgi -
> i like this system - but its people target for a build system I think.
>
>
>
>> > but almost untestable without sophisticated
>> > solutions for enterprises apps)
>>
>> OSGi actually allows better testing (through DI and service layer),
>> while the official maven-plugin-test still suffers from being bound to
>> maven-compat and JUnit 3 .... so I can't really say testing "maven" is
>> really anything I would call easy ;-)
>>
>
> Agree we can enhance maven but yout point about osgi is to not test it (you
> forgot all the cases of this random lifecycle to cite just a trivial
> pitfall). At least maven does not have that kind of issues and does not
> need to document the best you can fo is either not test or use some kind of
> chaos testing.
>
>
>
>> > we should just stick to the excellent work Guillaume did and keep
>> > decoupling our internal impls/deps from the exposed API we should
>> > keep control now we have a real API we lacked for years.
>>
>> This work is actually nothing contradictory or "different" if one would
>> use OSGi ...
>>
>
> Right but it is opposed to your sample using ds @Reference for ex.
>
> Anyway, guess nobody will spend time on making it so no need to discuss it
> much, no?
>
>
>>
>> Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau:
>>> Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <ma...@laeubi-soft.de> a
>>> écrit :
>>>
>>>> For OSGi there is a DI framework name "Declarative Services", that is
>>>> (from users POV) not any "complex" or different than Plexus, e.g a Mojo
>>>> might simply look like:
>>>>
>>>> @Component
>>>> MyMojo implements Mojo {
>>>>
>>>> @Reference
>>>> Logger logger;
>>>>
>>>> @Overide
>>>> void execute() {
>>>> ... do it ! ...
>>>> }
>>>> }
>>>>
>>>> for the rest, you simply has a maven plugin that generates all the rest
>>>> for you ... so very similar to what we have today, but with much more
>>>> flexibility (not shown here as not required for most cases).
>>>>
>>>> And for the "breakage", as outlined in the linked issue [1], Tycho
>>>> already use a Maven <-> OSGi bridge, so actually one can even combine
>>>> both "worlds" ...
>>>>
>>>
>>> We saw multiple times by the past we shouldn't expose any used API cause
>> it
>>> leads to conflicts, API incompatibilities etc... so reuse DS sounds like
>>> redoing some previous errors (we got bitten by a single annotation from
>>> cdi-api.jar so imagine if we use more ;)).
>>> Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI so
>> not
>>> sure it is better than going back to plexus for end users.
>>> Last issue is that it has a whole set of API for dynamism maven will not
>>> get (to not make the system overcomplex and since it has no real need of
>> it
>>> - maven has a well defined lifecycle whereas OSGi wants to be ultra
>> dynamic
>>> which is good for some systems but almost untestable without
>> sophisticated
>>> solutions for enterprises apps) so think we should just stick to the
>>> excellent work Guillaume did and keep decoupling our internal impls/deps
>>> from the exposed API we should keep control now we have a real API we
>>> lacked for years.
>>>
>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/MNG-7518
>>>>
>>>> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
>>>>> I do agree that debugging the provisioning side is *very* complicated
>>>> when
>>>>> there's a problem.
>>>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
>>>> framework,
>>>>> at least for simple plugins.
>>>>> However, I definitely don't think pushing OSGi to plugins would be a
>> good
>>>>> idea : the cost and burden on plugin developers would outweigh the
>>>> benefits.
>>>>>
>>>>> For extensions, and for maven itself, that is a different story though.
>>>>> Maven and extensions could definitely benefit from OSGi, but this would
>>>> be
>>>>> a complete breakage and it would be hard to keep some level of
>>>>> compatibility.
>>>>>
>>>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de>
>> a
>>>>> écrit :
>>>>>
>>>>>> > Guess classrealm is fine for maven, it does not bring much issues
>>>>>>
>>>>>> As long as it works, maybe, maybe even if you write a simple maven
>>>>>> plugin, but for any more complex it is just a complete mess.
>>>>>>
>>>>>> Last time I asked on the mailing list how to debug that stuff ...
>>>>>> complete silence ...
>>>>>>
>>>>>> Today I tried to refactor the name of one module of a more complex
>>>>>> maven-plugin (with core extension), now I end up with
>>>>>>
>>>>>> org.apache.maven.InternalErrorException: Internal error:
>>>>>> com.google.inject.ProvisionException: Unable to provision, see the
>>>>>> following errors:
>>>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
>> bound.
>>>>>>
>>>>>> A whole bunch of stack trace but not a little info why the ***** it is
>>>>>> not happy. Now I need to add random "exportedArtifact" /
>>>>>> "exportedPackage" stuff to hope finding out where it has lost a
>>>>>> transitive dependency, also here absolutely no documentation what this
>>>>>> is supposed to do/work exactly beside some introduction that these xml
>>>>>> tags exits and reading the code... or probably add maven-compat
>>>>>> anywhere... or change provided to compile scope (even maven is jelling
>>>>>> at me that's bad and I will be punished soon)... not counting the many
>>>>>> times where I messed up the realms because I accidentally trying to
>> use
>>>>>> XppDom objects in extensions and plugins and something between got
>>>>>> messed up.
>>>>>>
>>>>>> With OSGi i get clear errors for missing requirements, I can clearly
>>>>>> share API (or declare I don't want to share it) and can reliable use
>> it
>>>>>> without classlaoding problems.
>>>>>> If one wan't can even implement service filtering that would hide all
>>>>>> "illegal implemented API" ... and you can even make sure API is
>>>>>> (backward) compatible with implementation without waiting for a method
>>>>>> not found exception or alike.
>>>>>>
>>>>>> Beside that I find it often more clear to distinguish between API
>> (that
>>>>>> is only implemented by the framework) and SPI (that might be
>> implemented
>>>>>> by extenders). So probably it would be good to have maven-api and
>>>>>> maven-spi (instead of "maven-core") to make this clear.
>>>>>>
>>>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Guess classrealm is fine for maven, it does not bring much issues
>> (less
>>>>>>> than OSGi or JPMS to be concrete), the real issue is the stability of
>>>> the
>>>>>>> exposed API.
>>>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
>>>>>> mainly
>>>>>>> a matter of deciding what we do for maven 3.
>>>>>>> Due to the resources and work needed I assume we can just play the
>>>>>>> status-quo for maven 3.
>>>>>>> Remaining question is for maven 4 do we drop the compatibilty. I
>> don't
>>>>>> like
>>>>>>> much the idea but a compat layer can solve that smoothly for maven
>>> = 4
>>>>>> and
>>>>>>> limit the work needed, no?
>>>>>>>
>>>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
>> mail@laeubi-soft.de>
>>>> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> If you really like to separate API and get out of the
>> ClassRealm-Hell
>>>>>>>> OSGi would be much more suitable:
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>>>>>
>>>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
>> or
>>>> 11
>>>>>>>> and
>>>>>>>>> adopt JPMS to better define its public APIs.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>>
>>>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yes, to define rules is quite easy, but to make our users to obey
>>>> them
>>>>>>>> is
>>>>>>>>>> tricky :D
>>>>>>>>>>
>>>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
>>>> used
>>>>>> in
>>>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>>>>>
>>>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
>>>> really
>>>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>>>>>
>>>>>>>>>> Ultimately, this was the whole reason for API:
>>>>>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>>>>>> - maven progress was really hindered by this, as that meant
>>>> modifying
>>>>>>>> (even
>>>>>>>>>> internal) interfaces without breaking clients was impossible, so
>> we
>>>>>> went
>>>>>>>>>> with tricks, and more tricks and even more tricks that now pays
>>>> back.
>>>>>>>>>>
>>>>>>>>>> The other day we had a question on ML about 4-alpha compatibility
>>>>>>>> breakage,
>>>>>>>>>> and from mail it was clear that the package of the referred class
>>>> was
>>>>>>>>>> having "internal" in it. I mean, developers should really take
>> care
>>>> of
>>>>>>>> what
>>>>>>>>>> they import.
>>>>>>>>>>
>>>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
>>>> compilation
>>>>>>>>>> against "encapsulated" internal classes....
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>>>>>
>>>>>>>>>> T
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kwin@apache.org
>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I guess this is the easy part, the tricky question remains: Do we
>>>>>> need
>>>>>>>> to
>>>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>>>> backwards
>>>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>>>>>
>>>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
>>>> classes
>>>>>>>>>>> generated from
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>>>>>> My change in
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>>>>>> was not backwards compatible (removed a method on an interface
>>>> which
>>>>>>>> may
>>>>>>>>>>> have been implemented by extensions...)
>>>>>>>>>>>
>>>>>>>>>>> Konrad
>>>>>>>>>>>
>>>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>>>>>
>>>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
>> grab"
>>>>>>>>>> sadly,
>>>>>>>>>>>> and is probably our major source of problems and reason we
>> started
>>>>>>>>>> Maven
>>>>>>>>>>> 4
>>>>>>>>>>>> API.
>>>>>>>>>>>>
>>>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
>>>> Maven
>>>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>>>>>>>>>> ACCESSIBLE
>>>>>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>>>>>> And done.
>>>>>>>>>>>>
>>>>>>>>>>>> Just as an example, here is what Maven Resolver has to say about
>>>>>> same
>>>>>>>>>>> topic
>>>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>>>>>
>>>>>>>>>>>> HTH
>>>>>>>>>>>> T
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
>> kwin@apache.org
>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I see now there is already
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>>>>>> but to me the javadoc is not explicit enough. It should state:
>>>> Only
>>>>>>>>>>> Maven
>>>>>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>>>>>> everything
>>>>>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>>>>>> plugin/extension developers.
>>>>>>>>>>>>>> For Maven 4 a completely separate API was established in
>> package
>>>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
>> and
>>>>>>>>>>> exported
>>>>>>>>>>>>> in Maven 3?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For example in the context of
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
>> evolve
>>>>>> the
>>>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>>>>>> We already figured out that this particular package (although
>>>> not
>>>>>>>>>>> part
>>>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
>> Maven
>>>>>>>>>>> Plugin
>>>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
>>>> compatible.
>>>>>>>>>>>>>> What about others like
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>> ?
>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>>>> ?>
>>>>>>>>>>>>>> This interface should IMHO never been implemented outside
>> Maven
>>>>>>>>>> Core
>>>>>>>>>>> but
>>>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>>>> ).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
>> new
>>>>>>>>>> ones
>>>>>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
>> way
>>>>>>>>>> (but
>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>> outside
>>>>>>>>>> core)
>>>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
>> way
>>>>>>>>>> (but
>>>>>>>>>>>>> somehow add a marker that they should not be implemented
>> outside
>>>>>>>>>> core)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For all three options we somehow need to come up with a list
>> of
>>>>>>>>>>>>> classes/interfaces currently being exported through the API
>> class
>>>>>>>>>>> loader,
>>>>>>>>>>>>> which should be considered private and agree on an
>>>>>> Annotation/Javadoc
>>>>>>>>>>> for
>>>>>>>>>>>>> that (something like
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>>>
>>>>>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
>> <
>>>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Konrad
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 17 nov. 2022 à 20:25, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> The great thing is that DS is not an "API" you use, it is just a
> convenient way to express what you provide and what you need, so you
> will never have any runtime dependency and thus can always choose
> another, you can even code all this "by hand" ... anyways I never heard
> it is "superseeded" or "legacy" do you have any normative statement
> about that?
>
A new more modern spec was created because existing one(s) was not
sufficient.
Phrase it as you want but DS is no more a default choice as of today and if
you get back to the topic it is far to cover maven need.
> > maven has a well defined lifecycle whereas OSGi wants to be ultra
> dynamic
>
> OSGi can be used in a dynamic way but still has "well defined lifecycle"
> and you are not forced to use the dynamics. and you can define the
> maven-lifecycle on top of it OSGi do not mandates any specific way to
> use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the other
> way round: Running in OSGi and embedding maven ...
>
In IT you can always make everything working but does it help the ecosystem
or users?
The defined lifecycle of OSGi is for a system with no linear lifecycle but
maven has one and this is what people tend to understand (one reason no ee
lib is really osgi friendly if you look closer) so the issue is not osgi -
i like this system - but its people target for a build system I think.
> > but almost untestable without sophisticated
> > solutions for enterprises apps)
>
> OSGi actually allows better testing (through DI and service layer),
> while the official maven-plugin-test still suffers from being bound to
> maven-compat and JUnit 3 .... so I can't really say testing "maven" is
> really anything I would call easy ;-)
>
Agree we can enhance maven but yout point about osgi is to not test it (you
forgot all the cases of this random lifecycle to cite just a trivial
pitfall). At least maven does not have that kind of issues and does not
need to document the best you can fo is either not test or use some kind of
chaos testing.
> > we should just stick to the excellent work Guillaume did and keep
> > decoupling our internal impls/deps from the exposed API we should
> > keep control now we have a real API we lacked for years.
>
> This work is actually nothing contradictory or "different" if one would
> use OSGi ...
>
Right but it is opposed to your sample using ds @Reference for ex.
Anyway, guess nobody will spend time on making it so no need to discuss it
much, no?
>
> Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau:
> > Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> For OSGi there is a DI framework name "Declarative Services", that is
> >> (from users POV) not any "complex" or different than Plexus, e.g a Mojo
> >> might simply look like:
> >>
> >> @Component
> >> MyMojo implements Mojo {
> >>
> >> @Reference
> >> Logger logger;
> >>
> >> @Overide
> >> void execute() {
> >> ... do it ! ...
> >> }
> >> }
> >>
> >> for the rest, you simply has a maven plugin that generates all the rest
> >> for you ... so very similar to what we have today, but with much more
> >> flexibility (not shown here as not required for most cases).
> >>
> >> And for the "breakage", as outlined in the linked issue [1], Tycho
> >> already use a Maven <-> OSGi bridge, so actually one can even combine
> >> both "worlds" ...
> >>
> >
> > We saw multiple times by the past we shouldn't expose any used API cause
> it
> > leads to conflicts, API incompatibilities etc... so reuse DS sounds like
> > redoing some previous errors (we got bitten by a single annotation from
> > cdi-api.jar so imagine if we use more ;)).
> > Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI so
> not
> > sure it is better than going back to plexus for end users.
> > Last issue is that it has a whole set of API for dynamism maven will not
> > get (to not make the system overcomplex and since it has no real need of
> it
> > - maven has a well defined lifecycle whereas OSGi wants to be ultra
> dynamic
> > which is good for some systems but almost untestable without
> sophisticated
> > solutions for enterprises apps) so think we should just stick to the
> > excellent work Guillaume did and keep decoupling our internal impls/deps
> > from the exposed API we should keep control now we have a real API we
> > lacked for years.
> >
> >
> >>
> >> [1] https://issues.apache.org/jira/browse/MNG-7518
> >>
> >> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
> >>> I do agree that debugging the provisioning side is *very* complicated
> >> when
> >>> there's a problem.
> >>> I'd be happy to get rid of sisu/plexus and use a more simple DI
> >> framework,
> >>> at least for simple plugins.
> >>> However, I definitely don't think pushing OSGi to plugins would be a
> good
> >>> idea : the cost and burden on plugin developers would outweigh the
> >> benefits.
> >>>
> >>> For extensions, and for maven itself, that is a different story though.
> >>> Maven and extensions could definitely benefit from OSGi, but this would
> >> be
> >>> a complete breakage and it would be hard to keep some level of
> >>> compatibility.
> >>>
> >>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> >>> écrit :
> >>>
> >>>> > Guess classrealm is fine for maven, it does not bring much issues
> >>>>
> >>>> As long as it works, maybe, maybe even if you write a simple maven
> >>>> plugin, but for any more complex it is just a complete mess.
> >>>>
> >>>> Last time I asked on the mailing list how to debug that stuff ...
> >>>> complete silence ...
> >>>>
> >>>> Today I tried to refactor the name of one module of a more complex
> >>>> maven-plugin (with core extension), now I end up with
> >>>>
> >>>> org.apache.maven.InternalErrorException: Internal error:
> >>>> com.google.inject.ProvisionException: Unable to provision, see the
> >>>> following errors:
> >>>> 1) No implementation for org.eclipse.aether.RepositorySystem was
> bound.
> >>>>
> >>>> A whole bunch of stack trace but not a little info why the ***** it is
> >>>> not happy. Now I need to add random "exportedArtifact" /
> >>>> "exportedPackage" stuff to hope finding out where it has lost a
> >>>> transitive dependency, also here absolutely no documentation what this
> >>>> is supposed to do/work exactly beside some introduction that these xml
> >>>> tags exits and reading the code... or probably add maven-compat
> >>>> anywhere... or change provided to compile scope (even maven is jelling
> >>>> at me that's bad and I will be punished soon)... not counting the many
> >>>> times where I messed up the realms because I accidentally trying to
> use
> >>>> XppDom objects in extensions and plugins and something between got
> >>>> messed up.
> >>>>
> >>>> With OSGi i get clear errors for missing requirements, I can clearly
> >>>> share API (or declare I don't want to share it) and can reliable use
> it
> >>>> without classlaoding problems.
> >>>> If one wan't can even implement service filtering that would hide all
> >>>> "illegal implemented API" ... and you can even make sure API is
> >>>> (backward) compatible with implementation without waiting for a method
> >>>> not found exception or alike.
> >>>>
> >>>> Beside that I find it often more clear to distinguish between API
> (that
> >>>> is only implemented by the framework) and SPI (that might be
> implemented
> >>>> by extenders). So probably it would be good to have maven-api and
> >>>> maven-spi (instead of "maven-core") to make this clear.
> >>>>
> >>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>>>> Hi,
> >>>>>
> >>>>> Guess classrealm is fine for maven, it does not bring much issues
> (less
> >>>>> than OSGi or JPMS to be concrete), the real issue is the stability of
> >> the
> >>>>> exposed API.
> >>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
> >>>> mainly
> >>>>> a matter of deciding what we do for maven 3.
> >>>>> Due to the resources and work needed I assume we can just play the
> >>>>> status-quo for maven 3.
> >>>>> Remaining question is for maven 4 do we drop the compatibilty. I
> don't
> >>>> like
> >>>>> much the idea but a compat layer can solve that smoothly for maven
> >= 4
> >>>> and
> >>>>> limit the work needed, no?
> >>>>>
> >>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <
> mail@laeubi-soft.de>
> >> a
> >>>>> écrit :
> >>>>>
> >>>>>> If you really like to separate API and get out of the
> ClassRealm-Hell
> >>>>>> OSGi would be much more suitable:
> >>>>>>
> >>>>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>>>
> >>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9
> or
> >> 11
> >>>>>> and
> >>>>>>> adopt JPMS to better define its public APIs.
> >>>>>>>
> >>>>>>> Gary
> >>>>>>>
> >>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> Yes, to define rules is quite easy, but to make our users to obey
> >> them
> >>>>>> is
> >>>>>>>> tricky :D
> >>>>>>>>
> >>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
> >> used
> >>>> in
> >>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>>>
> >>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> >> really
> >>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>>>
> >>>>>>>> Ultimately, this was the whole reason for API:
> >>>>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>>>> - maven progress was really hindered by this, as that meant
> >> modifying
> >>>>>> (even
> >>>>>>>> internal) interfaces without breaking clients was impossible, so
> we
> >>>> went
> >>>>>>>> with tricks, and more tricks and even more tricks that now pays
> >> back.
> >>>>>>>>
> >>>>>>>> The other day we had a question on ML about 4-alpha compatibility
> >>>>>> breakage,
> >>>>>>>> and from mail it was clear that the package of the referred class
> >> was
> >>>>>>>> having "internal" in it. I mean, developers should really take
> care
> >> of
> >>>>>> what
> >>>>>>>> they import.
> >>>>>>>>
> >>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> >> compilation
> >>>>>>>> against "encapsulated" internal classes....
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>>>
> >>>>>>>> T
> >>>>>>>>
> >>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kwin@apache.org
> >
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I guess this is the easy part, the tricky question remains: Do we
> >>>> need
> >>>>>> to
> >>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> >> backwards
> >>>>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>>>
> >>>>>>>>> This wasn't handled consistently in master till now, e.g. the
> >> classes
> >>>>>>>>> generated from
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>>>> My change in
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>>>> was not backwards compatible (removed a method on an interface
> >> which
> >>>>>> may
> >>>>>>>>> have been implemented by extensions...)
> >>>>>>>>>
> >>>>>>>>> Konrad
> >>>>>>>>>
> >>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>>>
> >>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can
> grab"
> >>>>>>>> sadly,
> >>>>>>>>>> and is probably our major source of problems and reason we
> started
> >>>>>>>> Maven
> >>>>>>>>> 4
> >>>>>>>>>> API.
> >>>>>>>>>>
> >>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
> >> Maven
> >>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >>>>>>>>> ACCESSIBLE
> >>>>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>>>> And done.
> >>>>>>>>>>
> >>>>>>>>>> Just as an example, here is what Maven Resolver has to say about
> >>>> same
> >>>>>>>>> topic
> >>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>>>
> >>>>>>>>>> HTH
> >>>>>>>>>> T
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <
> kwin@apache.org
> >>>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> I see now there is already
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>>>> but to me the javadoc is not explicit enough. It should state:
> >> Only
> >>>>>>>>> Maven
> >>>>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>>>
> >>>>>>>>>>> Konrad
> >>>>>>>>>>>
> >>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>>>>>>>> everything
> >>>>>>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>>>>>> plugin/extension developers.
> >>>>>>>>>>>> For Maven 4 a completely separate API was established in
> package
> >>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used
> and
> >>>>>>>>> exported
> >>>>>>>>>>> in Maven 3?
> >>>>>>>>>>>>
> >>>>>>>>>>>> For example in the context of
> >>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to
> evolve
> >>>> the
> >>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>>>> We already figured out that this particular package (although
> >> not
> >>>>>>>>> part
> >>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as
> Maven
> >>>>>>>>> Plugin
> >>>>>>>>>>> Tools, therefore this probably needs to stay backwards
> >> compatible.
> >>>>>>>>>>>> What about others like
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>> ?
> >>>>>>>>>>> <
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>>>> ?>
> >>>>>>>>>>>> This interface should IMHO never been implemented outside
> Maven
> >>>>>>>> Core
> >>>>>>>>> but
> >>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>> <
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>>>> ).
> >>>>>>>>>>>>
> >>>>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create
> new
> >>>>>>>> ones
> >>>>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible
> way
> >>>>>>>> (but
> >>>>>>>>>>> somehow add a marker that they should not be implemented
> outside
> >>>>>>>> core)
> >>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible
> way
> >>>>>>>> (but
> >>>>>>>>>>> somehow add a marker that they should not be implemented
> outside
> >>>>>>>> core)
> >>>>>>>>>>>>
> >>>>>>>>>>>> For all three options we somehow need to come up with a list
> of
> >>>>>>>>>>> classes/interfaces currently being exported through the API
> class
> >>>>>>>>> loader,
> >>>>>>>>>>> which should be considered private and agree on an
> >>>> Annotation/Javadoc
> >>>>>>>>> for
> >>>>>>>>>>> that (something like
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>> <
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>>>
> >>>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution
> <
> >>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>>>
> >>>>>>>>>>>> WDYT?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Konrad
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
The great thing is that DS is not an "API" you use, it is just a
convenient way to express what you provide and what you need, so you
will never have any runtime dependency and thus can always choose
another, you can even code all this "by hand" ... anyways I never heard
it is "superseeded" or "legacy" do you have any normative statement
about that?
> maven has a well defined lifecycle whereas OSGi wants to be ultra dynamic
OSGi can be used in a dynamic way but still has "well defined lifecycle"
and you are not forced to use the dynamics. and you can define the
maven-lifecycle on top of it OSGi do not mandates any specific way to
use it. e.g. Tycho embedds OSGi into maven, while m2eclipse do the other
way round: Running in OSGi and embedding maven ...
> but almost untestable without sophisticated
> solutions for enterprises apps)
OSGi actually allows better testing (through DI and service layer),
while the official maven-plugin-test still suffers from being bound to
maven-compat and JUnit 3 .... so I can't really say testing "maven" is
really anything I would call easy ;-)
> we should just stick to the excellent work Guillaume did and keep
> decoupling our internal impls/deps from the exposed API we should
> keep control now we have a real API we lacked for years.
This work is actually nothing contradictory or "different" if one would
use OSGi ...
Am 17.11.22 um 19:58 schrieb Romain Manni-Bucau:
> Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> For OSGi there is a DI framework name "Declarative Services", that is
>> (from users POV) not any "complex" or different than Plexus, e.g a Mojo
>> might simply look like:
>>
>> @Component
>> MyMojo implements Mojo {
>>
>> @Reference
>> Logger logger;
>>
>> @Overide
>> void execute() {
>> ... do it ! ...
>> }
>> }
>>
>> for the rest, you simply has a maven plugin that generates all the rest
>> for you ... so very similar to what we have today, but with much more
>> flexibility (not shown here as not required for most cases).
>>
>> And for the "breakage", as outlined in the linked issue [1], Tycho
>> already use a Maven <-> OSGi bridge, so actually one can even combine
>> both "worlds" ...
>>
>
> We saw multiple times by the past we shouldn't expose any used API cause it
> leads to conflicts, API incompatibilities etc... so reuse DS sounds like
> redoing some previous errors (we got bitten by a single annotation from
> cdi-api.jar so imagine if we use more ;)).
> Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI so not
> sure it is better than going back to plexus for end users.
> Last issue is that it has a whole set of API for dynamism maven will not
> get (to not make the system overcomplex and since it has no real need of it
> - maven has a well defined lifecycle whereas OSGi wants to be ultra dynamic
> which is good for some systems but almost untestable without sophisticated
> solutions for enterprises apps) so think we should just stick to the
> excellent work Guillaume did and keep decoupling our internal impls/deps
> from the exposed API we should keep control now we have a real API we
> lacked for years.
>
>
>>
>> [1] https://issues.apache.org/jira/browse/MNG-7518
>>
>> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
>>> I do agree that debugging the provisioning side is *very* complicated
>> when
>>> there's a problem.
>>> I'd be happy to get rid of sisu/plexus and use a more simple DI
>> framework,
>>> at least for simple plugins.
>>> However, I definitely don't think pushing OSGi to plugins would be a good
>>> idea : the cost and burden on plugin developers would outweigh the
>> benefits.
>>>
>>> For extensions, and for maven itself, that is a different story though.
>>> Maven and extensions could definitely benefit from OSGi, but this would
>> be
>>> a complete breakage and it would be hard to keep some level of
>>> compatibility.
>>>
>>> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de> a
>>> écrit :
>>>
>>>> > Guess classrealm is fine for maven, it does not bring much issues
>>>>
>>>> As long as it works, maybe, maybe even if you write a simple maven
>>>> plugin, but for any more complex it is just a complete mess.
>>>>
>>>> Last time I asked on the mailing list how to debug that stuff ...
>>>> complete silence ...
>>>>
>>>> Today I tried to refactor the name of one module of a more complex
>>>> maven-plugin (with core extension), now I end up with
>>>>
>>>> org.apache.maven.InternalErrorException: Internal error:
>>>> com.google.inject.ProvisionException: Unable to provision, see the
>>>> following errors:
>>>> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>>>>
>>>> A whole bunch of stack trace but not a little info why the ***** it is
>>>> not happy. Now I need to add random "exportedArtifact" /
>>>> "exportedPackage" stuff to hope finding out where it has lost a
>>>> transitive dependency, also here absolutely no documentation what this
>>>> is supposed to do/work exactly beside some introduction that these xml
>>>> tags exits and reading the code... or probably add maven-compat
>>>> anywhere... or change provided to compile scope (even maven is jelling
>>>> at me that's bad and I will be punished soon)... not counting the many
>>>> times where I messed up the realms because I accidentally trying to use
>>>> XppDom objects in extensions and plugins and something between got
>>>> messed up.
>>>>
>>>> With OSGi i get clear errors for missing requirements, I can clearly
>>>> share API (or declare I don't want to share it) and can reliable use it
>>>> without classlaoding problems.
>>>> If one wan't can even implement service filtering that would hide all
>>>> "illegal implemented API" ... and you can even make sure API is
>>>> (backward) compatible with implementation without waiting for a method
>>>> not found exception or alike.
>>>>
>>>> Beside that I find it often more clear to distinguish between API (that
>>>> is only implemented by the framework) and SPI (that might be implemented
>>>> by extenders). So probably it would be good to have maven-api and
>>>> maven-spi (instead of "maven-core") to make this clear.
>>>>
>>>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>>>> Hi,
>>>>>
>>>>> Guess classrealm is fine for maven, it does not bring much issues (less
>>>>> than OSGi or JPMS to be concrete), the real issue is the stability of
>> the
>>>>> exposed API.
>>>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
>>>> mainly
>>>>> a matter of deciding what we do for maven 3.
>>>>> Due to the resources and work needed I assume we can just play the
>>>>> status-quo for maven 3.
>>>>> Remaining question is for maven 4 do we drop the compatibilty. I don't
>>>> like
>>>>> much the idea but a compat layer can solve that smoothly for maven >= 4
>>>> and
>>>>> limit the work needed, no?
>>>>>
>>>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de>
>> a
>>>>> écrit :
>>>>>
>>>>>> If you really like to separate API and get out of the ClassRealm-Hell
>>>>>> OSGi would be much more suitable:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>>>
>>>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or
>> 11
>>>>>> and
>>>>>>> adopt JPMS to better define its public APIs.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>>>> wrote:
>>>>>>>
>>>>>>>> Yes, to define rules is quite easy, but to make our users to obey
>> them
>>>>>> is
>>>>>>>> tricky :D
>>>>>>>>
>>>>>>>> In general, I guess, we should. For this reason JapiCmp has been
>> used
>>>> in
>>>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>>>
>>>>>>>> But while this was "kinda simple" to achieve in Resolver, I am
>> really
>>>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>>>
>>>>>>>> Ultimately, this was the whole reason for API:
>>>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>>>> - maven progress was really hindered by this, as that meant
>> modifying
>>>>>> (even
>>>>>>>> internal) interfaces without breaking clients was impossible, so we
>>>> went
>>>>>>>> with tricks, and more tricks and even more tricks that now pays
>> back.
>>>>>>>>
>>>>>>>> The other day we had a question on ML about 4-alpha compatibility
>>>>>> breakage,
>>>>>>>> and from mail it was clear that the package of the referred class
>> was
>>>>>>>> having "internal" in it. I mean, developers should really take care
>> of
>>>>>> what
>>>>>>>> they import.
>>>>>>>>
>>>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
>> compilation
>>>>>>>> against "encapsulated" internal classes....
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>>>
>>>>>>>> T
>>>>>>>>
>>>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I guess this is the easy part, the tricky question remains: Do we
>>>> need
>>>>>> to
>>>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
>> backwards
>>>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>>>
>>>>>>>>> This wasn't handled consistently in master till now, e.g. the
>> classes
>>>>>>>>> generated from
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>>>> My change in
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>>>> was not backwards compatible (removed a method on an interface
>> which
>>>>>> may
>>>>>>>>> have been implemented by extensions...)
>>>>>>>>>
>>>>>>>>> Konrad
>>>>>>>>>
>>>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>>>
>>>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
>>>>>>>> sadly,
>>>>>>>>>> and is probably our major source of problems and reason we started
>>>>>>>> Maven
>>>>>>>>> 4
>>>>>>>>>> API.
>>>>>>>>>>
>>>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
>> Maven
>>>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>>>>>>>> ACCESSIBLE
>>>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>>>> And done.
>>>>>>>>>>
>>>>>>>>>> Just as an example, here is what Maven Resolver has to say about
>>>> same
>>>>>>>>> topic
>>>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>>>
>>>>>>>>>> HTH
>>>>>>>>>> T
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kwin@apache.org
>>>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I see now there is already
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>>>> but to me the javadoc is not explicit enough. It should state:
>> Only
>>>>>>>>> Maven
>>>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>>>
>>>>>>>>>>> Konrad
>>>>>>>>>>>
>>>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>>>> everything
>>>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>>>> plugin/extension developers.
>>>>>>>>>>>> For Maven 4 a completely separate API was established in package
>>>>>>>>>>> “org.apache.maven.api”, but what about the old packages used and
>>>>>>>>> exported
>>>>>>>>>>> in Maven 3?
>>>>>>>>>>>>
>>>>>>>>>>>> For example in the context of
>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve
>>>> the
>>>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>>>> We already figured out that this particular package (although
>> not
>>>>>>>>> part
>>>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
>>>>>>>>> Plugin
>>>>>>>>>>> Tools, therefore this probably needs to stay backwards
>> compatible.
>>>>>>>>>>>> What about others like
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>> ?
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>>>> ?>
>>>>>>>>>>>> This interface should IMHO never been implemented outside Maven
>>>>>>>> Core
>>>>>>>>> but
>>>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>>>> ).
>>>>>>>>>>>>
>>>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
>>>>>>>> ones
>>>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
>>>>>>>> (but
>>>>>>>>>>> somehow add a marker that they should not be implemented outside
>>>>>>>> core)
>>>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible way
>>>>>>>> (but
>>>>>>>>>>> somehow add a marker that they should not be implemented outside
>>>>>>>> core)
>>>>>>>>>>>>
>>>>>>>>>>>> For all three options we somehow need to come up with a list of
>>>>>>>>>>> classes/interfaces currently being exported through the API class
>>>>>>>>> loader,
>>>>>>>>>>> which should be considered private and agree on an
>>>> Annotation/Javadoc
>>>>>>>>> for
>>>>>>>>>>> that (something like
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>>>
>>>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
>>>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>>>
>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>> Konrad
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 17 nov. 2022 à 19:23, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> For OSGi there is a DI framework name "Declarative Services", that is
> (from users POV) not any "complex" or different than Plexus, e.g a Mojo
> might simply look like:
>
> @Component
> MyMojo implements Mojo {
>
> @Reference
> Logger logger;
>
> @Overide
> void execute() {
> ... do it ! ...
> }
> }
>
> for the rest, you simply has a maven plugin that generates all the rest
> for you ... so very similar to what we have today, but with much more
> flexibility (not shown here as not required for most cases).
>
> And for the "breakage", as outlined in the linked issue [1], Tycho
> already use a Maven <-> OSGi bridge, so actually one can even combine
> both "worlds" ...
>
We saw multiple times by the past we shouldn't expose any used API cause it
leads to conflicts, API incompatibilities etc... so reuse DS sounds like
redoing some previous errors (we got bitten by a single annotation from
cdi-api.jar so imagine if we use more ;)).
Also DS is starting to be legacy now OSGi superseeded it by OSGi-CDI so not
sure it is better than going back to plexus for end users.
Last issue is that it has a whole set of API for dynamism maven will not
get (to not make the system overcomplex and since it has no real need of it
- maven has a well defined lifecycle whereas OSGi wants to be ultra dynamic
which is good for some systems but almost untestable without sophisticated
solutions for enterprises apps) so think we should just stick to the
excellent work Guillaume did and keep decoupling our internal impls/deps
from the exposed API we should keep control now we have a real API we
lacked for years.
>
> [1] https://issues.apache.org/jira/browse/MNG-7518
>
> Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
> > I do agree that debugging the provisioning side is *very* complicated
> when
> > there's a problem.
> > I'd be happy to get rid of sisu/plexus and use a more simple DI
> framework,
> > at least for simple plugins.
> > However, I definitely don't think pushing OSGi to plugins would be a good
> > idea : the cost and burden on plugin developers would outweigh the
> benefits.
> >
> > For extensions, and for maven itself, that is a different story though.
> > Maven and extensions could definitely benefit from OSGi, but this would
> be
> > a complete breakage and it would be hard to keep some level of
> > compatibility.
> >
> > Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> > Guess classrealm is fine for maven, it does not bring much issues
> >>
> >> As long as it works, maybe, maybe even if you write a simple maven
> >> plugin, but for any more complex it is just a complete mess.
> >>
> >> Last time I asked on the mailing list how to debug that stuff ...
> >> complete silence ...
> >>
> >> Today I tried to refactor the name of one module of a more complex
> >> maven-plugin (with core extension), now I end up with
> >>
> >> org.apache.maven.InternalErrorException: Internal error:
> >> com.google.inject.ProvisionException: Unable to provision, see the
> >> following errors:
> >> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
> >>
> >> A whole bunch of stack trace but not a little info why the ***** it is
> >> not happy. Now I need to add random "exportedArtifact" /
> >> "exportedPackage" stuff to hope finding out where it has lost a
> >> transitive dependency, also here absolutely no documentation what this
> >> is supposed to do/work exactly beside some introduction that these xml
> >> tags exits and reading the code... or probably add maven-compat
> >> anywhere... or change provided to compile scope (even maven is jelling
> >> at me that's bad and I will be punished soon)... not counting the many
> >> times where I messed up the realms because I accidentally trying to use
> >> XppDom objects in extensions and plugins and something between got
> >> messed up.
> >>
> >> With OSGi i get clear errors for missing requirements, I can clearly
> >> share API (or declare I don't want to share it) and can reliable use it
> >> without classlaoding problems.
> >> If one wan't can even implement service filtering that would hide all
> >> "illegal implemented API" ... and you can even make sure API is
> >> (backward) compatible with implementation without waiting for a method
> >> not found exception or alike.
> >>
> >> Beside that I find it often more clear to distinguish between API (that
> >> is only implemented by the framework) and SPI (that might be implemented
> >> by extenders). So probably it would be good to have maven-api and
> >> maven-spi (instead of "maven-core") to make this clear.
> >>
> >> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> >>> Hi,
> >>>
> >>> Guess classrealm is fine for maven, it does not bring much issues (less
> >>> than OSGi or JPMS to be concrete), the real issue is the stability of
> the
> >>> exposed API.
> >>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
> >> mainly
> >>> a matter of deciding what we do for maven 3.
> >>> Due to the resources and work needed I assume we can just play the
> >>> status-quo for maven 3.
> >>> Remaining question is for maven 4 do we drop the compatibilty. I don't
> >> like
> >>> much the idea but a compat layer can solve that smoothly for maven >= 4
> >> and
> >>> limit the work needed, no?
> >>>
> >>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de>
> a
> >>> écrit :
> >>>
> >>>> If you really like to separate API and get out of the ClassRealm-Hell
> >>>> OSGi would be much more suitable:
> >>>>
> >>>> https://issues.apache.org/jira/browse/MNG-7518
> >>>>
> >>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or
> 11
> >>>> and
> >>>>> adopt JPMS to better define its public APIs.
> >>>>>
> >>>>> Gary
> >>>>>
> >>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
> >> wrote:
> >>>>>
> >>>>>> Yes, to define rules is quite easy, but to make our users to obey
> them
> >>>> is
> >>>>>> tricky :D
> >>>>>>
> >>>>>> In general, I guess, we should. For this reason JapiCmp has been
> used
> >> in
> >>>>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>>>
> >>>>>> But while this was "kinda simple" to achieve in Resolver, I am
> really
> >>>>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>>>
> >>>>>> Ultimately, this was the whole reason for API:
> >>>>>> - users "grabbed" whatever could get hold on and used
> >>>>>> - maven progress was really hindered by this, as that meant
> modifying
> >>>> (even
> >>>>>> internal) interfaces without breaking clients was impossible, so we
> >> went
> >>>>>> with tricks, and more tricks and even more tricks that now pays
> back.
> >>>>>>
> >>>>>> The other day we had a question on ML about 4-alpha compatibility
> >>>> breakage,
> >>>>>> and from mail it was clear that the package of the referred class
> was
> >>>>>> having "internal" in it. I mean, developers should really take care
> of
> >>>> what
> >>>>>> they import.
> >>>>>>
> >>>>>> This is another huge plus for Takari lifecycle, it FORBIDS
> compilation
> >>>>>> against "encapsulated" internal classes....
> >>>>>>
> >>>>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>>>
> >>>>>> T
> >>>>>>
> >>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
> >>>> wrote:
> >>>>>>
> >>>>>>> I guess this is the easy part, the tricky question remains: Do we
> >> need
> >>>> to
> >>>>>>> make sure that all Maven 3 API interfaces/classes stay 100%
> backwards
> >>>>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>>>
> >>>>>>> This wasn't handled consistently in master till now, e.g. the
> classes
> >>>>>>> generated from
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>>>> My change in
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>>>> was not backwards compatible (removed a method on an interface
> which
> >>>> may
> >>>>>>> have been implemented by extensions...)
> >>>>>>>
> >>>>>>> Konrad
> >>>>>>>
> >>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>>>
> >>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
> >>>>>> sadly,
> >>>>>>>> and is probably our major source of problems and reason we started
> >>>>>> Maven
> >>>>>>> 4
> >>>>>>>> API.
> >>>>>>>>
> >>>>>>>> IMO, I'd consider them as "whole", and just say "starting with
> Maven
> >>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >>>>>>> ACCESSIBLE
> >>>>>>>> ANYMORE FROM PLUGINS.
> >>>>>>>> And done.
> >>>>>>>>
> >>>>>>>> Just as an example, here is what Maven Resolver has to say about
> >> same
> >>>>>>> topic
> >>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>>>
> >>>>>>>> HTH
> >>>>>>>> T
> >>>>>>>>
> >>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kwin@apache.org
> >
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I see now there is already
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>>>> but to me the javadoc is not explicit enough. It should state:
> Only
> >>>>>>> Maven
> >>>>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>>>
> >>>>>>>>> Konrad
> >>>>>>>>>
> >>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>>>>>> everything
> >>>>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>>>> plugin/extension developers.
> >>>>>>>>>> For Maven 4 a completely separate API was established in package
> >>>>>>>>> “org.apache.maven.api”, but what about the old packages used and
> >>>>>>> exported
> >>>>>>>>> in Maven 3?
> >>>>>>>>>>
> >>>>>>>>>> For example in the context of
> >>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve
> >> the
> >>>>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>>>> We already figured out that this particular package (although
> not
> >>>>>>> part
> >>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
> >>>>>>> Plugin
> >>>>>>>>> Tools, therefore this probably needs to stay backwards
> compatible.
> >>>>>>>>>> What about others like
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>> ?
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>>>> ?>
> >>>>>>>>>> This interface should IMHO never been implemented outside Maven
> >>>>>> Core
> >>>>>>> but
> >>>>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>>>> ).
> >>>>>>>>>>
> >>>>>>>>>> There are three options coming to my mind:
> >>>>>>>>>>
> >>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
> >>>>>> ones
> >>>>>>>>> for Maven 4 which are not exported!
> >>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
> >>>>>> (but
> >>>>>>>>> somehow add a marker that they should not be implemented outside
> >>>>>> core)
> >>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible way
> >>>>>> (but
> >>>>>>>>> somehow add a marker that they should not be implemented outside
> >>>>>> core)
> >>>>>>>>>>
> >>>>>>>>>> For all three options we somehow need to come up with a list of
> >>>>>>>>> classes/interfaces currently being exported through the API class
> >>>>>>> loader,
> >>>>>>>>> which should be considered private and agree on an
> >> Annotation/Javadoc
> >>>>>>> for
> >>>>>>>>> that (something like
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>> <
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>>>
> >>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> >>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>>>
> >>>>>>>>>> WDYT?
> >>>>>>>>>>
> >>>>>>>>>> Konrad
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
For OSGi there is a DI framework name "Declarative Services", that is
(from users POV) not any "complex" or different than Plexus, e.g a Mojo
might simply look like:
@Component
MyMojo implements Mojo {
@Reference
Logger logger;
@Overide
void execute() {
... do it ! ...
}
}
for the rest, you simply has a maven plugin that generates all the rest
for you ... so very similar to what we have today, but with much more
flexibility (not shown here as not required for most cases).
And for the "breakage", as outlined in the linked issue [1], Tycho
already use a Maven <-> OSGi bridge, so actually one can even combine
both "worlds" ...
[1] https://issues.apache.org/jira/browse/MNG-7518
Am 17.11.22 um 17:48 schrieb Guillaume Nodet:
> I do agree that debugging the provisioning side is *very* complicated when
> there's a problem.
> I'd be happy to get rid of sisu/plexus and use a more simple DI framework,
> at least for simple plugins.
> However, I definitely don't think pushing OSGi to plugins would be a good
> idea : the cost and burden on plugin developers would outweigh the benefits.
>
> For extensions, and for maven itself, that is a different story though.
> Maven and extensions could definitely benefit from OSGi, but this would be
> a complete breakage and it would be hard to keep some level of
> compatibility.
>
> Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> > Guess classrealm is fine for maven, it does not bring much issues
>>
>> As long as it works, maybe, maybe even if you write a simple maven
>> plugin, but for any more complex it is just a complete mess.
>>
>> Last time I asked on the mailing list how to debug that stuff ...
>> complete silence ...
>>
>> Today I tried to refactor the name of one module of a more complex
>> maven-plugin (with core extension), now I end up with
>>
>> org.apache.maven.InternalErrorException: Internal error:
>> com.google.inject.ProvisionException: Unable to provision, see the
>> following errors:
>> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>>
>> A whole bunch of stack trace but not a little info why the ***** it is
>> not happy. Now I need to add random "exportedArtifact" /
>> "exportedPackage" stuff to hope finding out where it has lost a
>> transitive dependency, also here absolutely no documentation what this
>> is supposed to do/work exactly beside some introduction that these xml
>> tags exits and reading the code... or probably add maven-compat
>> anywhere... or change provided to compile scope (even maven is jelling
>> at me that's bad and I will be punished soon)... not counting the many
>> times where I messed up the realms because I accidentally trying to use
>> XppDom objects in extensions and plugins and something between got
>> messed up.
>>
>> With OSGi i get clear errors for missing requirements, I can clearly
>> share API (or declare I don't want to share it) and can reliable use it
>> without classlaoding problems.
>> If one wan't can even implement service filtering that would hide all
>> "illegal implemented API" ... and you can even make sure API is
>> (backward) compatible with implementation without waiting for a method
>> not found exception or alike.
>>
>> Beside that I find it often more clear to distinguish between API (that
>> is only implemented by the framework) and SPI (that might be implemented
>> by extenders). So probably it would be good to have maven-api and
>> maven-spi (instead of "maven-core") to make this clear.
>>
>> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
>>> Hi,
>>>
>>> Guess classrealm is fine for maven, it does not bring much issues (less
>>> than OSGi or JPMS to be concrete), the real issue is the stability of the
>>> exposed API.
>>> Thanks the hard work Guillaume did on that for maven 4 I guess it is
>> mainly
>>> a matter of deciding what we do for maven 3.
>>> Due to the resources and work needed I assume we can just play the
>>> status-quo for maven 3.
>>> Remaining question is for maven 4 do we drop the compatibilty. I don't
>> like
>>> much the idea but a compat layer can solve that smoothly for maven >= 4
>> and
>>> limit the work needed, no?
>>>
>>> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de> a
>>> écrit :
>>>
>>>> If you really like to separate API and get out of the ClassRealm-Hell
>>>> OSGi would be much more suitable:
>>>>
>>>> https://issues.apache.org/jira/browse/MNG-7518
>>>>
>>>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11
>>>> and
>>>>> adopt JPMS to better define its public APIs.
>>>>>
>>>>> Gary
>>>>>
>>>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
>> wrote:
>>>>>
>>>>>> Yes, to define rules is quite easy, but to make our users to obey them
>>>> is
>>>>>> tricky :D
>>>>>>
>>>>>> In general, I guess, we should. For this reason JapiCmp has been used
>> in
>>>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>>>
>>>>>> But while this was "kinda simple" to achieve in Resolver, I am really
>>>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>>>
>>>>>> Ultimately, this was the whole reason for API:
>>>>>> - users "grabbed" whatever could get hold on and used
>>>>>> - maven progress was really hindered by this, as that meant modifying
>>>> (even
>>>>>> internal) interfaces without breaking clients was impossible, so we
>> went
>>>>>> with tricks, and more tricks and even more tricks that now pays back.
>>>>>>
>>>>>> The other day we had a question on ML about 4-alpha compatibility
>>>> breakage,
>>>>>> and from mail it was clear that the package of the referred class was
>>>>>> having "internal" in it. I mean, developers should really take care of
>>>> what
>>>>>> they import.
>>>>>>
>>>>>> This is another huge plus for Takari lifecycle, it FORBIDS compilation
>>>>>> against "encapsulated" internal classes....
>>>>>>
>>>>>>
>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>>>
>>>>>> T
>>>>>>
>>>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
>>>> wrote:
>>>>>>
>>>>>>> I guess this is the easy part, the tricky question remains: Do we
>> need
>>>> to
>>>>>>> make sure that all Maven 3 API interfaces/classes stay 100% backwards
>>>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>>>
>>>>>>> This wasn't handled consistently in master till now, e.g. the classes
>>>>>>> generated from
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>>>> My change in
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>>>> was not backwards compatible (removed a method on an interface which
>>>> may
>>>>>>> have been implemented by extensions...)
>>>>>>>
>>>>>>> Konrad
>>>>>>>
>>>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>>>
>>>>>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
>>>>>> sadly,
>>>>>>>> and is probably our major source of problems and reason we started
>>>>>> Maven
>>>>>>> 4
>>>>>>>> API.
>>>>>>>>
>>>>>>>> IMO, I'd consider them as "whole", and just say "starting with Maven
>>>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>>>>>> ACCESSIBLE
>>>>>>>> ANYMORE FROM PLUGINS.
>>>>>>>> And done.
>>>>>>>>
>>>>>>>> Just as an example, here is what Maven Resolver has to say about
>> same
>>>>>>> topic
>>>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>>>
>>>>>>>> HTH
>>>>>>>> T
>>>>>>>>
>>>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I see now there is already
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>>>> but to me the javadoc is not explicit enough. It should state: Only
>>>>>>> Maven
>>>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>>>
>>>>>>>>> Konrad
>>>>>>>>>
>>>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>>>> everything
>>>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>>>> plugin/extension developers.
>>>>>>>>>> For Maven 4 a completely separate API was established in package
>>>>>>>>> “org.apache.maven.api”, but what about the old packages used and
>>>>>>> exported
>>>>>>>>> in Maven 3?
>>>>>>>>>>
>>>>>>>>>> For example in the context of
>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve
>> the
>>>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>>>> We already figured out that this particular package (although not
>>>>>>> part
>>>>>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
>>>>>>> Plugin
>>>>>>>>> Tools, therefore this probably needs to stay backwards compatible.
>>>>>>>>>> What about others like
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>> ?
>>>>>>>>> <
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>>>> ?>
>>>>>>>>>> This interface should IMHO never been implemented outside Maven
>>>>>> Core
>>>>>>> but
>>>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>> <
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>>>> ).
>>>>>>>>>>
>>>>>>>>>> There are three options coming to my mind:
>>>>>>>>>>
>>>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
>>>>>> ones
>>>>>>>>> for Maven 4 which are not exported!
>>>>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
>>>>>> (but
>>>>>>>>> somehow add a marker that they should not be implemented outside
>>>>>> core)
>>>>>>>>>> 3. Modify the existing interfaces in a backwards compatible way
>>>>>> (but
>>>>>>>>> somehow add a marker that they should not be implemented outside
>>>>>> core)
>>>>>>>>>>
>>>>>>>>>> For all three options we somehow need to come up with a list of
>>>>>>>>> classes/interfaces currently being exported through the API class
>>>>>>> loader,
>>>>>>>>> which should be considered private and agree on an
>> Annotation/Javadoc
>>>>>>> for
>>>>>>>>> that (something like
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>> <
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>>>
>>>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
>>>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>>
>>>>>>>>>> Konrad
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Guillaume Nodet <gn...@apache.org>.
I do agree that debugging the provisioning side is *very* complicated when
there's a problem.
I'd be happy to get rid of sisu/plexus and use a more simple DI framework,
at least for simple plugins.
However, I definitely don't think pushing OSGi to plugins would be a good
idea : the cost and burden on plugin developers would outweigh the benefits.
For extensions, and for maven itself, that is a different story though.
Maven and extensions could definitely benefit from OSGi, but this would be
a complete breakage and it would be hard to keep some level of
compatibility.
Le jeu. 17 nov. 2022 à 17:00, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> > Guess classrealm is fine for maven, it does not bring much issues
>
> As long as it works, maybe, maybe even if you write a simple maven
> plugin, but for any more complex it is just a complete mess.
>
> Last time I asked on the mailing list how to debug that stuff ...
> complete silence ...
>
> Today I tried to refactor the name of one module of a more complex
> maven-plugin (with core extension), now I end up with
>
> org.apache.maven.InternalErrorException: Internal error:
> com.google.inject.ProvisionException: Unable to provision, see the
> following errors:
> 1) No implementation for org.eclipse.aether.RepositorySystem was bound.
>
> A whole bunch of stack trace but not a little info why the ***** it is
> not happy. Now I need to add random "exportedArtifact" /
> "exportedPackage" stuff to hope finding out where it has lost a
> transitive dependency, also here absolutely no documentation what this
> is supposed to do/work exactly beside some introduction that these xml
> tags exits and reading the code... or probably add maven-compat
> anywhere... or change provided to compile scope (even maven is jelling
> at me that's bad and I will be punished soon)... not counting the many
> times where I messed up the realms because I accidentally trying to use
> XppDom objects in extensions and plugins and something between got
> messed up.
>
> With OSGi i get clear errors for missing requirements, I can clearly
> share API (or declare I don't want to share it) and can reliable use it
> without classlaoding problems.
> If one wan't can even implement service filtering that would hide all
> "illegal implemented API" ... and you can even make sure API is
> (backward) compatible with implementation without waiting for a method
> not found exception or alike.
>
> Beside that I find it often more clear to distinguish between API (that
> is only implemented by the framework) and SPI (that might be implemented
> by extenders). So probably it would be good to have maven-api and
> maven-spi (instead of "maven-core") to make this clear.
>
> Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> > Hi,
> >
> > Guess classrealm is fine for maven, it does not bring much issues (less
> > than OSGi or JPMS to be concrete), the real issue is the stability of the
> > exposed API.
> > Thanks the hard work Guillaume did on that for maven 4 I guess it is
> mainly
> > a matter of deciding what we do for maven 3.
> > Due to the resources and work needed I assume we can just play the
> > status-quo for maven 3.
> > Remaining question is for maven 4 do we drop the compatibilty. I don't
> like
> > much the idea but a compat layer can solve that smoothly for maven >= 4
> and
> > limit the work needed, no?
> >
> > 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de> a
> > écrit :
> >
> >> If you really like to separate API and get out of the ClassRealm-Hell
> >> OSGi would be much more suitable:
> >>
> >> https://issues.apache.org/jira/browse/MNG-7518
> >>
> >> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> >>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11
> >> and
> >>> adopt JPMS to better define its public APIs.
> >>>
> >>> Gary
> >>>
> >>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >>>
> >>>> Yes, to define rules is quite easy, but to make our users to obey them
> >> is
> >>>> tricky :D
> >>>>
> >>>> In general, I guess, we should. For this reason JapiCmp has been used
> in
> >>>> Resolver since 1.9.0 (as noted on refd page end).
> >>>>
> >>>> But while this was "kinda simple" to achieve in Resolver, I am really
> >>>> unsure if it is doable in Maven (sans 4 API) :(
> >>>>
> >>>> Ultimately, this was the whole reason for API:
> >>>> - users "grabbed" whatever could get hold on and used
> >>>> - maven progress was really hindered by this, as that meant modifying
> >> (even
> >>>> internal) interfaces without breaking clients was impossible, so we
> went
> >>>> with tricks, and more tricks and even more tricks that now pays back.
> >>>>
> >>>> The other day we had a question on ML about 4-alpha compatibility
> >> breakage,
> >>>> and from mail it was clear that the package of the referred class was
> >>>> having "internal" in it. I mean, developers should really take care of
> >> what
> >>>> they import.
> >>>>
> >>>> This is another huge plus for Takari lifecycle, it FORBIDS compilation
> >>>> against "encapsulated" internal classes....
> >>>>
> >>>>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>>>
> >>>> T
> >>>>
> >>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
> >> wrote:
> >>>>
> >>>>> I guess this is the easy part, the tricky question remains: Do we
> need
> >> to
> >>>>> make sure that all Maven 3 API interfaces/classes stay 100% backwards
> >>>>> compatible until we reach 4.100/5.0/whatever?
> >>>>>
> >>>>> This wasn't handled consistently in master till now, e.g. the classes
> >>>>> generated from
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>>>> are now immutable, i.e. lack setter methods in Maven 4.
> >>>>> My change in
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>>>> was not backwards compatible (removed a method on an interface which
> >> may
> >>>>> have been implemented by extensions...)
> >>>>>
> >>>>> Konrad
> >>>>>
> >>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>>>> Unsure we want to deprecate all of Maven :)
> >>>>>>
> >>>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
> >>>> sadly,
> >>>>>> and is probably our major source of problems and reason we started
> >>>> Maven
> >>>>> 4
> >>>>>> API.
> >>>>>>
> >>>>>> IMO, I'd consider them as "whole", and just say "starting with Maven
> >>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >>>>> ACCESSIBLE
> >>>>>> ANYMORE FROM PLUGINS.
> >>>>>> And done.
> >>>>>>
> >>>>>> Just as an example, here is what Maven Resolver has to say about
> same
> >>>>> topic
> >>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>>>
> >>>>>
> >>>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>>>
> >>>>>> HTH
> >>>>>> T
> >>>>>>
> >>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>>> I see now there is already
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>>>> but to me the javadoc is not explicit enough. It should state: Only
> >>>>> Maven
> >>>>>>> is allowed to implement/extend types with this annotation.
> >>>>>>>
> >>>>>>> Konrad
> >>>>>>>
> >>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>>>> Hi,
> >>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>>>> everything
> >>>>>>> somehow exposed through class loaders was considered API by
> >>>>>>> plugin/extension developers.
> >>>>>>>> For Maven 4 a completely separate API was established in package
> >>>>>>> “org.apache.maven.api”, but what about the old packages used and
> >>>>> exported
> >>>>>>> in Maven 3?
> >>>>>>>>
> >>>>>>>> For example in the context of
> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve
> the
> >>>>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>>>> We already figured out that this particular package (although not
> >>>>> part
> >>>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
> >>>>> Plugin
> >>>>>>> Tools, therefore this probably needs to stay backwards compatible.
> >>>>>>>> What about others like
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>> ?
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>>>> ?>
> >>>>>>>> This interface should IMHO never been implemented outside Maven
> >>>> Core
> >>>>> but
> >>>>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>>>> ).
> >>>>>>>>
> >>>>>>>> There are three options coming to my mind:
> >>>>>>>>
> >>>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
> >>>> ones
> >>>>>>> for Maven 4 which are not exported!
> >>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
> >>>> (but
> >>>>>>> somehow add a marker that they should not be implemented outside
> >>>> core)
> >>>>>>>> 3. Modify the existing interfaces in a backwards compatible way
> >>>> (but
> >>>>>>> somehow add a marker that they should not be implemented outside
> >>>> core)
> >>>>>>>>
> >>>>>>>> For all three options we somehow need to come up with a list of
> >>>>>>> classes/interfaces currently being exported through the API class
> >>>>> loader,
> >>>>>>> which should be considered private and agree on an
> Annotation/Javadoc
> >>>>> for
> >>>>>>> that (something like
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>>>
> >>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> >>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>>>
> >>>>>>>> WDYT?
> >>>>>>>>
> >>>>>>>> Konrad
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
------------------------
Guillaume Nodet
Re: Maven 3 API, backwards compatibility
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
> Guess classrealm is fine for maven, it does not bring much issues
As long as it works, maybe, maybe even if you write a simple maven
plugin, but for any more complex it is just a complete mess.
Last time I asked on the mailing list how to debug that stuff ...
complete silence ...
Today I tried to refactor the name of one module of a more complex
maven-plugin (with core extension), now I end up with
org.apache.maven.InternalErrorException: Internal error:
com.google.inject.ProvisionException: Unable to provision, see the
following errors:
1) No implementation for org.eclipse.aether.RepositorySystem was bound.
A whole bunch of stack trace but not a little info why the ***** it is
not happy. Now I need to add random "exportedArtifact" /
"exportedPackage" stuff to hope finding out where it has lost a
transitive dependency, also here absolutely no documentation what this
is supposed to do/work exactly beside some introduction that these xml
tags exits and reading the code... or probably add maven-compat
anywhere... or change provided to compile scope (even maven is jelling
at me that's bad and I will be punished soon)... not counting the many
times where I messed up the realms because I accidentally trying to use
XppDom objects in extensions and plugins and something between got
messed up.
With OSGi i get clear errors for missing requirements, I can clearly
share API (or declare I don't want to share it) and can reliable use it
without classlaoding problems.
If one wan't can even implement service filtering that would hide all
"illegal implemented API" ... and you can even make sure API is
(backward) compatible with implementation without waiting for a method
not found exception or alike.
Beside that I find it often more clear to distinguish between API (that
is only implemented by the framework) and SPI (that might be implemented
by extenders). So probably it would be good to have maven-api and
maven-spi (instead of "maven-core") to make this clear.
Am 16.11.22 um 14:53 schrieb Romain Manni-Bucau:
> Hi,
>
> Guess classrealm is fine for maven, it does not bring much issues (less
> than OSGi or JPMS to be concrete), the real issue is the stability of the
> exposed API.
> Thanks the hard work Guillaume did on that for maven 4 I guess it is mainly
> a matter of deciding what we do for maven 3.
> Due to the resources and work needed I assume we can just play the
> status-quo for maven 3.
> Remaining question is for maven 4 do we drop the compatibilty. I don't like
> much the idea but a compat layer can solve that smoothly for maven >= 4 and
> limit the work needed, no?
>
> 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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de> a
> écrit :
>
>> If you really like to separate API and get out of the ClassRealm-Hell
>> OSGi would be much more suitable:
>>
>> https://issues.apache.org/jira/browse/MNG-7518
>>
>> Am 16.11.22 um 12:30 schrieb Gary Gregory:
>>> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11
>> and
>>> adopt JPMS to better define its public APIs.
>>>
>>> Gary
>>>
>>> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote:
>>>
>>>> Yes, to define rules is quite easy, but to make our users to obey them
>> is
>>>> tricky :D
>>>>
>>>> In general, I guess, we should. For this reason JapiCmp has been used in
>>>> Resolver since 1.9.0 (as noted on refd page end).
>>>>
>>>> But while this was "kinda simple" to achieve in Resolver, I am really
>>>> unsure if it is doable in Maven (sans 4 API) :(
>>>>
>>>> Ultimately, this was the whole reason for API:
>>>> - users "grabbed" whatever could get hold on and used
>>>> - maven progress was really hindered by this, as that meant modifying
>> (even
>>>> internal) interfaces without breaking clients was impossible, so we went
>>>> with tricks, and more tricks and even more tricks that now pays back.
>>>>
>>>> The other day we had a question on ML about 4-alpha compatibility
>> breakage,
>>>> and from mail it was clear that the package of the referred class was
>>>> having "internal" in it. I mean, developers should really take care of
>> what
>>>> they import.
>>>>
>>>> This is another huge plus for Takari lifecycle, it FORBIDS compilation
>>>> against "encapsulated" internal classes....
>>>>
>>>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>>>
>>>> T
>>>>
>>>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
>> wrote:
>>>>
>>>>> I guess this is the easy part, the tricky question remains: Do we need
>> to
>>>>> make sure that all Maven 3 API interfaces/classes stay 100% backwards
>>>>> compatible until we reach 4.100/5.0/whatever?
>>>>>
>>>>> This wasn't handled consistently in master till now, e.g. the classes
>>>>> generated from
>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>>>> are now immutable, i.e. lack setter methods in Maven 4.
>>>>> My change in
>>>>>
>>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>>>> was not backwards compatible (removed a method on an interface which
>> may
>>>>> have been implemented by extensions...)
>>>>>
>>>>> Konrad
>>>>>
>>>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>>>> Unsure we want to deprecate all of Maven :)
>>>>>>
>>>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
>>>> sadly,
>>>>>> and is probably our major source of problems and reason we started
>>>> Maven
>>>>> 4
>>>>>> API.
>>>>>>
>>>>>> IMO, I'd consider them as "whole", and just say "starting with Maven
>>>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>>>> ACCESSIBLE
>>>>>> ANYMORE FROM PLUGINS.
>>>>>> And done.
>>>>>>
>>>>>> Just as an example, here is what Maven Resolver has to say about same
>>>>> topic
>>>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>>>
>>>>>
>>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>>>
>>>>>> HTH
>>>>>> T
>>>>>>
>>>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>>> I see now there is already
>>>>>>>
>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>>>> but to me the javadoc is not explicit enough. It should state: Only
>>>>> Maven
>>>>>>> is allowed to implement/extend types with this annotation.
>>>>>>>
>>>>>>> Konrad
>>>>>>>
>>>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>>>> Hi,
>>>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>>>> everything
>>>>>>> somehow exposed through class loaders was considered API by
>>>>>>> plugin/extension developers.
>>>>>>>> For Maven 4 a completely separate API was established in package
>>>>>>> “org.apache.maven.api”, but what about the old packages used and
>>>>> exported
>>>>>>> in Maven 3?
>>>>>>>>
>>>>>>>> For example in the context of
>>>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
>>>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>>>> We already figured out that this particular package (although not
>>>>> part
>>>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
>>>>> Plugin
>>>>>>> Tools, therefore this probably needs to stay backwards compatible.
>>>>>>>> What about others like
>>>>>>>
>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>> ?
>>>>>>> <
>>>>>>>
>>>>>
>>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>>>> ?>
>>>>>>>> This interface should IMHO never been implemented outside Maven
>>>> Core
>>>>> but
>>>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>>>
>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>> <
>>>>>>>
>>>>>
>>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>>>> ).
>>>>>>>>
>>>>>>>> There are three options coming to my mind:
>>>>>>>>
>>>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
>>>> ones
>>>>>>> for Maven 4 which are not exported!
>>>>>>>> 2. Modify the existing interfaces in a backwards compatible way
>>>> (but
>>>>>>> somehow add a marker that they should not be implemented outside
>>>> core)
>>>>>>>> 3. Modify the existing interfaces in a backwards compatible way
>>>> (but
>>>>>>> somehow add a marker that they should not be implemented outside
>>>> core)
>>>>>>>>
>>>>>>>> For all three options we somehow need to come up with a list of
>>>>>>> classes/interfaces currently being exported through the API class
>>>>> loader,
>>>>>>> which should be considered private and agree on an Annotation/Javadoc
>>>>> for
>>>>>>> that (something like
>>>>>>>
>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>> <
>>>>>>>
>>>>>
>>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>>>
>>>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
>>>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Konrad
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Guess classrealm is fine for maven, it does not bring much issues (less
than OSGi or JPMS to be concrete), the real issue is the stability of the
exposed API.
Thanks the hard work Guillaume did on that for maven 4 I guess it is mainly
a matter of deciding what we do for maven 3.
Due to the resources and work needed I assume we can just play the
status-quo for maven 3.
Remaining question is for maven 4 do we drop the compatibilty. I don't like
much the idea but a compat layer can solve that smoothly for maven >= 4 and
limit the work needed, no?
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 mer. 16 nov. 2022 à 13:00, Christoph Läubrich <ma...@laeubi-soft.de> a
écrit :
> If you really like to separate API and get out of the ClassRealm-Hell
> OSGi would be much more suitable:
>
> https://issues.apache.org/jira/browse/MNG-7518
>
> Am 16.11.22 um 12:30 schrieb Gary Gregory:
> > As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11
> and
> > adopt JPMS to better define its public APIs.
> >
> > Gary
> >
> > On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote:
> >
> >> Yes, to define rules is quite easy, but to make our users to obey them
> is
> >> tricky :D
> >>
> >> In general, I guess, we should. For this reason JapiCmp has been used in
> >> Resolver since 1.9.0 (as noted on refd page end).
> >>
> >> But while this was "kinda simple" to achieve in Resolver, I am really
> >> unsure if it is doable in Maven (sans 4 API) :(
> >>
> >> Ultimately, this was the whole reason for API:
> >> - users "grabbed" whatever could get hold on and used
> >> - maven progress was really hindered by this, as that meant modifying
> (even
> >> internal) interfaces without breaking clients was impossible, so we went
> >> with tricks, and more tricks and even more tricks that now pays back.
> >>
> >> The other day we had a question on ML about 4-alpha compatibility
> breakage,
> >> and from mail it was clear that the package of the referred class was
> >> having "internal" in it. I mean, developers should really take care of
> what
> >> they import.
> >>
> >> This is another huge plus for Takari lifecycle, it FORBIDS compilation
> >> against "encapsulated" internal classes....
> >>
> >>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >>
> >> T
> >>
> >> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
> wrote:
> >>
> >>> I guess this is the easy part, the tricky question remains: Do we need
> to
> >>> make sure that all Maven 3 API interfaces/classes stay 100% backwards
> >>> compatible until we reach 4.100/5.0/whatever?
> >>>
> >>> This wasn't handled consistently in master till now, e.g. the classes
> >>> generated from
> >>>
> >>
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> >>> are now immutable, i.e. lack setter methods in Maven 4.
> >>> My change in
> >>>
> >>
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> >>> was not backwards compatible (removed a method on an interface which
> may
> >>> have been implemented by extensions...)
> >>>
> >>> Konrad
> >>>
> >>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> >>>> Unsure we want to deprecate all of Maven :)
> >>>>
> >>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
> >> sadly,
> >>>> and is probably our major source of problems and reason we started
> >> Maven
> >>> 4
> >>>> API.
> >>>>
> >>>> IMO, I'd consider them as "whole", and just say "starting with Maven
> >>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> >>> ACCESSIBLE
> >>>> ANYMORE FROM PLUGINS.
> >>>> And done.
> >>>>
> >>>> Just as an example, here is what Maven Resolver has to say about same
> >>> topic
> >>>> (part of not-yet-released, vote is in process 1.9.1 version):
> >>>>
> >>>
> >>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >>>>
> >>>> HTH
> >>>> T
> >>>>
> >>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
> >>> wrote:
> >>>>
> >>>>> I see now there is already
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> >>>>> but to me the javadoc is not explicit enough. It should state: Only
> >>> Maven
> >>>>> is allowed to implement/extend types with this annotation.
> >>>>>
> >>>>> Konrad
> >>>>>
> >>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> >>>>>> Hi,
> >>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
> >>> everything
> >>>>> somehow exposed through class loaders was considered API by
> >>>>> plugin/extension developers.
> >>>>>> For Maven 4 a completely separate API was established in package
> >>>>> “org.apache.maven.api”, but what about the old packages used and
> >>> exported
> >>>>> in Maven 3?
> >>>>>>
> >>>>>> For example in the context of
> >>>>> https://issues.apache.org/jira/browse/MNG-7588 <
> >>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> >>>>> package “org.apache.maven.plugin.descriptor”.
> >>>>>> We already figured out that this particular package (although not
> >>> part
> >>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
> >>> Plugin
> >>>>> Tools, therefore this probably needs to stay backwards compatible.
> >>>>>> What about others like
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>> ?
> >>>>> <
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> >>>>> ?>
> >>>>>> This interface should IMHO never been implemented outside Maven
> >> Core
> >>> but
> >>>>> in fact it was exposed to all plugins/extensions (via
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>> <
> >>>>>
> >>>
> >>
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >>>>>> ).
> >>>>>>
> >>>>>> There are three options coming to my mind:
> >>>>>>
> >>>>>> 1. Deprecate the interfaces we don’t consider API and create new
> >> ones
> >>>>> for Maven 4 which are not exported!
> >>>>>> 2. Modify the existing interfaces in a backwards compatible way
> >> (but
> >>>>> somehow add a marker that they should not be implemented outside
> >> core)
> >>>>>> 3. Modify the existing interfaces in a backwards compatible way
> >> (but
> >>>>> somehow add a marker that they should not be implemented outside
> >> core)
> >>>>>>
> >>>>>> For all three options we somehow need to come up with a list of
> >>>>> classes/interfaces currently being exported through the API class
> >>> loader,
> >>>>> which should be considered private and agree on an Annotation/Javadoc
> >>> for
> >>>>> that (something like
> >>>>>
> >>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>> <
> >>>>>
> >>>
> >>
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >>>>
> >>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> >>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>> Konrad
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Christoph Läubrich <ma...@laeubi-soft.de>.
If you really like to separate API and get out of the ClassRealm-Hell
OSGi would be much more suitable:
https://issues.apache.org/jira/browse/MNG-7518
Am 16.11.22 um 12:30 schrieb Gary Gregory:
> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
> adopt JPMS to better define its public APIs.
>
> Gary
>
> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote:
>
>> Yes, to define rules is quite easy, but to make our users to obey them is
>> tricky :D
>>
>> In general, I guess, we should. For this reason JapiCmp has been used in
>> Resolver since 1.9.0 (as noted on refd page end).
>>
>> But while this was "kinda simple" to achieve in Resolver, I am really
>> unsure if it is doable in Maven (sans 4 API) :(
>>
>> Ultimately, this was the whole reason for API:
>> - users "grabbed" whatever could get hold on and used
>> - maven progress was really hindered by this, as that meant modifying (even
>> internal) interfaces without breaking clients was impossible, so we went
>> with tricks, and more tricks and even more tricks that now pays back.
>>
>> The other day we had a question on ML about 4-alpha compatibility breakage,
>> and from mail it was clear that the package of the referred class was
>> having "internal" in it. I mean, developers should really take care of what
>> they import.
>>
>> This is another huge plus for Takari lifecycle, it FORBIDS compilation
>> against "encapsulated" internal classes....
>>
>> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>>
>> T
>>
>> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org> wrote:
>>
>>> I guess this is the easy part, the tricky question remains: Do we need to
>>> make sure that all Maven 3 API interfaces/classes stay 100% backwards
>>> compatible until we reach 4.100/5.0/whatever?
>>>
>>> This wasn't handled consistently in master till now, e.g. the classes
>>> generated from
>>>
>> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
>>> are now immutable, i.e. lack setter methods in Maven 4.
>>> My change in
>>>
>> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
>>> was not backwards compatible (removed a method on an interface which may
>>> have been implemented by extensions...)
>>>
>>> Konrad
>>>
>>> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
>>>> Unsure we want to deprecate all of Maven :)
>>>>
>>>> But yes, in general, 3.x "Maven API" was "all that users can grab"
>> sadly,
>>>> and is probably our major source of problems and reason we started
>> Maven
>>> 4
>>>> API.
>>>>
>>>> IMO, I'd consider them as "whole", and just say "starting with Maven
>>>> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
>>> ACCESSIBLE
>>>> ANYMORE FROM PLUGINS.
>>>> And done.
>>>>
>>>> Just as an example, here is what Maven Resolver has to say about same
>>> topic
>>>> (part of not-yet-released, vote is in process 1.9.1 version):
>>>>
>>>
>> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>>>>
>>>> HTH
>>>> T
>>>>
>>>> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
>>> wrote:
>>>>
>>>>> I see now there is already
>>>>>
>>>
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>>>>> but to me the javadoc is not explicit enough. It should state: Only
>>> Maven
>>>>> is allowed to implement/extend types with this annotation.
>>>>>
>>>>> Konrad
>>>>>
>>>>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>>>>>> Hi,
>>>>>> Unfortunately Maven 3 didn’t define a proper API. In effect
>>> everything
>>>>> somehow exposed through class loaders was considered API by
>>>>> plugin/extension developers.
>>>>>> For Maven 4 a completely separate API was established in package
>>>>> “org.apache.maven.api”, but what about the old packages used and
>>> exported
>>>>> in Maven 3?
>>>>>>
>>>>>> For example in the context of
>>>>> https://issues.apache.org/jira/browse/MNG-7588 <
>>>>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
>>>>> package “org.apache.maven.plugin.descriptor”.
>>>>>> We already figured out that this particular package (although not
>>> part
>>>>> of the Maven 4 API) is used from both Maven Core as well as Maven
>>> Plugin
>>>>> Tools, therefore this probably needs to stay backwards compatible.
>>>>>> What about others like
>>>>>
>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>> ?
>>>>> <
>>>>>
>>>
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>>>>> ?>
>>>>>> This interface should IMHO never been implemented outside Maven
>> Core
>>> but
>>>>> in fact it was exposed to all plugins/extensions (via
>>>>>
>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>> <
>>>>>
>>>
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>>>>>> ).
>>>>>>
>>>>>> There are three options coming to my mind:
>>>>>>
>>>>>> 1. Deprecate the interfaces we don’t consider API and create new
>> ones
>>>>> for Maven 4 which are not exported!
>>>>>> 2. Modify the existing interfaces in a backwards compatible way
>> (but
>>>>> somehow add a marker that they should not be implemented outside
>> core)
>>>>>> 3. Modify the existing interfaces in a backwards compatible way
>> (but
>>>>> somehow add a marker that they should not be implemented outside
>> core)
>>>>>>
>>>>>> For all three options we somehow need to come up with a list of
>>>>> classes/interfaces currently being exported through the API class
>>> loader,
>>>>> which should be considered private and agree on an Annotation/Javadoc
>>> for
>>>>> that (something like
>>>>>
>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>> <
>>>>>
>>>
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>>>>
>>>>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
>>>>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Konrad
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Tamás Cservenák <ta...@cservenak.net>.
Maybe Maven 5, as if we do it in 4, we would break the whole world :)
Maven 4 will provide API, but will also keep "backward compat" to Maven 3,
kinda offer "transition time" for the plugins from 3 to 4. Maven 2
compatibility is out of scope naturally.
So with initial Maven 4 releases, plugins should still work in both, Maven
3 (ie. 3.8.6 and 3.9.0) and also Maven 4.
The moment the plugin uses the new API, the plugin immediately has the
prerequisite of Maven 4.... that may be "too high" or too sudden change for
some.
Still, if you want, nothing stops you changing/writing a plugin that uses
API only, and is Maven 4+ only, even today (well, once 4.0.0 stabilises).
Actually, many plugins have been converted by Guillaume to the new 4 API
already, just as a proof of concept, and to cover in API all the cases we
need. Look for `mvn4` branches in plugin reposes.
That's the idea.
T
On Wed, Nov 16, 2022 at 12:30 PM Gary Gregory <ga...@gmail.com>
wrote:
> As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
> adopt JPMS to better define its public APIs.
>
> Gary
>
> On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Yes, to define rules is quite easy, but to make our users to obey them is
> > tricky :D
> >
> > In general, I guess, we should. For this reason JapiCmp has been used in
> > Resolver since 1.9.0 (as noted on refd page end).
> >
> > But while this was "kinda simple" to achieve in Resolver, I am really
> > unsure if it is doable in Maven (sans 4 API) :(
> >
> > Ultimately, this was the whole reason for API:
> > - users "grabbed" whatever could get hold on and used
> > - maven progress was really hindered by this, as that meant modifying
> (even
> > internal) interfaces without breaking clients was impossible, so we went
> > with tricks, and more tricks and even more tricks that now pays back.
> >
> > The other day we had a question on ML about 4-alpha compatibility
> breakage,
> > and from mail it was clear that the package of the referred class was
> > having "internal" in it. I mean, developers should really take care of
> what
> > they import.
> >
> > This is another huge plus for Takari lifecycle, it FORBIDS compilation
> > against "encapsulated" internal classes....
> >
> >
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
> >
> > T
> >
> > On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org>
> wrote:
> >
> > > I guess this is the easy part, the tricky question remains: Do we need
> to
> > > make sure that all Maven 3 API interfaces/classes stay 100% backwards
> > > compatible until we reach 4.100/5.0/whatever?
> > >
> > > This wasn't handled consistently in master till now, e.g. the classes
> > > generated from
> > >
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > > are now immutable, i.e. lack setter methods in Maven 4.
> > > My change in
> > >
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > > was not backwards compatible (removed a method on an interface which
> may
> > > have been implemented by extensions...)
> > >
> > > Konrad
> > >
> > > On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > > > Unsure we want to deprecate all of Maven :)
> > > >
> > > > But yes, in general, 3.x "Maven API" was "all that users can grab"
> > sadly,
> > > > and is probably our major source of problems and reason we started
> > Maven
> > > 4
> > > > API.
> > > >
> > > > IMO, I'd consider them as "whole", and just say "starting with Maven
> > > > 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> > > ACCESSIBLE
> > > > ANYMORE FROM PLUGINS.
> > > > And done.
> > > >
> > > > Just as an example, here is what Maven Resolver has to say about same
> > > topic
> > > > (part of not-yet-released, vote is in process 1.9.1 version):
> > > >
> > >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > > >
> > > > HTH
> > > > T
> > > >
> > > > On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
> > > wrote:
> > > >
> > > > > I see now there is already
> > > > >
> > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > > > > but to me the javadoc is not explicit enough. It should state: Only
> > > Maven
> > > > > is allowed to implement/extend types with this annotation.
> > > > >
> > > > > Konrad
> > > > >
> > > > > On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > > > > Hi,
> > > > > > Unfortunately Maven 3 didn’t define a proper API. In effect
> > > everything
> > > > > somehow exposed through class loaders was considered API by
> > > > > plugin/extension developers.
> > > > > > For Maven 4 a completely separate API was established in package
> > > > > “org.apache.maven.api”, but what about the old packages used and
> > > exported
> > > > > in Maven 3?
> > > > > >
> > > > > > For example in the context of
> > > > > https://issues.apache.org/jira/browse/MNG-7588 <
> > > > > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve
> the
> > > > > package “org.apache.maven.plugin.descriptor”.
> > > > > > We already figured out that this particular package (although not
> > > part
> > > > > of the Maven 4 API) is used from both Maven Core as well as Maven
> > > Plugin
> > > > > Tools, therefore this probably needs to stay backwards compatible.
> > > > > > What about others like
> > > > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > ?
> > > > > <
> > > > >
> > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > > > ?>
> > > > > > This interface should IMHO never been implemented outside Maven
> > Core
> > > but
> > > > > in fact it was exposed to all plugins/extensions (via
> > > > >
> > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > > <
> > > > >
> > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > > >).
> > > > > >
> > > > > > There are three options coming to my mind:
> > > > > >
> > > > > > 1. Deprecate the interfaces we don’t consider API and create new
> > ones
> > > > > for Maven 4 which are not exported!
> > > > > > 2. Modify the existing interfaces in a backwards compatible way
> > (but
> > > > > somehow add a marker that they should not be implemented outside
> > core)
> > > > > > 3. Modify the existing interfaces in a backwards compatible way
> > (but
> > > > > somehow add a marker that they should not be implemented outside
> > core)
> > > > > >
> > > > > > For all three options we somehow need to come up with a list of
> > > > > classes/interfaces currently being exported through the API class
> > > loader,
> > > > > which should be considered private and agree on an
> Annotation/Javadoc
> > > for
> > > > > that (something like
> > > > >
> > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > > > <
> > > > >
> > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > >
> > > > > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> > > > > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > > > > >
> > > > > > WDYT?
> > > > > >
> > > > > > Konrad
> > > > > >
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Maven 3 API, backwards compatibility
Posted by Gary Gregory <ga...@gmail.com>.
As much as I dislike JPMS, maybe Maven 4 should migrate to Java 9 or 11 and
adopt JPMS to better define its public APIs.
Gary
On Wed, Nov 16, 2022, 05:06 Tamás Cservenák <ta...@cservenak.net> wrote:
> Yes, to define rules is quite easy, but to make our users to obey them is
> tricky :D
>
> In general, I guess, we should. For this reason JapiCmp has been used in
> Resolver since 1.9.0 (as noted on refd page end).
>
> But while this was "kinda simple" to achieve in Resolver, I am really
> unsure if it is doable in Maven (sans 4 API) :(
>
> Ultimately, this was the whole reason for API:
> - users "grabbed" whatever could get hold on and used
> - maven progress was really hindered by this, as that meant modifying (even
> internal) interfaces without breaking clients was impossible, so we went
> with tricks, and more tricks and even more tricks that now pays back.
>
> The other day we had a question on ML about 4-alpha compatibility breakage,
> and from mail it was clear that the package of the referred class was
> having "internal" in it. I mean, developers should really take care of what
> they import.
>
> This is another huge plus for Takari lifecycle, it FORBIDS compilation
> against "encapsulated" internal classes....
>
> http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
>
> T
>
> On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org> wrote:
>
> > I guess this is the easy part, the tricky question remains: Do we need to
> > make sure that all Maven 3 API interfaces/classes stay 100% backwards
> > compatible until we reach 4.100/5.0/whatever?
> >
> > This wasn't handled consistently in master till now, e.g. the classes
> > generated from
> >
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> > are now immutable, i.e. lack setter methods in Maven 4.
> > My change in
> >
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> > was not backwards compatible (removed a method on an interface which may
> > have been implemented by extensions...)
> >
> > Konrad
> >
> > On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > > Unsure we want to deprecate all of Maven :)
> > >
> > > But yes, in general, 3.x "Maven API" was "all that users can grab"
> sadly,
> > > and is probably our major source of problems and reason we started
> Maven
> > 4
> > > API.
> > >
> > > IMO, I'd consider them as "whole", and just say "starting with Maven
> > > 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> > ACCESSIBLE
> > > ANYMORE FROM PLUGINS.
> > > And done.
> > >
> > > Just as an example, here is what Maven Resolver has to say about same
> > topic
> > > (part of not-yet-released, vote is in process 1.9.1 version):
> > >
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> > >
> > > HTH
> > > T
> > >
> > > On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
> > wrote:
> > >
> > > > I see now there is already
> > > >
> >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > > > but to me the javadoc is not explicit enough. It should state: Only
> > Maven
> > > > is allowed to implement/extend types with this annotation.
> > > >
> > > > Konrad
> > > >
> > > > On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > > > Hi,
> > > > > Unfortunately Maven 3 didn’t define a proper API. In effect
> > everything
> > > > somehow exposed through class loaders was considered API by
> > > > plugin/extension developers.
> > > > > For Maven 4 a completely separate API was established in package
> > > > “org.apache.maven.api”, but what about the old packages used and
> > exported
> > > > in Maven 3?
> > > > >
> > > > > For example in the context of
> > > > https://issues.apache.org/jira/browse/MNG-7588 <
> > > > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> > > > package “org.apache.maven.plugin.descriptor”.
> > > > > We already figured out that this particular package (although not
> > part
> > > > of the Maven 4 API) is used from both Maven Core as well as Maven
> > Plugin
> > > > Tools, therefore this probably needs to stay backwards compatible.
> > > > > What about others like
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > ?
> > > > <
> > > >
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > > ?>
> > > > > This interface should IMHO never been implemented outside Maven
> Core
> > but
> > > > in fact it was exposed to all plugins/extensions (via
> > > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > <
> > > >
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > > >).
> > > > >
> > > > > There are three options coming to my mind:
> > > > >
> > > > > 1. Deprecate the interfaces we don’t consider API and create new
> ones
> > > > for Maven 4 which are not exported!
> > > > > 2. Modify the existing interfaces in a backwards compatible way
> (but
> > > > somehow add a marker that they should not be implemented outside
> core)
> > > > > 3. Modify the existing interfaces in a backwards compatible way
> (but
> > > > somehow add a marker that they should not be implemented outside
> core)
> > > > >
> > > > > For all three options we somehow need to come up with a list of
> > > > classes/interfaces currently being exported through the API class
> > loader,
> > > > which should be considered private and agree on an Annotation/Javadoc
> > for
> > > > that (something like
> > > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > > <
> > > >
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > >
> > > > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> > > > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > > > >
> > > > > WDYT?
> > > > >
> > > > > Konrad
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 3 API, backwards compatibility
Posted by Tamás Cservenák <ta...@cservenak.net>.
Yes, to define rules is quite easy, but to make our users to obey them is
tricky :D
In general, I guess, we should. For this reason JapiCmp has been used in
Resolver since 1.9.0 (as noted on refd page end).
But while this was "kinda simple" to achieve in Resolver, I am really
unsure if it is doable in Maven (sans 4 API) :(
Ultimately, this was the whole reason for API:
- users "grabbed" whatever could get hold on and used
- maven progress was really hindered by this, as that meant modifying (even
internal) interfaces without breaking clients was impossible, so we went
with tricks, and more tricks and even more tricks that now pays back.
The other day we had a question on ML about 4-alpha compatibility breakage,
and from mail it was clear that the package of the referred class was
having "internal" in it. I mean, developers should really take care of what
they import.
This is another huge plus for Takari lifecycle, it FORBIDS compilation
against "encapsulated" internal classes....
http://takari.io/book/40-lifecycle.html#enforcing-dependency-usage-during-compilation
T
On Wed, Nov 16, 2022 at 10:44 AM Konrad Windszus <kw...@apache.org> wrote:
> I guess this is the easy part, the tricky question remains: Do we need to
> make sure that all Maven 3 API interfaces/classes stay 100% backwards
> compatible until we reach 4.100/5.0/whatever?
>
> This wasn't handled consistently in master till now, e.g. the classes
> generated from
> https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo
> are now immutable, i.e. lack setter methods in Maven 4.
> My change in
> https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77
> was not backwards compatible (removed a method on an interface which may
> have been implemented by extensions...)
>
> Konrad
>
> On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> > Unsure we want to deprecate all of Maven :)
> >
> > But yes, in general, 3.x "Maven API" was "all that users can grab" sadly,
> > and is probably our major source of problems and reason we started Maven
> 4
> > API.
> >
> > IMO, I'd consider them as "whole", and just say "starting with Maven
> > 4.100/5.0/whatever" the maven-core (any class out of it) is NOT
> ACCESSIBLE
> > ANYMORE FROM PLUGINS.
> > And done.
> >
> > Just as an example, here is what Maven Resolver has to say about same
> topic
> > (part of not-yet-released, vote is in process 1.9.1 version):
> >
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
> >
> > HTH
> > T
> >
> > On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org>
> wrote:
> >
> > > I see now there is already
> > >
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > > but to me the javadoc is not explicit enough. It should state: Only
> Maven
> > > is allowed to implement/extend types with this annotation.
> > >
> > > Konrad
> > >
> > > On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > > Hi,
> > > > Unfortunately Maven 3 didn’t define a proper API. In effect
> everything
> > > somehow exposed through class loaders was considered API by
> > > plugin/extension developers.
> > > > For Maven 4 a completely separate API was established in package
> > > “org.apache.maven.api”, but what about the old packages used and
> exported
> > > in Maven 3?
> > > >
> > > > For example in the context of
> > > https://issues.apache.org/jira/browse/MNG-7588 <
> > > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> > > package “org.apache.maven.plugin.descriptor”.
> > > > We already figured out that this particular package (although not
> part
> > > of the Maven 4 API) is used from both Maven Core as well as Maven
> Plugin
> > > Tools, therefore this probably needs to stay backwards compatible.
> > > > What about others like
> > >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> ?
> > > <
> > >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > > ?>
> > > > This interface should IMHO never been implemented outside Maven Core
> but
> > > in fact it was exposed to all plugins/extensions (via
> > >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > <
> > >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > > >).
> > > >
> > > > There are three options coming to my mind:
> > > >
> > > > 1. Deprecate the interfaces we don’t consider API and create new ones
> > > for Maven 4 which are not exported!
> > > > 2. Modify the existing interfaces in a backwards compatible way (but
> > > somehow add a marker that they should not be implemented outside core)
> > > > 3. Modify the existing interfaces in a backwards compatible way (but
> > > somehow add a marker that they should not be implemented outside core)
> > > >
> > > > For all three options we somehow need to come up with a list of
> > > classes/interfaces currently being exported through the API class
> loader,
> > > which should be considered private and agree on an Annotation/Javadoc
> for
> > > that (something like
> > >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > > <
> > >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >
> > > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> > > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > > >
> > > > WDYT?
> > > >
> > > > Konrad
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Konrad Windszus <kw...@apache.org>.
I guess this is the easy part, the tricky question remains: Do we need to make sure that all Maven 3 API interfaces/classes stay 100% backwards compatible until we reach 4.100/5.0/whatever?
This wasn't handled consistently in master till now, e.g. the classes generated from https://github.com/apache/maven/blob/master/maven-plugin-api/src/main/mdo/lifecycle.mdo are now immutable, i.e. lack setter methods in Maven 4.
My change in https://github.com/apache/maven/pull/827/files#diff-2324c8cead0ad922c829a8ca450764aa149d6efdfe7f841e64210f20efd148acR77 was not backwards compatible (removed a method on an interface which may have been implemented by extensions...)
Konrad
On 2022/11/16 09:35:15 Tamás Cservenák wrote:
> Unsure we want to deprecate all of Maven :)
>
> But yes, in general, 3.x "Maven API" was "all that users can grab" sadly,
> and is probably our major source of problems and reason we started Maven 4
> API.
>
> IMO, I'd consider them as "whole", and just say "starting with Maven
> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT ACCESSIBLE
> ANYMORE FROM PLUGINS.
> And done.
>
> Just as an example, here is what Maven Resolver has to say about same topic
> (part of not-yet-released, vote is in process 1.9.1 version):
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>
> HTH
> T
>
> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org> wrote:
>
> > I see now there is already
> > https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> > but to me the javadoc is not explicit enough. It should state: Only Maven
> > is allowed to implement/extend types with this annotation.
> >
> > Konrad
> >
> > On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > > Hi,
> > > Unfortunately Maven 3 didn’t define a proper API. In effect everything
> > somehow exposed through class loaders was considered API by
> > plugin/extension developers.
> > > For Maven 4 a completely separate API was established in package
> > “org.apache.maven.api”, but what about the old packages used and exported
> > in Maven 3?
> > >
> > > For example in the context of
> > https://issues.apache.org/jira/browse/MNG-7588 <
> > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> > package “org.apache.maven.plugin.descriptor”.
> > > We already figured out that this particular package (although not part
> > of the Maven 4 API) is used from both Maven Core as well as Maven Plugin
> > Tools, therefore this probably needs to stay backwards compatible.
> > > What about others like
> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?
> > <
> > https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > ?>
> > > This interface should IMHO never been implemented outside Maven Core but
> > in fact it was exposed to all plugins/extensions (via
> > https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > <
> > https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >).
> > >
> > > There are three options coming to my mind:
> > >
> > > 1. Deprecate the interfaces we don’t consider API and create new ones
> > for Maven 4 which are not exported!
> > > 2. Modify the existing interfaces in a backwards compatible way (but
> > somehow add a marker that they should not be implemented outside core)
> > > 3. Modify the existing interfaces in a backwards compatible way (but
> > somehow add a marker that they should not be implemented outside core)
> > >
> > > For all three options we somehow need to come up with a list of
> > classes/interfaces currently being exported through the API class loader,
> > which should be considered private and agree on an Annotation/Javadoc for
> > that (something like
> > https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > <
> > https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29>
> > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> > >
> > > WDYT?
> > >
> > > Konrad
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by Tamás Cservenák <ta...@cservenak.net>.
Addendum:
1, we did discuss this Resolver 1.9.1 page with @Guillaume Nodet
<gn...@apache.org> and we agreed it has to change. Resolver was always
using these Javadoc tags to mark the intent, but we should switch to
annotations (Resolver predates Java5). This implies we'd need some
"maven-really-shared-tooling" stuff, that could be reused by Maven but also
by Resolver (and probably many other things in maveniverse).
2. we could add proper tooling, that could for example break the build if
the "noimplement" interface is implemented, etc. Pretty much like Takari
lifecycle detected any form of violation (like use of
undeclared dependency) etc.
My 3 cents
T
On Wed, Nov 16, 2022 at 10:35 AM Tamás Cservenák <ta...@cservenak.net>
wrote:
> Unsure we want to deprecate all of Maven :)
>
> But yes, in general, 3.x "Maven API" was "all that users can grab" sadly,
> and is probably our major source of problems and reason we started Maven 4
> API.
>
> IMO, I'd consider them as "whole", and just say "starting with Maven
> 4.100/5.0/whatever" the maven-core (any class out of it) is NOT ACCESSIBLE
> ANYMORE FROM PLUGINS.
> And done.
>
> Just as an example, here is what Maven Resolver has to say about same
> topic (part of not-yet-released, vote is in process 1.9.1 version):
>
> https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
>
> HTH
> T
>
> On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org> wrote:
>
>> I see now there is already
>> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
>> but to me the javadoc is not explicit enough. It should state: Only Maven
>> is allowed to implement/extend types with this annotation.
>>
>> Konrad
>>
>> On 2022/11/16 09:20:11 Konrad Windszus wrote:
>> > Hi,
>> > Unfortunately Maven 3 didn’t define a proper API. In effect everything
>> somehow exposed through class loaders was considered API by
>> plugin/extension developers.
>> > For Maven 4 a completely separate API was established in package
>> “org.apache.maven.api”, but what about the old packages used and exported
>> in Maven 3?
>> >
>> > For example in the context of
>> https://issues.apache.org/jira/browse/MNG-7588 <
>> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
>> package “org.apache.maven.plugin.descriptor”.
>> > We already figured out that this particular package (although not part
>> of the Maven 4 API) is used from both Maven Core as well as Maven Plugin
>> Tools, therefore this probably needs to stay backwards compatible.
>> > What about others like
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?
>> <
>> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
>> ?>
>> > This interface should IMHO never been implemented outside Maven Core
>> but in fact it was exposed to all plugins/extensions (via
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> <
>> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
>> >).
>> >
>> > There are three options coming to my mind:
>> >
>> > 1. Deprecate the interfaces we don’t consider API and create new ones
>> for Maven 4 which are not exported!
>> > 2. Modify the existing interfaces in a backwards compatible way (but
>> somehow add a marker that they should not be implemented outside core)
>> > 3. Modify the existing interfaces in a backwards compatible way (but
>> somehow add a marker that they should not be implemented outside core)
>> >
>> > For all three options we somehow need to come up with a list of
>> classes/interfaces currently being exported through the API class loader,
>> which should be considered private and agree on an Annotation/Javadoc for
>> that (something like
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
>> <
>> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29>
>> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
>> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>> >
>> > WDYT?
>> >
>> > Konrad
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
Re: Maven 3 API, backwards compatibility
Posted by Tamás Cservenák <ta...@cservenak.net>.
Unsure we want to deprecate all of Maven :)
But yes, in general, 3.x "Maven API" was "all that users can grab" sadly,
and is probably our major source of problems and reason we started Maven 4
API.
IMO, I'd consider them as "whole", and just say "starting with Maven
4.100/5.0/whatever" the maven-core (any class out of it) is NOT ACCESSIBLE
ANYMORE FROM PLUGINS.
And done.
Just as an example, here is what Maven Resolver has to say about same topic
(part of not-yet-released, vote is in process 1.9.1 version):
https://maven.apache.org/resolver-archives/resolver-LATEST/api-compatibility.html
HTH
T
On Wed, Nov 16, 2022 at 10:26 AM Konrad Windszus <kw...@apache.org> wrote:
> I see now there is already
> https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java
> but to me the javadoc is not explicit enough. It should state: Only Maven
> is allowed to implement/extend types with this annotation.
>
> Konrad
>
> On 2022/11/16 09:20:11 Konrad Windszus wrote:
> > Hi,
> > Unfortunately Maven 3 didn’t define a proper API. In effect everything
> somehow exposed through class loaders was considered API by
> plugin/extension developers.
> > For Maven 4 a completely separate API was established in package
> “org.apache.maven.api”, but what about the old packages used and exported
> in Maven 3?
> >
> > For example in the context of
> https://issues.apache.org/jira/browse/MNG-7588 <
> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> package “org.apache.maven.plugin.descriptor”.
> > We already figured out that this particular package (although not part
> of the Maven 4 API) is used from both Maven Core as well as Maven Plugin
> Tools, therefore this probably needs to stay backwards compatible.
> > What about others like
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?
> <
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> ?>
> > This interface should IMHO never been implemented outside Maven Core but
> in fact it was exposed to all plugins/extensions (via
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> <
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >).
> >
> > There are three options coming to my mind:
> >
> > 1. Deprecate the interfaces we don’t consider API and create new ones
> for Maven 4 which are not exported!
> > 2. Modify the existing interfaces in a backwards compatible way (but
> somehow add a marker that they should not be implemented outside core)
> > 3. Modify the existing interfaces in a backwards compatible way (but
> somehow add a marker that they should not be implemented outside core)
> >
> > For all three options we somehow need to come up with a list of
> classes/interfaces currently being exported through the API class loader,
> which should be considered private and agree on an Annotation/Javadoc for
> that (something like
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> <
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29>
> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >
> > WDYT?
> >
> > Konrad
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 3 API, backwards compatibility
Posted by Konrad Windszus <kw...@apache.org>.
I see now there is already https://github.com/apache/maven/blob/master/api/maven-api-meta/src/main/java/org/apache/maven/api/annotations/Provider.java but to me the javadoc is not explicit enough. It should state: Only Maven is allowed to implement/extend types with this annotation.
Konrad
On 2022/11/16 09:20:11 Konrad Windszus wrote:
> Hi,
> Unfortunately Maven 3 didn’t define a proper API. In effect everything somehow exposed through class loaders was considered API by plugin/extension developers.
> For Maven 4 a completely separate API was established in package “org.apache.maven.api”, but what about the old packages used and exported in Maven 3?
>
> For example in the context of https://issues.apache.org/jira/browse/MNG-7588 <https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the package “org.apache.maven.plugin.descriptor”.
> We already figured out that this particular package (although not part of the Maven 4 API) is used from both Maven Core as well as Maven Plugin Tools, therefore this probably needs to stay backwards compatible.
> What about others like https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java? <https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?>
> This interface should IMHO never been implemented outside Maven Core but in fact it was exposed to all plugins/extensions (via https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40 <https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40>).
>
> There are three options coming to my mind:
>
> 1. Deprecate the interfaces we don’t consider API and create new ones for Maven 4 which are not exported!
> 2. Modify the existing interfaces in a backwards compatible way (but somehow add a marker that they should not be implemented outside core)
> 3. Modify the existing interfaces in a backwards compatible way (but somehow add a marker that they should not be implemented outside core)
>
> For all three options we somehow need to come up with a list of classes/interfaces currently being exported through the API class loader, which should be considered private and agree on an Annotation/Javadoc for that (something like https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29 <https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>
> WDYT?
>
> Konrad
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 3 API, backwards compatibility
Posted by James Gao <ga...@gmail.com>.
Hi, after following the discussion, i still have no idea how to maintain a
core-extension that needs to run on both maven 3 and 4. Could anyone plz
give some suggestions?
On Fri, Nov 18, 2022 at 4:20 PM Guillaume Nodet <gn...@apache.org> wrote:
> Le mer. 16 nov. 2022, 10:20, Konrad Windszus <kw...@apache.org> a écrit :
>
> > Hi,
> > Unfortunately Maven 3 didn’t define a proper API. In effect everything
> > somehow exposed through class loaders was considered API by
> > plugin/extension developers.
> > For Maven 4 a completely separate API was established in package
> > “org.apache.maven.api”, but what about the old packages used and exported
> > in Maven 3?
> >
> > For example in the context of
> > https://issues.apache.org/jira/browse/MNG-7588 <
> > https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> > package “org.apache.maven.plugin.descriptor”.
> > We already figured out that this particular package (although not part of
> > the Maven 4 API) is used from both Maven Core as well as Maven Plugin
> > Tools, therefore this probably needs to stay backwards compatible.
> > What about others like
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> ?
> > <
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> > ?>
> > This interface should IMHO never been implemented outside Maven Core but
> > in fact it was exposed to all plugins/extensions (via
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > <
> >
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> > >).
> >
> > There are three options coming to my mind:
> >
> > 1. Deprecate the interfaces we don’t consider API and create new ones for
> > Maven 4 which are not exported!
> >
>
> I think that's the way to go.
> We'd also need to deprecate a bunch of jars and in maven-shared like
> m-artifact-transfer, maven-dependency-tree etc...
> One of the goal is also to completely hide the resolver.
>
> 2. Modify the existing interfaces in a backwards compatible way (but
> > somehow add a marker that they should not be implemented outside core)
> >
>
>
>
> 3. Modify the existing interfaces in a backwards compatible way (but
> > somehow add a marker that they should not be implemented outside core)
> >
> > For all three options we somehow need to come up with a list of
> > classes/interfaces currently being exported through the API class loader,
> > which should be considered private and agree on an Annotation/Javadoc for
> > that (something like
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> > <
> >
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> >
> > or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> > https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
> >
> > WDYT?
> >
> > Konrad
> >
> >
>
Re: Maven 3 API, backwards compatibility
Posted by Guillaume Nodet <gn...@apache.org>.
Le mer. 16 nov. 2022, 10:20, Konrad Windszus <kw...@apache.org> a écrit :
> Hi,
> Unfortunately Maven 3 didn’t define a proper API. In effect everything
> somehow exposed through class loaders was considered API by
> plugin/extension developers.
> For Maven 4 a completely separate API was established in package
> “org.apache.maven.api”, but what about the old packages used and exported
> in Maven 3?
>
> For example in the context of
> https://issues.apache.org/jira/browse/MNG-7588 <
> https://issues.apache.org/jira/browse/MNG-7588> I want to evolve the
> package “org.apache.maven.plugin.descriptor”.
> We already figured out that this particular package (although not part of
> the Maven 4 API) is used from both Maven Core as well as Maven Plugin
> Tools, therefore this probably needs to stay backwards compatible.
> What about others like
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java?
> <
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/plugin/MavenPluginManager.java
> ?>
> This interface should IMHO never been implemented outside Maven Core but
> in fact it was exposed to all plugins/extensions (via
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> <
> https://github.com/apache/maven/blob/a6b1ebb1cd40ca4b288fdeb30c6d2460323aa25b/maven-core/src/main/resources/META-INF/maven/extension.xml#L40
> >).
>
> There are three options coming to my mind:
>
> 1. Deprecate the interfaces we don’t consider API and create new ones for
> Maven 4 which are not exported!
>
I think that's the way to go.
We'd also need to deprecate a bunch of jars and in maven-shared like
m-artifact-transfer, maven-dependency-tree etc...
One of the goal is also to completely hide the resolver.
2. Modify the existing interfaces in a backwards compatible way (but
> somehow add a marker that they should not be implemented outside core)
>
3. Modify the existing interfaces in a backwards compatible way (but
> somehow add a marker that they should not be implemented outside core)
>
> For all three options we somehow need to come up with a list of
> classes/interfaces currently being exported through the API class loader,
> which should be considered private and agree on an Annotation/Javadoc for
> that (something like
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29
> <
> https://github.com/mulesoft/api-annotations/blob/40b258afeff6560241dee5001ed00f1deb392e47/src/main/java/org/mule/api/annotation/NoImplement.java#L29>
> or https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution <
> https://wiki.eclipse.org/API_Javadoc_tags#The_New_Solution>
>
> WDYT?
>
> Konrad
>
>