> 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 <m...@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 <gno...@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 <gno...@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 <
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
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
---------------------------------------------------------------------
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
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
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
