Re: Maven 3 API, backwards compatibility

Christoph Läubrich Thu, 17 Nov 2022 10:23:25 -0800

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 Mojomight 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 restfor you ... so very similar to what we have today, but with much moreflexibility (not shown here as not required for most cases).

And for the "breakage", as outlined in the linked issue [1], Tychoalready use a Maven <-> OSGi bridge, so actually one can even combineboth "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 <m...@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 <m...@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 <k...@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

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 <k...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3 API, backwards compatibility

Reply via email to