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
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 <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
