> 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 <m...@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 <m...@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 <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
---------------------------------------------------------------------
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
