You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Alexander Kriegisch <al...@kriegisch.name> on 2022/02/01 00:57:01 UTC
Re: Question for Maven Plugin developers/maintainers
I am replying to Manfred rather than to Tamás, because I am only
contributing to one plugin, and it is not using any Beanshell stuff. But
I do use Beanshell scripting in a few projects where it is difficult too
avoid, because I have not found any proper plugins to do what I need.
Examples include:
-- Using org.codehaus.mojo:build-helper-maven-plugin, goal
bsh-property, in order to unpack certain classes from Java 9+ JREs,
using the jimage executable. I am doing this in order to instrument
same classes and then prepend them to the bootclasspath using
'--path-module' in some situations. If Maven JMOD Plugin was not
dead, maybe that would be an alternative. But today it is not. You
cannot do a lot with that plugin. Besides, for the Java 8 profile
in the same project, I use Antrun with a simple unzip task in order
to extract the same classes from tools.jar. That is easier, no
extra BeanShell scripting needed.
-- Using org.codehaus.mojo:build-helper-maven-plugin, goal
bsh-property, in order to create a marker file after some expensive
steps (downloading and unpacking certain dependencies in order to
create a specific directory structure), so that in later builds a
file-based property does not activate the same profile again,
avoiding the downloading and unpacking in later builds. Why I am
doing that is complicated. Basically, it is because not all the
files I am downloading are available on Maven Central, so I cannot
simply use the Dependency plugin.
An alternative to Beanshell would be Groovy scripting in the above
cases, but pulling in heavy Groovy stuff for a little script in projects
which otherwise do not use Groovy seems to be a bit costly.
So Beanshell as such might be dead to some people, but even I who
otherwise claims to hate scripted builds cannot avoid it sometimes,
basically because I am too lazy to write my own Maven plugins, because I
do not wish to learn how to do so. Sometimes I just want to get
something done and usually have tried 5 other ways to solve the same
problem before yielding and resorting to Beanshell inside a POM.
--
Alexander Kriegisch
https://scrum-master.de
Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> I think beanshell is long dead. Any plugin that uses it would be for a
> very old Maven version and would need a lot of work when upgrading. So
> we should be okay to deprecate
>
> And in terms of ANT .. if there are any out there.. similar things
> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> is available as escape hatch as well.
>
> And there is also
> https://maven.apache.org/plugins/maven-scripting-plugin/
>
> So overall.. I would say we are ok to deprecate that support.
>
>
> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
>
>> We'd like to get some feedback from anyone who implemented,
>> maintained or plans to implement a Maven Plugin (Mojo):
>>
>> Did any of you see a Maven Plugin that is NOT implemented in Java
>> (but uses Ant or Beanshell scripting)?
>>
>> Currently implementing Maven Plugins with these scripting solutions
>> is possible, we are not aware of any uses of it. Hence, we would like
>> to deprecate support for these (naturally, based on user responses).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Question for Maven Plugin developers/maintainers
Posted by Hervé BOUTEMY <he...@free.fr>.
= the maven-script part of https://maven.apache.org/plugin-tools/index.html
Le mardi 1 février 2022, 09:16:36 CET Tamás Cservenák a écrit :
> Howdy,
>
> Yes, the reason for this question was to deprecate the "scripting" bit of
> maven-plugin-tools, as many of us did not see such a beast in a while....
>
> T
>
> On Tue, Feb 1, 2022 at 2:10 AM Manfred Moser <ma...@simpligility.com>
>
> wrote:
> > Fair enough and good examples for using beanshell in the pom. My point was
> > mostly that there are alternatives.
> >
> > Also from all I understand Tamás asked about implementing part of a plugin
> > in beanshell. That is what you are
> > avoiding by doing it in the POM. And if you were to implement a plugin I
> > would assume would also choose Java.
> > I know I would ;-)
> >
> >
> > Manfred
> >
> > Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):
> > > I am replying to Manfred rather than to Tamás, because I am only
> > > contributing to one plugin, and it is not using any Beanshell stuff. But
> > > I do use Beanshell scripting in a few projects where it is difficult too
> > > avoid, because I have not found any proper plugins to do what I need.
> > >
> > > Examples include:
> > > -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > >
> > > bsh-property, in order to unpack certain classes from Java 9+ JREs,
> > > using the jimage executable. I am doing this in order to instrument
> > > same classes and then prepend them to the bootclasspath using
> > > '--path-module' in some situations. If Maven JMOD Plugin was not
> > > dead, maybe that would be an alternative. But today it is not. You
> > > cannot do a lot with that plugin. Besides, for the Java 8 profile
> > > in the same project, I use Antrun with a simple unzip task in order
> > > to extract the same classes from tools.jar. That is easier, no
> > > extra BeanShell scripting needed.
> > >
> > > -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > >
> > > bsh-property, in order to create a marker file after some expensive
> > > steps (downloading and unpacking certain dependencies in order to
> > > create a specific directory structure), so that in later builds a
> > > file-based property does not activate the same profile again,
> > > avoiding the downloading and unpacking in later builds. Why I am
> > > doing that is complicated. Basically, it is because not all the
> > > files I am downloading are available on Maven Central, so I cannot
> > > simply use the Dependency plugin.
> > >
> > > An alternative to Beanshell would be Groovy scripting in the above
> > > cases, but pulling in heavy Groovy stuff for a little script in projects
> > > which otherwise do not use Groovy seems to be a bit costly.
> > >
> > > So Beanshell as such might be dead to some people, but even I who
> > > otherwise claims to hate scripted builds cannot avoid it sometimes,
> > > basically because I am too lazy to write my own Maven plugins, because I
> > > do not wish to learn how to do so. Sometimes I just want to get
> > > something done and usually have tried 5 other ways to solve the same
> > > problem before yielding and resorting to Beanshell inside a POM.
> > >
> > > --
> > > Alexander Kriegisch
> > > https://scrum-master.de
> > >
> > > Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> > >> I think beanshell is long dead. Any plugin that uses it would be for a
> > >> very old Maven version and would need a lot of work when upgrading. So
> > >> we should be okay to deprecate
> > >>
> > >> And in terms of ANT .. if there are any out there.. similar things
> > >> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> > >> is available as escape hatch as well.
> > >>
> > >> And there is also
> > >> https://maven.apache.org/plugins/maven-scripting-plugin/
> > >>
> > >> So overall.. I would say we are ok to deprecate that support.
> > >>
> > >> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
> > >>> We'd like to get some feedback from anyone who implemented,
> > >>> maintained or plans to implement a Maven Plugin (Mojo):
> > >>>
> > >>> Did any of you see a Maven Plugin that is NOT implemented in Java
> > >>> (but uses Ant or Beanshell scripting)?
> > >>>
> > >>> Currently implementing Maven Plugins with these scripting solutions
> > >>> is possible, we are not aware of any uses of it. Hence, we would like
> > >>> to deprecate support for these (naturally, based on user responses).
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Question for Maven Plugin developers/maintainers
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
Yes, the reason for this question was to deprecate the "scripting" bit of
maven-plugin-tools, as many of us did not see such a beast in a while....
T
On Tue, Feb 1, 2022 at 2:10 AM Manfred Moser <ma...@simpligility.com>
wrote:
> Fair enough and good examples for using beanshell in the pom. My point was
> mostly that there are alternatives.
>
> Also from all I understand Tamás asked about implementing part of a plugin
> in beanshell. That is what you are
> avoiding by doing it in the POM. And if you were to implement a plugin I
> would assume would also choose Java.
> I know I would ;-)
>
>
> Manfred
> Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):
>
> > I am replying to Manfred rather than to Tamás, because I am only
> > contributing to one plugin, and it is not using any Beanshell stuff. But
> > I do use Beanshell scripting in a few projects where it is difficult too
> > avoid, because I have not found any proper plugins to do what I need.
> > Examples include:
> >
> > -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > bsh-property, in order to unpack certain classes from Java 9+ JREs,
> > using the jimage executable. I am doing this in order to instrument
> > same classes and then prepend them to the bootclasspath using
> > '--path-module' in some situations. If Maven JMOD Plugin was not
> > dead, maybe that would be an alternative. But today it is not. You
> > cannot do a lot with that plugin. Besides, for the Java 8 profile
> > in the same project, I use Antrun with a simple unzip task in order
> > to extract the same classes from tools.jar. That is easier, no
> > extra BeanShell scripting needed.
> >
> > -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > bsh-property, in order to create a marker file after some expensive
> > steps (downloading and unpacking certain dependencies in order to
> > create a specific directory structure), so that in later builds a
> > file-based property does not activate the same profile again,
> > avoiding the downloading and unpacking in later builds. Why I am
> > doing that is complicated. Basically, it is because not all the
> > files I am downloading are available on Maven Central, so I cannot
> > simply use the Dependency plugin.
> >
> > An alternative to Beanshell would be Groovy scripting in the above
> > cases, but pulling in heavy Groovy stuff for a little script in projects
> > which otherwise do not use Groovy seems to be a bit costly.
> >
> > So Beanshell as such might be dead to some people, but even I who
> > otherwise claims to hate scripted builds cannot avoid it sometimes,
> > basically because I am too lazy to write my own Maven plugins, because I
> > do not wish to learn how to do so. Sometimes I just want to get
> > something done and usually have tried 5 other ways to solve the same
> > problem before yielding and resorting to Beanshell inside a POM.
> >
> > --
> > Alexander Kriegisch
> > https://scrum-master.de
> >
> >
> > Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> >
> >> I think beanshell is long dead. Any plugin that uses it would be for a
> >> very old Maven version and would need a lot of work when upgrading. So
> >> we should be okay to deprecate
> >>
> >> And in terms of ANT .. if there are any out there.. similar things
> >> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> >> is available as escape hatch as well.
> >>
> >> And there is also
> >> https://maven.apache.org/plugins/maven-scripting-plugin/
> >>
> >> So overall.. I would say we are ok to deprecate that support.
> >>
> >>
> >> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
> >>
> >>> We'd like to get some feedback from anyone who implemented,
> >>> maintained or plans to implement a Maven Plugin (Mojo):
> >>>
> >>> Did any of you see a Maven Plugin that is NOT implemented in Java
> >>> (but uses Ant or Beanshell scripting)?
> >>>
> >>> Currently implementing Maven Plugins with these scripting solutions
> >>> is possible, we are not aware of any uses of it. Hence, we would like
> >>> to deprecate support for these (naturally, based on user responses).
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Question for Maven Plugin developers/maintainers
Posted by Manfred Moser <ma...@simpligility.com>.
Fair enough and good examples for using beanshell in the pom. My point was mostly that there are alternatives.
Also from all I understand Tamás asked about implementing part of a plugin in beanshell. That is what you are
avoiding by doing it in the POM. And if you were to implement a plugin I would assume would also choose Java.
I know I would ;-)
Manfred
Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):
> I am replying to Manfred rather than to Tamás, because I am only
> contributing to one plugin, and it is not using any Beanshell stuff. But
> I do use Beanshell scripting in a few projects where it is difficult too
> avoid, because I have not found any proper plugins to do what I need.
> Examples include:
>
> -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> bsh-property, in order to unpack certain classes from Java 9+ JREs,
> using the jimage executable. I am doing this in order to instrument
> same classes and then prepend them to the bootclasspath using
> '--path-module' in some situations. If Maven JMOD Plugin was not
> dead, maybe that would be an alternative. But today it is not. You
> cannot do a lot with that plugin. Besides, for the Java 8 profile
> in the same project, I use Antrun with a simple unzip task in order
> to extract the same classes from tools.jar. That is easier, no
> extra BeanShell scripting needed.
>
> -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> bsh-property, in order to create a marker file after some expensive
> steps (downloading and unpacking certain dependencies in order to
> create a specific directory structure), so that in later builds a
> file-based property does not activate the same profile again,
> avoiding the downloading and unpacking in later builds. Why I am
> doing that is complicated. Basically, it is because not all the
> files I am downloading are available on Maven Central, so I cannot
> simply use the Dependency plugin.
>
> An alternative to Beanshell would be Groovy scripting in the above
> cases, but pulling in heavy Groovy stuff for a little script in projects
> which otherwise do not use Groovy seems to be a bit costly.
>
> So Beanshell as such might be dead to some people, but even I who
> otherwise claims to hate scripted builds cannot avoid it sometimes,
> basically because I am too lazy to write my own Maven plugins, because I
> do not wish to learn how to do so. Sometimes I just want to get
> something done and usually have tried 5 other ways to solve the same
> problem before yielding and resorting to Beanshell inside a POM.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
>
>> I think beanshell is long dead. Any plugin that uses it would be for a
>> very old Maven version and would need a lot of work when upgrading. So
>> we should be okay to deprecate
>>
>> And in terms of ANT .. if there are any out there.. similar things
>> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
>> is available as escape hatch as well.
>>
>> And there is also
>> https://maven.apache.org/plugins/maven-scripting-plugin/
>>
>> So overall.. I would say we are ok to deprecate that support.
>>
>>
>> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
>>
>>> We'd like to get some feedback from anyone who implemented,
>>> maintained or plans to implement a Maven Plugin (Mojo):
>>>
>>> Did any of you see a Maven Plugin that is NOT implemented in Java
>>> (but uses Ant or Beanshell scripting)?
>>>
>>> Currently implementing Maven Plugins with these scripting solutions
>>> is possible, we are not aware of any uses of it. Hence, we would like
>>> to deprecate support for these (naturally, based on user responses).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org