You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2021/02/25 08:59:21 UTC
Future of maven scripting plugin, java?
Hi all,
Wonder if maven scripting plugin has some future plans or not.
Very concretely I'm interested in being able to use java as scripting files
(something along src/build/scripting in terms of structure in final
project).
Since we are in maven we have javac so it is not hard to implement a jsr223
(with tool provider or not is a detail) but more complicated thing is the
classpath, it needs the plugin to be able to create a classloader adjusted
for that kind of execution (potentially compiling the whole scripting
folder). In terms of impacts it means enabling to configure the script
engine, ie pass args from the mojo to the getScriptEngine method (typically
kind of the same as exec maven plugin, ie scope/classpath).
So changes would be:
1. implement a java script engine
2. make the script engine instantiation more configurable
Do you think it is worth it or exec maven plugin is still preferred?
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>
Re: Future of maven scripting plugin, java?
Posted by Christian Stein <so...@gmail.com>.
On Fri, Feb 26, 2021 at 12:42 PM Robert Scholte <rf...@apache.org>
wrote:
> I remember the same discussion with Christian Stein.
>
Yeah, me too. Came up with a JSR223 wrapper POC implementation around that
time:
https://github.com/sormuras/java-compiler-script-engine
Maybe it's of help here - if not, then not. (-:
Re: Future of maven scripting plugin, java?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 26 févr. 2021 à 12:42, Robert Scholte <rf...@apache.org> a
écrit :
> I remember the same discussion with Christian Stein.
> The problem is that a Java + main(String[]) is not equivalent to JSR223,
> because it is not context aware.
>
Yes but nothing prevents you to support MyClass(Bindings b) instantiation,
works well (not in the PoC though) but since you instantiate after the
compilation you can integrate with JSR223 properly.
> I don't want to extend the eval-goal with toolchain, etc to make it
> possible to execute Java.
> If we would create a new goal, it would likely be the same as exec:java,
> so there's no benefit there.
>
No, as mentionned, one of the big target is to have build classpath vs
module classpath without having to create fake modules which are harder to
maintain (since decoralated) and slower to build (inheriting from way more
than just the compilation mojo).
>
> Using the JShellToolProvider[1] comes close, but again it is not possible
> to use the JSR223 context.
> Having a jshell goal might be an option, but that means we need to adjust
> the purpose of the plugin a bit.
>
jshell is very specific and unrelated to java over jsr223 usage, it also
has several blockers by its lack of java features support so I prefer exec
plugin over a jshell plugin as of today.
Indeed an option would be to add a scope=build but it has the pitfall to
not be maven 3 friendly nor IDE friendly so the scripting was tempting for
that.
>
> Robert
> [1]
> https://github.com/openjdk/jdk/blob/master/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java
>
> On 26-2-2021 11:59:13, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Le ven. 26 févr. 2021 à 11:47, Hervé BOUTEMY a
> écrit :
>
> > I don't fully get the logic
> >
> > but on dependencies injection to the running script, I was just talking
> > about:
> >
> > org.apache.maven.plugins
> > maven-scripting-plugin
> > @project.version@
> >
> >
> >
> > org.codehaus.groovy
> > groovy-jsr223
> > 3.0.7
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> Ok, this does not work perfectly since you inherit from a lot using plugin
> dependencies so it is always good to be able to isolate a stack, in
> particular at compilation time where you will not want to put the plugin
> classpath to compile your "script".
>
>
> >
> > regards,
> >
> > Hervé
> >
> > Le vendredi 26 février 2021, 09:42:22 CET Romain Manni-Bucau a écrit :
> > > here is a draft
> > >
> >
> https://github.com/apache/maven-scripting-plugin/tree/rmannibucau/java-scrip
> > > ting-draft, still require some more love for dependency management (for
> > now
> > > it will use project dependencies) but shows the overall idea I guess
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github <
> > https://github.com/rmannibucau>
> > > | LinkedIn | Book
> > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le ven. 26 févr. 2021 à 09:07, Romain Manni-Bucau
> > a
> > >
> > > écrit :
> > > > Hi Hervé,
> > > >
> > > > Do you mean project binding and from there use plexus container to
> > lookup
> > > > anything?
> > > > This can work but then the question is what is the value of this
> > plugin?
> > > > To detail that let me review the usage you can get today:
> > > >
> > > > 1. groovy -> you will likely use gplus plugin which is more centered
> on
> > > > groovy and way more powerful
> > > > 2. js -> likely nashorn-maven-plugin for trivial script which has
> more
> > > > bindings and a better script enclosing but if you really do js you
> can
> > end
> > > > up using frontend-maven-plugin which enables a real node scripting
> > > > 3. java -> hack with maven compiler+exec-maven-plugin but has the
> > > > dependency pitfall
> > > > 4. python -> probably acceptable but several jython maven plugins
> have
> > > > more integrations (not using jsr223)
> > > > 5. ruby -> jruby-maven-plugin, way more features and configurations
> > needed
> > > > for ruby (like gems)
> > > >
> > > > Not sure other languages are often used through JSR223 but overall
> > there
> > > > is almost no real cases justifying current plugin usage as of today
> > > > because
> > > > you will quickly hit limitations already solved until your case is
> very
> > > > simple and you just replace ant maven plugin IMHO.
> > > >
> > > > Indeed, you are fully right, from the project instance you can hack
> all
> > > > you want but then you end up managing complex scripts so it is
> > generally
> > > > pointless and preferrable to be able:
> > > > 1. to configure the engine
> > > > 2. configure the bindings from the pom.xml (or have several
> virtual/or
> > not
> > > > ones out of the box)
> > > > 3. handling the execution environment (which is sometimes linked to 1
> > and
> > > > sometimes not as for java)
> > > >
> > > > Java case also needs a bit more like using toolchain and plexus-java
> > for
> > > > example - until you do it more simply using javac directly but
> > wouldn't be
> > > > consistent for maven itself.
> > > >
> > > > Now I fully hear the "there is enough SPI to do it outside" and I can
> > > > agree with it but then my question would be "what is the goal of this
> > > > plugin" in current ecosystem?
> > > > Java integration is an opportunity to give to maven some scripting
> > > > capabilities keys in current way to develop for doc and integration
> > with
> > > > external system but we have alternatives, this is why I sent this
> mail
> > > > before doing all the code - BTW i can push a quick PoC if you want to
> > see
> > > > more what it can look like, I was not sure it was the way to solve
> that
> > > > extensibility need *from the project* itself.
> > > >
> > > > Hope it makes sense.
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau | Blog
> > > > | Old Blog
> > > > | Github
> > > > | LinkedIn
> > > > | Book
> > > > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performan
> > > > ce>
> > > >
> > > >
> > > > Le ven. 26 févr. 2021 à 08:40, Hervé BOUTEMY a
> > > >
> > > > écrit :
> > > >> I don't get every detail, but have one question on dependencies:
> isn't
> > > >> dependency injection to the maven-scripting-plugin sufficient [1]
> > > >>
> > > >> do you need something more advanced, managed by the
> > > >> maven-scripting-plugin
> > > >> itself?
> > > >>
> > > >> Regards,
> > > >>
> > > >> Hervé
> > > >>
> > > >> [1]
> > > >>
> > https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> > > >> configure-the-script-engine.html
> > > >> <
> > https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> > > >> configure-the-script-engine.html>>>
> > > >> Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
> > > >> > Le jeu. 25 févr. 2021 à 15:28, Markus KARG
> > a
> > > >> >
> > > >> > écrit :
> > > >> > > Romain,
> > > >> > >
> > > >> > > just to understand your target: In the end what you want is that
> > the
> > > >>
> > > >> Java
> > > >>
> > > >> > > scripting plugin will execute Java source code, just like jshell
> > > >> > > does?
> > > >> > > That
> > > >> > > sounds interesting to me.
> > > >> >
> > > >> > This is more a side effect, the target is to be able to be able to
> > > >>
> > > >> replace
> > > >>
> > > >> > src/main/java/xxxx/build/*.java + exec-maven-plugin setups which
> has
> > > >> > the
> > > >> > drawback to require dependencies in the actual module (even in
> scope
> > > >> > provided).
> > > >> > The scripting plugin has the opportunity to normalize that through
> > the
> > > >> > maven-java-scripting-engine which will take this through engine
> > > >> > configuration.
> > > >> > To illustrate the usage: it generates documentation, typed clients
> > > >>
> > > >> (http),
> > > >>
> > > >> > jsonschema, openapi.json, docker images with CDS and much more and
> > in a
> > > >> > customized fashion.
> > > >> > Big gain is to not have to leak all dependencies in the build and
> > keep
> > > >> > build part of the build isolated (a profile can enable to code in
> > the
> > > >>
> > > >> IDE
> > > >>
> > > >> > but when running mvn xxx it is gone/deactivated).
> > > >> >
> > > >> > Side notes:
> > > >> > 1. creating a build module is not an option since it is really
> about
> > > >>
> > > >> having
> > > >>
> > > >> > the build code in the related module and not a "put it all" module
> > > >>
> > > >> which is
> > > >>
> > > >> > very hard to maintain.
> > > >> > 2. creating a mojo for these needs is inefficient in terms of
> > > >>
> > > >> maintenance
> > > >>
> > > >> > and customization level (I come from there) and ultra verbose in
> the
> > > >> > pom
> > > >> > compared to this scripting option
> > > >> >
> > > >> >
> > > >> > Hope it clarifies my goal
> > > >> >
> > > >> > > -Markus
> > > >> > >
> > > >> > >
> > > >> > > -----Ursprüngliche Nachricht-----
> > > >> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > >> > > Gesendet: Donnerstag, 25. Februar 2021 09:59
> > > >> > > An: Maven Developers List
> > > >> > > Betreff: Future of maven scripting plugin, java?
> > > >> > >
> > > >> > > Hi all,
> > > >> > >
> > > >> > > Wonder if maven scripting plugin has some future plans or not.
> > > >> > > Very concretely I'm interested in being able to use java as
> > scripting
> > > >> > > files
> > > >> > > (something along src/build/scripting in terms of structure in
> > final
> > > >> > > project).
> > > >> > > Since we are in maven we have javac so it is not hard to
> > implement a
> > > >> > > jsr223
> > > >> > > (with tool provider or not is a detail) but more complicated
> > thing is
> > > >>
> > > >> the
> > > >>
> > > >> > > classpath, it needs the plugin to be able to create a
> classloader
> > > >>
> > > >> adjusted
> > > >>
> > > >> > > for that kind of execution (potentially compiling the whole
> > scripting
> > > >> > > folder). In terms of impacts it means enabling to configure the
> > > >> > > script
> > > >> > > engine, ie pass args from the mojo to the getScriptEngine method
> > > >> > > (typically
> > > >> > > kind of the same as exec maven plugin, ie scope/classpath).
> > > >> > >
> > > >> > > So changes would be:
> > > >> > >
> > > >> > > 1. implement a java script engine
> > > >> > > 2. make the script engine instantiation more configurable
> > > >> > >
> > > >> > > Do you think it is worth it or exec maven plugin is still
> > preferred?
> > > >> > >
> > > >> > > Romain Manni-Bucau
> > > >> > > @rmannibucau | Blog
> > > >> > > | Old Blog
> > > >> > > | Github <
> > > >> > > https://github.com/rmannibucau> |
> > > >> > > LinkedIn | Book
> > > >> > > <
> > > >>
> > > >>
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performan
> > > >> c
> > > >>
> > > >> > > e
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > >
> > ---------------------------------------------------------------------
> > > >> > > 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: Future of maven scripting plugin, java?
Posted by Robert Scholte <rf...@apache.org>.
I remember the same discussion with Christian Stein.
The problem is that a Java + main(String[]) is not equivalent to JSR223, because it is not context aware.
I don't want to extend the eval-goal with toolchain, etc to make it possible to execute Java.
If we would create a new goal, it would likely be the same as exec:java, so there's no benefit there.
Using the JShellToolProvider[1] comes close, but again it is not possible to use the JSR223 context.
Having a jshell goal might be an option, but that means we need to adjust the purpose of the plugin a bit.
Robert
[1] https://github.com/openjdk/jdk/blob/master/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolProvider.java
On 26-2-2021 11:59:13, Romain Manni-Bucau <rm...@gmail.com> wrote:
Le ven. 26 févr. 2021 à 11:47, Hervé BOUTEMY a
écrit :
> I don't fully get the logic
>
> but on dependencies injection to the running script, I was just talking
> about:
>
> org.apache.maven.plugins
> maven-scripting-plugin
> @project.version@
>
>
>
> org.codehaus.groovy
> groovy-jsr223
> 3.0.7
>
>
>
>
>
>
>
>
>
>
Ok, this does not work perfectly since you inherit from a lot using plugin
dependencies so it is always good to be able to isolate a stack, in
particular at compilation time where you will not want to put the plugin
classpath to compile your "script".
>
> regards,
>
> Hervé
>
> Le vendredi 26 février 2021, 09:42:22 CET Romain Manni-Bucau a écrit :
> > here is a draft
> >
> https://github.com/apache/maven-scripting-plugin/tree/rmannibucau/java-scrip
> > ting-draft, still require some more love for dependency management (for
> now
> > it will use project dependencies) but shows the overall idea I guess
> >
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > | Old Blog
> > | Github <
> https://github.com/rmannibucau>
> > | LinkedIn | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le ven. 26 févr. 2021 à 09:07, Romain Manni-Bucau
> a
> >
> > écrit :
> > > Hi Hervé,
> > >
> > > Do you mean project binding and from there use plexus container to
> lookup
> > > anything?
> > > This can work but then the question is what is the value of this
> plugin?
> > > To detail that let me review the usage you can get today:
> > >
> > > 1. groovy -> you will likely use gplus plugin which is more centered on
> > > groovy and way more powerful
> > > 2. js -> likely nashorn-maven-plugin for trivial script which has more
> > > bindings and a better script enclosing but if you really do js you can
> end
> > > up using frontend-maven-plugin which enables a real node scripting
> > > 3. java -> hack with maven compiler+exec-maven-plugin but has the
> > > dependency pitfall
> > > 4. python -> probably acceptable but several jython maven plugins have
> > > more integrations (not using jsr223)
> > > 5. ruby -> jruby-maven-plugin, way more features and configurations
> needed
> > > for ruby (like gems)
> > >
> > > Not sure other languages are often used through JSR223 but overall
> there
> > > is almost no real cases justifying current plugin usage as of today
> > > because
> > > you will quickly hit limitations already solved until your case is very
> > > simple and you just replace ant maven plugin IMHO.
> > >
> > > Indeed, you are fully right, from the project instance you can hack all
> > > you want but then you end up managing complex scripts so it is
> generally
> > > pointless and preferrable to be able:
> > > 1. to configure the engine
> > > 2. configure the bindings from the pom.xml (or have several virtual/or
> not
> > > ones out of the box)
> > > 3. handling the execution environment (which is sometimes linked to 1
> and
> > > sometimes not as for java)
> > >
> > > Java case also needs a bit more like using toolchain and plexus-java
> for
> > > example - until you do it more simply using javac directly but
> wouldn't be
> > > consistent for maven itself.
> > >
> > > Now I fully hear the "there is enough SPI to do it outside" and I can
> > > agree with it but then my question would be "what is the goal of this
> > > plugin" in current ecosystem?
> > > Java integration is an opportunity to give to maven some scripting
> > > capabilities keys in current way to develop for doc and integration
> with
> > > external system but we have alternatives, this is why I sent this mail
> > > before doing all the code - BTW i can push a quick PoC if you want to
> see
> > > more what it can look like, I was not sure it was the way to solve that
> > > extensibility need *from the project* itself.
> > >
> > > Hope it makes sense.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau | Blog
> > > | Old Blog
> > > | Github
> > > | LinkedIn
> > > | Book
> > > <
> https://www.packtpub.com/application-development/java-ee-8-high-performan
> > > ce>
> > >
> > >
> > > Le ven. 26 févr. 2021 à 08:40, Hervé BOUTEMY a
> > >
> > > écrit :
> > >> I don't get every detail, but have one question on dependencies: isn't
> > >> dependency injection to the maven-scripting-plugin sufficient [1]
> > >>
> > >> do you need something more advanced, managed by the
> > >> maven-scripting-plugin
> > >> itself?
> > >>
> > >> Regards,
> > >>
> > >> Hervé
> > >>
> > >> [1]
> > >>
> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> > >> configure-the-script-engine.html
> > >> <
> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> > >> configure-the-script-engine.html>>>
> > >> Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
> > >> > Le jeu. 25 févr. 2021 à 15:28, Markus KARG
> a
> > >> >
> > >> > écrit :
> > >> > > Romain,
> > >> > >
> > >> > > just to understand your target: In the end what you want is that
> the
> > >>
> > >> Java
> > >>
> > >> > > scripting plugin will execute Java source code, just like jshell
> > >> > > does?
> > >> > > That
> > >> > > sounds interesting to me.
> > >> >
> > >> > This is more a side effect, the target is to be able to be able to
> > >>
> > >> replace
> > >>
> > >> > src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has
> > >> > the
> > >> > drawback to require dependencies in the actual module (even in scope
> > >> > provided).
> > >> > The scripting plugin has the opportunity to normalize that through
> the
> > >> > maven-java-scripting-engine which will take this through engine
> > >> > configuration.
> > >> > To illustrate the usage: it generates documentation, typed clients
> > >>
> > >> (http),
> > >>
> > >> > jsonschema, openapi.json, docker images with CDS and much more and
> in a
> > >> > customized fashion.
> > >> > Big gain is to not have to leak all dependencies in the build and
> keep
> > >> > build part of the build isolated (a profile can enable to code in
> the
> > >>
> > >> IDE
> > >>
> > >> > but when running mvn xxx it is gone/deactivated).
> > >> >
> > >> > Side notes:
> > >> > 1. creating a build module is not an option since it is really about
> > >>
> > >> having
> > >>
> > >> > the build code in the related module and not a "put it all" module
> > >>
> > >> which is
> > >>
> > >> > very hard to maintain.
> > >> > 2. creating a mojo for these needs is inefficient in terms of
> > >>
> > >> maintenance
> > >>
> > >> > and customization level (I come from there) and ultra verbose in the
> > >> > pom
> > >> > compared to this scripting option
> > >> >
> > >> >
> > >> > Hope it clarifies my goal
> > >> >
> > >> > > -Markus
> > >> > >
> > >> > >
> > >> > > -----Ursprüngliche Nachricht-----
> > >> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > >> > > Gesendet: Donnerstag, 25. Februar 2021 09:59
> > >> > > An: Maven Developers List
> > >> > > Betreff: Future of maven scripting plugin, java?
> > >> > >
> > >> > > Hi all,
> > >> > >
> > >> > > Wonder if maven scripting plugin has some future plans or not.
> > >> > > Very concretely I'm interested in being able to use java as
> scripting
> > >> > > files
> > >> > > (something along src/build/scripting in terms of structure in
> final
> > >> > > project).
> > >> > > Since we are in maven we have javac so it is not hard to
> implement a
> > >> > > jsr223
> > >> > > (with tool provider or not is a detail) but more complicated
> thing is
> > >>
> > >> the
> > >>
> > >> > > classpath, it needs the plugin to be able to create a classloader
> > >>
> > >> adjusted
> > >>
> > >> > > for that kind of execution (potentially compiling the whole
> scripting
> > >> > > folder). In terms of impacts it means enabling to configure the
> > >> > > script
> > >> > > engine, ie pass args from the mojo to the getScriptEngine method
> > >> > > (typically
> > >> > > kind of the same as exec maven plugin, ie scope/classpath).
> > >> > >
> > >> > > So changes would be:
> > >> > >
> > >> > > 1. implement a java script engine
> > >> > > 2. make the script engine instantiation more configurable
> > >> > >
> > >> > > Do you think it is worth it or exec maven plugin is still
> preferred?
> > >> > >
> > >> > > Romain Manni-Bucau
> > >> > > @rmannibucau | Blog
> > >> > > | Old Blog
> > >> > > | Github <
> > >> > > https://github.com/rmannibucau> |
> > >> > > LinkedIn | Book
> > >> > > <
> > >>
> > >>
> https://www.packtpub.com/application-development/java-ee-8-high-performan
> > >> c
> > >>
> > >> > > e
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > 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: Future of maven scripting plugin, java?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 26 févr. 2021 à 11:47, Hervé BOUTEMY <he...@free.fr> a
écrit :
> I don't fully get the logic
>
> but on dependencies injection to the running script, I was just talking
> about:
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-scripting-plugin</artifactId>
> <version>@project.version@</version>
> <dependencies>
> <!-- ScriptEngines -->
> <dependency>
> <groupId>org.codehaus.groovy</groupId>
> <artifactId>groovy-jsr223</artifactId>
> <version>3.0.7</version> <!-- look for latest -->
> </dependency>
> <!-- and any other dependency you'd like to be available -->
> <dependency>
> <groupId></groupId>
> <artifactId></artifactId>
> <version></version>
> </dependency>
> </dependencies>
> </plugin>
>
Ok, this does not work perfectly since you inherit from a lot using plugin
dependencies so it is always good to be able to isolate a stack, in
particular at compilation time where you will not want to put the plugin
classpath to compile your "script".
>
> regards,
>
> Hervé
>
> Le vendredi 26 février 2021, 09:42:22 CET Romain Manni-Bucau a écrit :
> > here is a draft
> >
> https://github.com/apache/maven-scripting-plugin/tree/rmannibucau/java-scrip
> > ting-draft, still require some more love for dependency management (for
> now
> > it will use project dependencies) but shows the overall idea I guess
> >
> > 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. 26 févr. 2021 à 09:07, Romain Manni-Bucau <rm...@gmail.com>
> a
> >
> > écrit :
> > > Hi Hervé,
> > >
> > > Do you mean project binding and from there use plexus container to
> lookup
> > > anything?
> > > This can work but then the question is what is the value of this
> plugin?
> > > To detail that let me review the usage you can get today:
> > >
> > > 1. groovy -> you will likely use gplus plugin which is more centered on
> > > groovy and way more powerful
> > > 2. js -> likely nashorn-maven-plugin for trivial script which has more
> > > bindings and a better script enclosing but if you really do js you can
> end
> > > up using frontend-maven-plugin which enables a real node scripting
> > > 3. java -> hack with maven compiler+exec-maven-plugin but has the
> > > dependency pitfall
> > > 4. python -> probably acceptable but several jython maven plugins have
> > > more integrations (not using jsr223)
> > > 5. ruby -> jruby-maven-plugin, way more features and configurations
> needed
> > > for ruby (like gems)
> > >
> > > Not sure other languages are often used through JSR223 but overall
> there
> > > is almost no real cases justifying current plugin usage as of today
> > > because
> > > you will quickly hit limitations already solved until your case is very
> > > simple and you just replace ant maven plugin IMHO.
> > >
> > > Indeed, you are fully right, from the project instance you can hack all
> > > you want but then you end up managing complex scripts so it is
> generally
> > > pointless and preferrable to be able:
> > > 1. to configure the engine
> > > 2. configure the bindings from the pom.xml (or have several virtual/or
> not
> > > ones out of the box)
> > > 3. handling the execution environment (which is sometimes linked to 1
> and
> > > sometimes not as for java)
> > >
> > > Java case also needs a bit more like using toolchain and plexus-java
> for
> > > example - until you do it more simply using javac directly but
> wouldn't be
> > > consistent for maven itself.
> > >
> > > Now I fully hear the "there is enough SPI to do it outside" and I can
> > > agree with it but then my question would be "what is the goal of this
> > > plugin" in current ecosystem?
> > > Java integration is an opportunity to give to maven some scripting
> > > capabilities keys in current way to develop for doc and integration
> with
> > > external system but we have alternatives, this is why I sent this mail
> > > before doing all the code - BTW i can push a quick PoC if you want to
> see
> > > more what it can look like, I was not sure it was the way to solve that
> > > extensibility need *from the project* itself.
> > >
> > > Hope it makes sense.
> > >
> > > 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-performan
> > > ce>
> > >
> > >
> > > Le ven. 26 févr. 2021 à 08:40, Hervé BOUTEMY <he...@free.fr> a
> > >
> > > écrit :
> > >> I don't get every detail, but have one question on dependencies: isn't
> > >> dependency injection to the maven-scripting-plugin sufficient [1]
> > >>
> > >> do you need something more advanced, managed by the
> > >> maven-scripting-plugin
> > >> itself?
> > >>
> > >> Regards,
> > >>
> > >> Hervé
> > >>
> > >> [1]
> > >>
> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> > >> configure-the-script-engine.html
> > >> <
> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> > >> configure-the-script-engine.html>>>
> > >> Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
> > >> > Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu>
> a
> > >> >
> > >> > écrit :
> > >> > > Romain,
> > >> > >
> > >> > > just to understand your target: In the end what you want is that
> the
> > >>
> > >> Java
> > >>
> > >> > > scripting plugin will execute Java source code, just like jshell
> > >> > > does?
> > >> > > That
> > >> > > sounds interesting to me.
> > >> >
> > >> > This is more a side effect, the target is to be able to be able to
> > >>
> > >> replace
> > >>
> > >> > src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has
> > >> > the
> > >> > drawback to require dependencies in the actual module (even in scope
> > >> > provided).
> > >> > The scripting plugin has the opportunity to normalize that through
> the
> > >> > maven-java-scripting-engine which will take this through engine
> > >> > configuration.
> > >> > To illustrate the usage: it generates documentation, typed clients
> > >>
> > >> (http),
> > >>
> > >> > jsonschema, openapi.json, docker images with CDS and much more and
> in a
> > >> > customized fashion.
> > >> > Big gain is to not have to leak all dependencies in the build and
> keep
> > >> > build part of the build isolated (a profile can enable to code in
> the
> > >>
> > >> IDE
> > >>
> > >> > but when running mvn xxx it is gone/deactivated).
> > >> >
> > >> > Side notes:
> > >> > 1. creating a build module is not an option since it is really about
> > >>
> > >> having
> > >>
> > >> > the build code in the related module and not a "put it all" module
> > >>
> > >> which is
> > >>
> > >> > very hard to maintain.
> > >> > 2. creating a mojo for these needs is inefficient in terms of
> > >>
> > >> maintenance
> > >>
> > >> > and customization level (I come from there) and ultra verbose in the
> > >> > pom
> > >> > compared to this scripting option
> > >> >
> > >> >
> > >> > Hope it clarifies my goal
> > >> >
> > >> > > -Markus
> > >> > >
> > >> > >
> > >> > > -----Ursprüngliche Nachricht-----
> > >> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > >> > > Gesendet: Donnerstag, 25. Februar 2021 09:59
> > >> > > An: Maven Developers List
> > >> > > Betreff: Future of maven scripting plugin, java?
> > >> > >
> > >> > > Hi all,
> > >> > >
> > >> > > Wonder if maven scripting plugin has some future plans or not.
> > >> > > Very concretely I'm interested in being able to use java as
> scripting
> > >> > > files
> > >> > > (something along src/build/scripting in terms of structure in
> final
> > >> > > project).
> > >> > > Since we are in maven we have javac so it is not hard to
> implement a
> > >> > > jsr223
> > >> > > (with tool provider or not is a detail) but more complicated
> thing is
> > >>
> > >> the
> > >>
> > >> > > classpath, it needs the plugin to be able to create a classloader
> > >>
> > >> adjusted
> > >>
> > >> > > for that kind of execution (potentially compiling the whole
> scripting
> > >> > > folder). In terms of impacts it means enabling to configure the
> > >> > > script
> > >> > > engine, ie pass args from the mojo to the getScriptEngine method
> > >> > > (typically
> > >> > > kind of the same as exec maven plugin, ie scope/classpath).
> > >> > >
> > >> > > So changes would be:
> > >> > >
> > >> > > 1. implement a java script engine
> > >> > > 2. make the script engine instantiation more configurable
> > >> > >
> > >> > > Do you think it is worth it or exec maven plugin is still
> preferred?
> > >> > >
> > >> > > 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-performan
> > >> c
> > >>
> > >> > > e
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> ---------------------------------------------------------------------
> > >> > > 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: Future of maven scripting plugin, java?
Posted by Hervé BOUTEMY <he...@free.fr>.
I don't fully get the logic
but on dependencies injection to the running script, I was just talking about:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-scripting-plugin</artifactId>
<version>@project.version@</version>
<dependencies>
<!-- ScriptEngines -->
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-jsr223</artifactId>
<version>3.0.7</version> <!-- look for latest -->
</dependency>
<!-- and any other dependency you'd like to be available -->
<dependency>
<groupId></groupId>
<artifactId></artifactId>
<version></version>
</dependency>
</dependencies>
</plugin>
regards,
Hervé
Le vendredi 26 février 2021, 09:42:22 CET Romain Manni-Bucau a écrit :
> here is a draft
> https://github.com/apache/maven-scripting-plugin/tree/rmannibucau/java-scrip
> ting-draft, still require some more love for dependency management (for now
> it will use project dependencies) but shows the overall idea I guess
>
> 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. 26 févr. 2021 à 09:07, Romain Manni-Bucau <rm...@gmail.com> a
>
> écrit :
> > Hi Hervé,
> >
> > Do you mean project binding and from there use plexus container to lookup
> > anything?
> > This can work but then the question is what is the value of this plugin?
> > To detail that let me review the usage you can get today:
> >
> > 1. groovy -> you will likely use gplus plugin which is more centered on
> > groovy and way more powerful
> > 2. js -> likely nashorn-maven-plugin for trivial script which has more
> > bindings and a better script enclosing but if you really do js you can end
> > up using frontend-maven-plugin which enables a real node scripting
> > 3. java -> hack with maven compiler+exec-maven-plugin but has the
> > dependency pitfall
> > 4. python -> probably acceptable but several jython maven plugins have
> > more integrations (not using jsr223)
> > 5. ruby -> jruby-maven-plugin, way more features and configurations needed
> > for ruby (like gems)
> >
> > Not sure other languages are often used through JSR223 but overall there
> > is almost no real cases justifying current plugin usage as of today
> > because
> > you will quickly hit limitations already solved until your case is very
> > simple and you just replace ant maven plugin IMHO.
> >
> > Indeed, you are fully right, from the project instance you can hack all
> > you want but then you end up managing complex scripts so it is generally
> > pointless and preferrable to be able:
> > 1. to configure the engine
> > 2. configure the bindings from the pom.xml (or have several virtual/or not
> > ones out of the box)
> > 3. handling the execution environment (which is sometimes linked to 1 and
> > sometimes not as for java)
> >
> > Java case also needs a bit more like using toolchain and plexus-java for
> > example - until you do it more simply using javac directly but wouldn't be
> > consistent for maven itself.
> >
> > Now I fully hear the "there is enough SPI to do it outside" and I can
> > agree with it but then my question would be "what is the goal of this
> > plugin" in current ecosystem?
> > Java integration is an opportunity to give to maven some scripting
> > capabilities keys in current way to develop for doc and integration with
> > external system but we have alternatives, this is why I sent this mail
> > before doing all the code - BTW i can push a quick PoC if you want to see
> > more what it can look like, I was not sure it was the way to solve that
> > extensibility need *from the project* itself.
> >
> > Hope it makes sense.
> >
> > 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-performan
> > ce>
> >
> >
> > Le ven. 26 févr. 2021 à 08:40, Hervé BOUTEMY <he...@free.fr> a
> >
> > écrit :
> >> I don't get every detail, but have one question on dependencies: isn't
> >> dependency injection to the maven-scripting-plugin sufficient [1]
> >>
> >> do you need something more advanced, managed by the
> >> maven-scripting-plugin
> >> itself?
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> [1]
> >> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> >> configure-the-script-engine.html
> >> <https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> >> configure-the-script-engine.html>>>
> >> Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
> >> > Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu> a
> >> >
> >> > écrit :
> >> > > Romain,
> >> > >
> >> > > just to understand your target: In the end what you want is that the
> >>
> >> Java
> >>
> >> > > scripting plugin will execute Java source code, just like jshell
> >> > > does?
> >> > > That
> >> > > sounds interesting to me.
> >> >
> >> > This is more a side effect, the target is to be able to be able to
> >>
> >> replace
> >>
> >> > src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has
> >> > the
> >> > drawback to require dependencies in the actual module (even in scope
> >> > provided).
> >> > The scripting plugin has the opportunity to normalize that through the
> >> > maven-java-scripting-engine which will take this through engine
> >> > configuration.
> >> > To illustrate the usage: it generates documentation, typed clients
> >>
> >> (http),
> >>
> >> > jsonschema, openapi.json, docker images with CDS and much more and in a
> >> > customized fashion.
> >> > Big gain is to not have to leak all dependencies in the build and keep
> >> > build part of the build isolated (a profile can enable to code in the
> >>
> >> IDE
> >>
> >> > but when running mvn xxx it is gone/deactivated).
> >> >
> >> > Side notes:
> >> > 1. creating a build module is not an option since it is really about
> >>
> >> having
> >>
> >> > the build code in the related module and not a "put it all" module
> >>
> >> which is
> >>
> >> > very hard to maintain.
> >> > 2. creating a mojo for these needs is inefficient in terms of
> >>
> >> maintenance
> >>
> >> > and customization level (I come from there) and ultra verbose in the
> >> > pom
> >> > compared to this scripting option
> >> >
> >> >
> >> > Hope it clarifies my goal
> >> >
> >> > > -Markus
> >> > >
> >> > >
> >> > > -----Ursprüngliche Nachricht-----
> >> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> >> > > Gesendet: Donnerstag, 25. Februar 2021 09:59
> >> > > An: Maven Developers List
> >> > > Betreff: Future of maven scripting plugin, java?
> >> > >
> >> > > Hi all,
> >> > >
> >> > > Wonder if maven scripting plugin has some future plans or not.
> >> > > Very concretely I'm interested in being able to use java as scripting
> >> > > files
> >> > > (something along src/build/scripting in terms of structure in final
> >> > > project).
> >> > > Since we are in maven we have javac so it is not hard to implement a
> >> > > jsr223
> >> > > (with tool provider or not is a detail) but more complicated thing is
> >>
> >> the
> >>
> >> > > classpath, it needs the plugin to be able to create a classloader
> >>
> >> adjusted
> >>
> >> > > for that kind of execution (potentially compiling the whole scripting
> >> > > folder). In terms of impacts it means enabling to configure the
> >> > > script
> >> > > engine, ie pass args from the mojo to the getScriptEngine method
> >> > > (typically
> >> > > kind of the same as exec maven plugin, ie scope/classpath).
> >> > >
> >> > > So changes would be:
> >> > >
> >> > > 1. implement a java script engine
> >> > > 2. make the script engine instantiation more configurable
> >> > >
> >> > > Do you think it is worth it or exec maven plugin is still preferred?
> >> > >
> >> > > 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-performan
> >> c
> >>
> >> > > e
> >> > >
> >> > >
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > 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: Future of maven scripting plugin, java?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
here is a draft
https://github.com/apache/maven-scripting-plugin/tree/rmannibucau/java-scripting-draft,
still require some more love for dependency management (for now it will use
project dependencies) but shows the overall idea I guess
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. 26 févr. 2021 à 09:07, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
> Hi Hervé,
>
> Do you mean project binding and from there use plexus container to lookup
> anything?
> This can work but then the question is what is the value of this plugin?
> To detail that let me review the usage you can get today:
>
> 1. groovy -> you will likely use gplus plugin which is more centered on
> groovy and way more powerful
> 2. js -> likely nashorn-maven-plugin for trivial script which has more
> bindings and a better script enclosing but if you really do js you can end
> up using frontend-maven-plugin which enables a real node scripting
> 3. java -> hack with maven compiler+exec-maven-plugin but has the
> dependency pitfall
> 4. python -> probably acceptable but several jython maven plugins have
> more integrations (not using jsr223)
> 5. ruby -> jruby-maven-plugin, way more features and configurations needed
> for ruby (like gems)
>
> Not sure other languages are often used through JSR223 but overall there
> is almost no real cases justifying current plugin usage as of today because
> you will quickly hit limitations already solved until your case is very
> simple and you just replace ant maven plugin IMHO.
>
> Indeed, you are fully right, from the project instance you can hack all
> you want but then you end up managing complex scripts so it is generally
> pointless and preferrable to be able:
> 1. to configure the engine
> 2. configure the bindings from the pom.xml (or have several virtual/or not
> ones out of the box)
> 3. handling the execution environment (which is sometimes linked to 1 and
> sometimes not as for java)
>
> Java case also needs a bit more like using toolchain and plexus-java for
> example - until you do it more simply using javac directly but wouldn't be
> consistent for maven itself.
>
> Now I fully hear the "there is enough SPI to do it outside" and I can
> agree with it but then my question would be "what is the goal of this
> plugin" in current ecosystem?
> Java integration is an opportunity to give to maven some scripting
> capabilities keys in current way to develop for doc and integration with
> external system but we have alternatives, this is why I sent this mail
> before doing all the code - BTW i can push a quick PoC if you want to see
> more what it can look like, I was not sure it was the way to solve that
> extensibility need *from the project* itself.
>
> Hope it makes sense.
>
> 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. 26 févr. 2021 à 08:40, Hervé BOUTEMY <he...@free.fr> a
> écrit :
>
>> I don't get every detail, but have one question on dependencies: isn't
>> dependency injection to the maven-scripting-plugin sufficient [1]
>>
>> do you need something more advanced, managed by the
>> maven-scripting-plugin
>> itself?
>>
>> Regards,
>>
>> Hervé
>>
>> [1]
>> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
>> configure-the-script-engine.html
>> <https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/configure-the-script-engine.html>
>>
>> Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
>> > Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu> a
>> >
>> > écrit :
>> > > Romain,
>> > >
>> > > just to understand your target: In the end what you want is that the
>> Java
>> > > scripting plugin will execute Java source code, just like jshell does?
>> > > That
>> > > sounds interesting to me.
>> >
>> > This is more a side effect, the target is to be able to be able to
>> replace
>> > src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has the
>> > drawback to require dependencies in the actual module (even in scope
>> > provided).
>> > The scripting plugin has the opportunity to normalize that through the
>> > maven-java-scripting-engine which will take this through engine
>> > configuration.
>> > To illustrate the usage: it generates documentation, typed clients
>> (http),
>> > jsonschema, openapi.json, docker images with CDS and much more and in a
>> > customized fashion.
>> > Big gain is to not have to leak all dependencies in the build and keep
>> > build part of the build isolated (a profile can enable to code in the
>> IDE
>> > but when running mvn xxx it is gone/deactivated).
>> >
>> > Side notes:
>> > 1. creating a build module is not an option since it is really about
>> having
>> > the build code in the related module and not a "put it all" module
>> which is
>> > very hard to maintain.
>> > 2. creating a mojo for these needs is inefficient in terms of
>> maintenance
>> > and customization level (I come from there) and ultra verbose in the pom
>> > compared to this scripting option
>> >
>> >
>> > Hope it clarifies my goal
>> >
>> > > -Markus
>> > >
>> > >
>> > > -----Ursprüngliche Nachricht-----
>> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>> > > Gesendet: Donnerstag, 25. Februar 2021 09:59
>> > > An: Maven Developers List
>> > > Betreff: Future of maven scripting plugin, java?
>> > >
>> > > Hi all,
>> > >
>> > > Wonder if maven scripting plugin has some future plans or not.
>> > > Very concretely I'm interested in being able to use java as scripting
>> > > files
>> > > (something along src/build/scripting in terms of structure in final
>> > > project).
>> > > Since we are in maven we have javac so it is not hard to implement a
>> > > jsr223
>> > > (with tool provider or not is a detail) but more complicated thing is
>> the
>> > > classpath, it needs the plugin to be able to create a classloader
>> adjusted
>> > > for that kind of execution (potentially compiling the whole scripting
>> > > folder). In terms of impacts it means enabling to configure the script
>> > > engine, ie pass args from the mojo to the getScriptEngine method
>> > > (typically
>> > > kind of the same as exec maven plugin, ie scope/classpath).
>> > >
>> > > So changes would be:
>> > >
>> > > 1. implement a java script engine
>> > > 2. make the script engine instantiation more configurable
>> > >
>> > > Do you think it is worth it or exec maven plugin is still preferred?
>> > >
>> > > 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-performanc
>> > > e
>> > >
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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: Future of maven scripting plugin, java?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Hervé,
Do you mean project binding and from there use plexus container to lookup
anything?
This can work but then the question is what is the value of this plugin?
To detail that let me review the usage you can get today:
1. groovy -> you will likely use gplus plugin which is more centered on
groovy and way more powerful
2. js -> likely nashorn-maven-plugin for trivial script which has more
bindings and a better script enclosing but if you really do js you can end
up using frontend-maven-plugin which enables a real node scripting
3. java -> hack with maven compiler+exec-maven-plugin but has the
dependency pitfall
4. python -> probably acceptable but several jython maven plugins have more
integrations (not using jsr223)
5. ruby -> jruby-maven-plugin, way more features and configurations needed
for ruby (like gems)
Not sure other languages are often used through JSR223 but overall there is
almost no real cases justifying current plugin usage as of today because
you will quickly hit limitations already solved until your case is very
simple and you just replace ant maven plugin IMHO.
Indeed, you are fully right, from the project instance you can hack all you
want but then you end up managing complex scripts so it is generally
pointless and preferrable to be able:
1. to configure the engine
2. configure the bindings from the pom.xml (or have several virtual/or not
ones out of the box)
3. handling the execution environment (which is sometimes linked to 1 and
sometimes not as for java)
Java case also needs a bit more like using toolchain and plexus-java for
example - until you do it more simply using javac directly but wouldn't be
consistent for maven itself.
Now I fully hear the "there is enough SPI to do it outside" and I can agree
with it but then my question would be "what is the goal of this plugin" in
current ecosystem?
Java integration is an opportunity to give to maven some scripting
capabilities keys in current way to develop for doc and integration with
external system but we have alternatives, this is why I sent this mail
before doing all the code - BTW i can push a quick PoC if you want to see
more what it can look like, I was not sure it was the way to solve that
extensibility need *from the project* itself.
Hope it makes sense.
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. 26 févr. 2021 à 08:40, Hervé BOUTEMY <he...@free.fr> a
écrit :
> I don't get every detail, but have one question on dependencies: isn't
> dependency injection to the maven-scripting-plugin sufficient [1]
>
> do you need something more advanced, managed by the maven-scripting-plugin
> itself?
>
> Regards,
>
> Hervé
>
> [1]
> https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
> configure-the-script-engine.html
> <https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/configure-the-script-engine.html>
>
> Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
> > Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu> a
> >
> > écrit :
> > > Romain,
> > >
> > > just to understand your target: In the end what you want is that the
> Java
> > > scripting plugin will execute Java source code, just like jshell does?
> > > That
> > > sounds interesting to me.
> >
> > This is more a side effect, the target is to be able to be able to
> replace
> > src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has the
> > drawback to require dependencies in the actual module (even in scope
> > provided).
> > The scripting plugin has the opportunity to normalize that through the
> > maven-java-scripting-engine which will take this through engine
> > configuration.
> > To illustrate the usage: it generates documentation, typed clients
> (http),
> > jsonschema, openapi.json, docker images with CDS and much more and in a
> > customized fashion.
> > Big gain is to not have to leak all dependencies in the build and keep
> > build part of the build isolated (a profile can enable to code in the IDE
> > but when running mvn xxx it is gone/deactivated).
> >
> > Side notes:
> > 1. creating a build module is not an option since it is really about
> having
> > the build code in the related module and not a "put it all" module which
> is
> > very hard to maintain.
> > 2. creating a mojo for these needs is inefficient in terms of maintenance
> > and customization level (I come from there) and ultra verbose in the pom
> > compared to this scripting option
> >
> >
> > Hope it clarifies my goal
> >
> > > -Markus
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > > Gesendet: Donnerstag, 25. Februar 2021 09:59
> > > An: Maven Developers List
> > > Betreff: Future of maven scripting plugin, java?
> > >
> > > Hi all,
> > >
> > > Wonder if maven scripting plugin has some future plans or not.
> > > Very concretely I'm interested in being able to use java as scripting
> > > files
> > > (something along src/build/scripting in terms of structure in final
> > > project).
> > > Since we are in maven we have javac so it is not hard to implement a
> > > jsr223
> > > (with tool provider or not is a detail) but more complicated thing is
> the
> > > classpath, it needs the plugin to be able to create a classloader
> adjusted
> > > for that kind of execution (potentially compiling the whole scripting
> > > folder). In terms of impacts it means enabling to configure the script
> > > engine, ie pass args from the mojo to the getScriptEngine method
> > > (typically
> > > kind of the same as exec maven plugin, ie scope/classpath).
> > >
> > > So changes would be:
> > >
> > > 1. implement a java script engine
> > > 2. make the script engine instantiation more configurable
> > >
> > > Do you think it is worth it or exec maven plugin is still preferred?
> > >
> > > 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-performanc
> > > e
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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: Future of maven scripting plugin, java?
Posted by Hervé BOUTEMY <he...@free.fr>.
I don't get every detail, but have one question on dependencies: isn't
dependency injection to the maven-scripting-plugin sufficient [1]
do you need something more advanced, managed by the maven-scripting-plugin
itself?
Regards,
Hervé
[1] https://maven.apache.org/plugins-archives/maven-scripting-plugin-LATEST/
configure-the-script-engine.html
Le jeudi 25 février 2021, 16:16:09 CET Romain Manni-Bucau a écrit :
> Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu> a
>
> écrit :
> > Romain,
> >
> > just to understand your target: In the end what you want is that the Java
> > scripting plugin will execute Java source code, just like jshell does?
> > That
> > sounds interesting to me.
>
> This is more a side effect, the target is to be able to be able to replace
> src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has the
> drawback to require dependencies in the actual module (even in scope
> provided).
> The scripting plugin has the opportunity to normalize that through the
> maven-java-scripting-engine which will take this through engine
> configuration.
> To illustrate the usage: it generates documentation, typed clients (http),
> jsonschema, openapi.json, docker images with CDS and much more and in a
> customized fashion.
> Big gain is to not have to leak all dependencies in the build and keep
> build part of the build isolated (a profile can enable to code in the IDE
> but when running mvn xxx it is gone/deactivated).
>
> Side notes:
> 1. creating a build module is not an option since it is really about having
> the build code in the related module and not a "put it all" module which is
> very hard to maintain.
> 2. creating a mojo for these needs is inefficient in terms of maintenance
> and customization level (I come from there) and ultra verbose in the pom
> compared to this scripting option
>
>
> Hope it clarifies my goal
>
> > -Markus
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Donnerstag, 25. Februar 2021 09:59
> > An: Maven Developers List
> > Betreff: Future of maven scripting plugin, java?
> >
> > Hi all,
> >
> > Wonder if maven scripting plugin has some future plans or not.
> > Very concretely I'm interested in being able to use java as scripting
> > files
> > (something along src/build/scripting in terms of structure in final
> > project).
> > Since we are in maven we have javac so it is not hard to implement a
> > jsr223
> > (with tool provider or not is a detail) but more complicated thing is the
> > classpath, it needs the plugin to be able to create a classloader adjusted
> > for that kind of execution (potentially compiling the whole scripting
> > folder). In terms of impacts it means enabling to configure the script
> > engine, ie pass args from the mojo to the getScriptEngine method
> > (typically
> > kind of the same as exec maven plugin, ie scope/classpath).
> >
> > So changes would be:
> >
> > 1. implement a java script engine
> > 2. make the script engine instantiation more configurable
> >
> > Do you think it is worth it or exec maven plugin is still preferred?
> >
> > 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-performanc
> > e
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
AW: Future of maven scripting plugin, java?
Posted by Markus KARG <ma...@headcrashing.eu>.
LGTM. Please tell me when done! ;-D
-Markus
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Donnerstag, 25. Februar 2021 16:16
An: Maven Developers List
Betreff: Re: Future of maven scripting plugin, java?
Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu> a
écrit :
> Romain,
>
> just to understand your target: In the end what you want is that the Java
> scripting plugin will execute Java source code, just like jshell does? That
> sounds interesting to me.
>
This is more a side effect, the target is to be able to be able to replace
src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has the
drawback to require dependencies in the actual module (even in scope
provided).
The scripting plugin has the opportunity to normalize that through the
maven-java-scripting-engine which will take this through engine
configuration.
To illustrate the usage: it generates documentation, typed clients (http),
jsonschema, openapi.json, docker images with CDS and much more and in a
customized fashion.
Big gain is to not have to leak all dependencies in the build and keep
build part of the build isolated (a profile can enable to code in the IDE
but when running mvn xxx it is gone/deactivated).
Side notes:
1. creating a build module is not an option since it is really about having
the build code in the related module and not a "put it all" module which is
very hard to maintain.
2. creating a mojo for these needs is inefficient in terms of maintenance
and customization level (I come from there) and ultra verbose in the pom
compared to this scripting option
Hope it clarifies my goal
>
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Donnerstag, 25. Februar 2021 09:59
> An: Maven Developers List
> Betreff: Future of maven scripting plugin, java?
>
> Hi all,
>
> Wonder if maven scripting plugin has some future plans or not.
> Very concretely I'm interested in being able to use java as scripting files
> (something along src/build/scripting in terms of structure in final
> project).
> Since we are in maven we have javac so it is not hard to implement a jsr223
> (with tool provider or not is a detail) but more complicated thing is the
> classpath, it needs the plugin to be able to create a classloader adjusted
> for that kind of execution (potentially compiling the whole scripting
> folder). In terms of impacts it means enabling to configure the script
> engine, ie pass args from the mojo to the getScriptEngine method (typically
> kind of the same as exec maven plugin, ie scope/classpath).
>
> So changes would be:
>
> 1. implement a java script engine
> 2. make the script engine instantiation more configurable
>
> Do you think it is worth it or exec maven plugin is still preferred?
>
> 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
> >
>
>
> ---------------------------------------------------------------------
> 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: Future of maven scripting plugin, java?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le jeu. 25 févr. 2021 à 15:28, Markus KARG <ma...@headcrashing.eu> a
écrit :
> Romain,
>
> just to understand your target: In the end what you want is that the Java
> scripting plugin will execute Java source code, just like jshell does? That
> sounds interesting to me.
>
This is more a side effect, the target is to be able to be able to replace
src/main/java/xxxx/build/*.java + exec-maven-plugin setups which has the
drawback to require dependencies in the actual module (even in scope
provided).
The scripting plugin has the opportunity to normalize that through the
maven-java-scripting-engine which will take this through engine
configuration.
To illustrate the usage: it generates documentation, typed clients (http),
jsonschema, openapi.json, docker images with CDS and much more and in a
customized fashion.
Big gain is to not have to leak all dependencies in the build and keep
build part of the build isolated (a profile can enable to code in the IDE
but when running mvn xxx it is gone/deactivated).
Side notes:
1. creating a build module is not an option since it is really about having
the build code in the related module and not a "put it all" module which is
very hard to maintain.
2. creating a mojo for these needs is inefficient in terms of maintenance
and customization level (I come from there) and ultra verbose in the pom
compared to this scripting option
Hope it clarifies my goal
>
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Donnerstag, 25. Februar 2021 09:59
> An: Maven Developers List
> Betreff: Future of maven scripting plugin, java?
>
> Hi all,
>
> Wonder if maven scripting plugin has some future plans or not.
> Very concretely I'm interested in being able to use java as scripting files
> (something along src/build/scripting in terms of structure in final
> project).
> Since we are in maven we have javac so it is not hard to implement a jsr223
> (with tool provider or not is a detail) but more complicated thing is the
> classpath, it needs the plugin to be able to create a classloader adjusted
> for that kind of execution (potentially compiling the whole scripting
> folder). In terms of impacts it means enabling to configure the script
> engine, ie pass args from the mojo to the getScriptEngine method (typically
> kind of the same as exec maven plugin, ie scope/classpath).
>
> So changes would be:
>
> 1. implement a java script engine
> 2. make the script engine instantiation more configurable
>
> Do you think it is worth it or exec maven plugin is still preferred?
>
> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
AW: Future of maven scripting plugin, java?
Posted by Markus KARG <ma...@headcrashing.eu>.
Romain,
just to understand your target: In the end what you want is that the Java scripting plugin will execute Java source code, just like jshell does? That sounds interesting to me.
-Markus
-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Donnerstag, 25. Februar 2021 09:59
An: Maven Developers List
Betreff: Future of maven scripting plugin, java?
Hi all,
Wonder if maven scripting plugin has some future plans or not.
Very concretely I'm interested in being able to use java as scripting files
(something along src/build/scripting in terms of structure in final
project).
Since we are in maven we have javac so it is not hard to implement a jsr223
(with tool provider or not is a detail) but more complicated thing is the
classpath, it needs the plugin to be able to create a classloader adjusted
for that kind of execution (potentially compiling the whole scripting
folder). In terms of impacts it means enabling to configure the script
engine, ie pass args from the mojo to the getScriptEngine method (typically
kind of the same as exec maven plugin, ie scope/classpath).
So changes would be:
1. implement a java script engine
2. make the script engine instantiation more configurable
Do you think it is worth it or exec maven plugin is still preferred?
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>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org