You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benjamin Marwell <bm...@apache.org> on 2020/12/15 21:37:21 UTC
[MJLINK] Move from 3.0.1 to 3.1.0
Hello everyone,
looking at the issues already solved and soon-be-solved, the next release
feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
If you agree, I would like to update the git repository to 3.1.0 and create
a 3.0.x branch from the last release, if needed.
I would also like to request some help with the documentation [2].
Currently it says that an extra 'dist' project is needed, but with the
introduction of classifiers (or moving the main jar away using a
classifier), this does not hold true anymore.
Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
"won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
documented anymore – only 'jlink --plugin-list' shows its usage.
Summary:
4 issues left, of which are:
1 with PR to be merged (update plexus-utils)
1 with PR half-way done (--add-options for launcher script)
1 documentation to be done
1 to be moved away or "wont’t fix".
Thanks in advance,
Ben
[1]
https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1
[2] https://issues.apache.org/jira/browse/MJLINK-49
[3] https://issues.apache.org/jira/browse/MJLINK-39
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
+1 for 3.1.0 release
wt., 15 gru 2020 o 22:38 Benjamin Marwell <bm...@apache.org> napisał(a):
>
> Hello everyone,
>
> looking at the issues already solved and soon-be-solved, the next release
> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
>
> If you agree, I would like to update the git repository to 3.1.0 and create
> a 3.0.x branch from the last release, if needed.
>
> I would also like to request some help with the documentation [2].
> Currently it says that an extra 'dist' project is needed, but with the
> introduction of classifiers (or moving the main jar away using a
> classifier), this does not hold true anymore.
>
> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
> documented anymore – only 'jlink --plugin-list' shows its usage.
>
> Summary:
> 4 issues left, of which are:
> 1 with PR to be merged (update plexus-utils)
> 1 with PR half-way done (--add-options for launcher script)
> 1 documentation to be done
> 1 to be moved away or "wont’t fix".
>
> Thanks in advance,
> Ben
>
> [1]
> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1
> [2] https://issues.apache.org/jira/browse/MJLINK-49
> [3] https://issues.apache.org/jira/browse/MJLINK-39
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 15 décembre 2020, 22:53:47 CET Andres Almiray a écrit :
> Hello,
>
> Not that I want to hijack this thread but considering that the move is from
> a fix release to a minor release I wonder about the use of
> <packaging>jlink</packaging>.
>
> For a multi-module project having this packaging option is not much of a
> problem, as if the project produces more than one artifact (such as a
> shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra
> module can perform the jlink packaging.
>
> However for single project builds the <packaging>jlink</packaging> would
> prevent other packaging options, wouldn't it?
sure, there is only one packaging in a pom.xml
> Say I want to have single JAR, shaded JAR, and jlink image on the same
> single project build. Is it possible to do so?
yes, it's by definition of POM's packaging always possible to do (for this
packaging or any other): it's just not automatic but has to be configured as
explicit plugins calls
Here is for example the reference of default packaging and their associated
automatic plugin goals bindings:
https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html
Defining a packaging is just a way to ease such goals bindings: but nothing
prevents you to always use pom packaging (which binds only install:install and
deploy:deploy) and define by hand every plugin goals bindings you want that
would correspond to war for example (which would mean defining 6 additional
plugingoals bindings to be defined in your pom.xml)
>
> If it is, then I missed it in the docs.
given it's not specific to this plugin and its provided packaging, I suppose it
is implicit: don't hesitate to provide a PR to make this more explicit if you
think this is useful given the nature of this plugin
> It it's not allowed then I'd suggest if JAR packaging is also enabled when
> <packaging>jlink</packaging> is defined, so keep them both active. Then
> remove <packaging>jlink</packaging> in 4.0.0.
perhaps a page describing the jlink packaging the same way default packagings
are described in Maven core could help to understand the mechanism behind it
>
> As reference the Helidon maven plugin supports creating jlink and Graal
> native images while keeping <packaging>jar</packaging>
>
> https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plug
> in
>
> All this being said, this comment is to weight in a possible change that
> would merit a minor release instead of a fix release.
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell <bm...@apache.org>
>
> wrote:
> > Hello everyone,
> >
> > looking at the issues already solved and soon-be-solved, the next release
> > feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
> >
> > If you agree, I would like to update the git repository to 3.1.0 and
> > create
> > a 3.0.x branch from the last release, if needed.
> >
> > I would also like to request some help with the documentation [2].
> > Currently it says that an extra 'dist' project is needed, but with the
> > introduction of classifiers (or moving the main jar away using a
> > classifier), this does not hold true anymore.
> >
> > Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> > "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
> > documented anymore – only 'jlink --plugin-list' shows its usage.
> >
> > Summary:
> > 4 issues left, of which are:
> > 1 with PR to be merged (update plexus-utils)
> > 1 with PR half-way done (--add-options for launcher script)
> > 1 documentation to be done
> > 1 to be moved away or "wont’t fix".
> >
> > Thanks in advance,
> > Ben
> >
> > [1]
> >
> > https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK
> > %20AND%20fixVersion%20%3D%203.0.1 [2]
> > https://issues.apache.org/jira/browse/MJLINK-49
> > [3] https://issues.apache.org/jira/browse/MJLINK-39
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Andres Almiray <aa...@gmail.com>.
Hi Ben,
Nice!
https://github.com/apache/maven-jlink-plugin/blob/master/src/it/projects/MJLINK-52_classifiers_jarproject/pom.xml
This is what I as looking for, even if an explicit
<classifier>jlink</classifier> has t be defined.
Thanks!
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Wed, Dec 16, 2020 at 8:12 AM Benjamin Marwell <bm...@apache.org>
wrote:
> > Not that I want to hijack this thread
> No worries! It is always good to have an extra pair of eyes look at
> the work of a new committer. ;-)
>
> > However for single project builds the <packaging>jlink</packaging> would
> > prevent other packaging options, wouldn't it?
> I created ITs, but this set-up is not an the list:
> https://github.com/apache/maven-jlink-plugin/tree/master/src/it/projects
> (Especially MJLINK-52_*).
> I would not know why this would prevent other packaging options.
> I will create another IT which will be packaging=jlink and
> add a jar execution. Note that you will need to define the execution
> manually.
>
> > Say I want to have single JAR, shaded JAR, and jlink image on the same
> > single project build. Is it possible to do so?
> This is why MJLINK-52 adds classifiers.
> The check of existing artifacts was broken before then.
> Most ITs from the link above already show a single jar project
> with an extra jlink execution. Add as many shaded jars as you like…
>
> Does that help?
>
> Thanks,
> Ben
>
> On 15.12.20 22:53, Andres Almiray wrote:
> > Hello,
> >
> > Not that I want to hijack this thread but considering that the move is
> from
> > a fix release to a minor release I wonder about the use of
> > <packaging>jlink</packaging>.
> >
> > For a multi-module project having this packaging option is not much of a
> > problem, as if the project produces more than one artifact (such as a
> > shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra
> > module can perform the jlink packaging.
> >
> > However for single project builds the <packaging>jlink</packaging> would
> > prevent other packaging options, wouldn't it?
> > Say I want to have single JAR, shaded JAR, and jlink image on the same
> > single project build. Is it possible to do so?
> >
> > If it is, then I missed it in the docs.
> > It it's not allowed then I'd suggest if JAR packaging is also enabled
> when
> > <packaging>jlink</packaging> is defined, so keep them both active. Then
> > remove <packaging>jlink</packaging> in 4.0.0.
> >
> > As reference the Helidon maven plugin supports creating jlink and Graal
> > native images while keeping <packaging>jar</packaging>
> >
> >
> https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin
> >
> > All this being said, this comment is to weight in a possible change that
> > would merit a minor release instead of a fix release.
> >
> > Cheers,
> > Andres
> >
> > -------------------------------------------
> > Java Champion; Groovy Enthusiast
> > http://andresalmiray.com
> > http://www.linkedin.com/in/aalmiray
> > --
> > What goes up, must come down. Ask any system administrator.
> > There are 10 types of people in the world: Those who understand binary,
> and
> > those who don't.
> > To understand recursion, we must first understand recursion.
> >
> >
> > On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell <bm...@apache.org>
> > wrote:
> >
> >> Hello everyone,
> >>
> >> looking at the issues already solved and soon-be-solved, the next
> release
> >> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
> >>
> >> If you agree, I would like to update the git repository to 3.1.0 and
> create
> >> a 3.0.x branch from the last release, if needed.
> >>
> >> I would also like to request some help with the documentation [2].
> >> Currently it says that an extra 'dist' project is needed, but with the
> >> introduction of classifiers (or moving the main jar away using a
> >> classifier), this does not hold true anymore.
> >>
> >> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> >> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not
> even
> >> documented anymore – only 'jlink --plugin-list' shows its usage.
> >>
> >> Summary:
> >> 4 issues left, of which are:
> >> 1 with PR to be merged (update plexus-utils)
> >> 1 with PR half-way done (--add-options for launcher script)
> >> 1 documentation to be done
> >> 1 to be moved away or "wont’t fix".
> >>
> >> Thanks in advance,
> >> Ben
> >>
> >> [1]
> >>
> >>
> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1
> >> [2] https://issues.apache.org/jira/browse/MJLINK-49
> >> [3] https://issues.apache.org/jira/browse/MJLINK-39
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Benjamin Marwell <bm...@apache.org>.
> Not that I want to hijack this thread
No worries! It is always good to have an extra pair of eyes look at
the work of a new committer. ;-)
> However for single project builds the <packaging>jlink</packaging> would
> prevent other packaging options, wouldn't it?
I created ITs, but this set-up is not an the list:
https://github.com/apache/maven-jlink-plugin/tree/master/src/it/projects
(Especially MJLINK-52_*).
I would not know why this would prevent other packaging options.
I will create another IT which will be packaging=jlink and
add a jar execution. Note that you will need to define the execution
manually.
> Say I want to have single JAR, shaded JAR, and jlink image on the same
> single project build. Is it possible to do so?
This is why MJLINK-52 adds classifiers.
The check of existing artifacts was broken before then.
Most ITs from the link above already show a single jar project
with an extra jlink execution. Add as many shaded jars as you like…
Does that help?
Thanks,
Ben
On 15.12.20 22:53, Andres Almiray wrote:
> Hello,
>
> Not that I want to hijack this thread but considering that the move is from
> a fix release to a minor release I wonder about the use of
> <packaging>jlink</packaging>.
>
> For a multi-module project having this packaging option is not much of a
> problem, as if the project produces more than one artifact (such as a
> shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra
> module can perform the jlink packaging.
>
> However for single project builds the <packaging>jlink</packaging> would
> prevent other packaging options, wouldn't it?
> Say I want to have single JAR, shaded JAR, and jlink image on the same
> single project build. Is it possible to do so?
>
> If it is, then I missed it in the docs.
> It it's not allowed then I'd suggest if JAR packaging is also enabled when
> <packaging>jlink</packaging> is defined, so keep them both active. Then
> remove <packaging>jlink</packaging> in 4.0.0.
>
> As reference the Helidon maven plugin supports creating jlink and Graal
> native images while keeping <packaging>jar</packaging>
>
> https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin
>
> All this being said, this comment is to weight in a possible change that
> would merit a minor release instead of a fix release.
>
> Cheers,
> Andres
>
> -------------------------------------------
> Java Champion; Groovy Enthusiast
> http://andresalmiray.com
> http://www.linkedin.com/in/aalmiray
> --
> What goes up, must come down. Ask any system administrator.
> There are 10 types of people in the world: Those who understand binary, and
> those who don't.
> To understand recursion, we must first understand recursion.
>
>
> On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell <bm...@apache.org>
> wrote:
>
>> Hello everyone,
>>
>> looking at the issues already solved and soon-be-solved, the next release
>> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
>>
>> If you agree, I would like to update the git repository to 3.1.0 and create
>> a 3.0.x branch from the last release, if needed.
>>
>> I would also like to request some help with the documentation [2].
>> Currently it says that an extra 'dist' project is needed, but with the
>> introduction of classifiers (or moving the main jar away using a
>> classifier), this does not hold true anymore.
>>
>> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
>> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
>> documented anymore – only 'jlink --plugin-list' shows its usage.
>>
>> Summary:
>> 4 issues left, of which are:
>> 1 with PR to be merged (update plexus-utils)
>> 1 with PR half-way done (--add-options for launcher script)
>> 1 documentation to be done
>> 1 to be moved away or "wont’t fix".
>>
>> Thanks in advance,
>> Ben
>>
>> [1]
>>
>> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1
>> [2] https://issues.apache.org/jira/browse/MJLINK-49
>> [3] https://issues.apache.org/jira/browse/MJLINK-39
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Andres Almiray <aa...@gmail.com>.
Hello,
Not that I want to hijack this thread but considering that the move is from
a fix release to a minor release I wonder about the use of
<packaging>jlink</packaging>.
For a multi-module project having this packaging option is not much of a
problem, as if the project produces more than one artifact (such as a
shaded JAR, jar with classpath, assemble/assembler, jlink) then an extra
module can perform the jlink packaging.
However for single project builds the <packaging>jlink</packaging> would
prevent other packaging options, wouldn't it?
Say I want to have single JAR, shaded JAR, and jlink image on the same
single project build. Is it possible to do so?
If it is, then I missed it in the docs.
It it's not allowed then I'd suggest if JAR packaging is also enabled when
<packaging>jlink</packaging> is defined, so keep them both active. Then
remove <packaging>jlink</packaging> in 4.0.0.
As reference the Helidon maven plugin supports creating jlink and Graal
native images while keeping <packaging>jar</packaging>
https://github.com/oracle/helidon-build-tools/tree/master/helidon-maven-plugin
All this being said, this comment is to weight in a possible change that
would merit a minor release instead of a fix release.
Cheers,
Andres
-------------------------------------------
Java Champion; Groovy Enthusiast
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and
those who don't.
To understand recursion, we must first understand recursion.
On Tue, Dec 15, 2020 at 10:38 PM Benjamin Marwell <bm...@apache.org>
wrote:
> Hello everyone,
>
> looking at the issues already solved and soon-be-solved, the next release
> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
>
> If you agree, I would like to update the git repository to 3.1.0 and create
> a 3.0.x branch from the last release, if needed.
>
> I would also like to request some help with the documentation [2].
> Currently it says that an extra 'dist' project is needed, but with the
> introduction of classifiers (or moving the main jar away using a
> classifier), this does not hold true anymore.
>
> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
> documented anymore – only 'jlink --plugin-list' shows its usage.
>
> Summary:
> 4 issues left, of which are:
> 1 with PR to be merged (update plexus-utils)
> 1 with PR half-way done (--add-options for launcher script)
> 1 documentation to be done
> 1 to be moved away or "wont’t fix".
>
> Thanks in advance,
> Ben
>
> [1]
>
> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%20AND%20fixVersion%20%3D%203.0.1
> [2] https://issues.apache.org/jira/browse/MJLINK-49
> [3] https://issues.apache.org/jira/browse/MJLINK-39
>
Re: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Benjamin Marwell <bm...@apache.org>.
Merci! Yes, I cannot change releases, so highly appreciated!
I might ping you again about the release, as I created a
ECDSA OpenPGP key, which nexus does not yet recognize.
Thanks!
Ben
On 16.12.20 08:06, Hervé BOUTEMY wrote:
> given the number of new features, yes, switching to 3.1.0 makes sense
> I just renamed the next release to 3.1.0 in Jira (I fear you don't have
> permissions)
>
> No need to create 3.0.x Git branch for now, unless you really have a specific
> reason to do so: we generally don't try to maintain multiple versions in
> parallel
>
> Don't hesitate to ping if there are tasks you don't have permissions
>
> Regards,
>
> Hervé
>
> Le mardi 15 décembre 2020, 22:37:21 CET Benjamin Marwell a écrit :
>> Hello everyone,
>>
>> looking at the issues already solved and soon-be-solved, the next release
>> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
>>
>> If you agree, I would like to update the git repository to 3.1.0 and create
>> a 3.0.x branch from the last release, if needed.
>>
>> I would also like to request some help with the documentation [2].
>> Currently it says that an extra 'dist' project is needed, but with the
>> introduction of classifiers (or moving the main jar away using a
>> classifier), this does not hold true anymore.
>>
>> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
>> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
>> documented anymore – only 'jlink --plugin-list' shows its usage.
>>
>> Summary:
>> 4 issues left, of which are:
>> 1 with PR to be merged (update plexus-utils)
>> 1 with PR half-way done (--add-options for launcher script)
>> 1 documentation to be done
>> 1 to be moved away or "wont’t fix".
>>
>> Thanks in advance,
>> Ben
>>
>> [1]
>> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%2
>> 0AND%20fixVersion%20%3D%203.0.1 [2]
>> https://issues.apache.org/jira/browse/MJLINK-49
>> [3] https://issues.apache.org/jira/browse/MJLINK-39
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: [MJLINK] Move from 3.0.1 to 3.1.0
Posted by Hervé BOUTEMY <he...@free.fr>.
given the number of new features, yes, switching to 3.1.0 makes sense
I just renamed the next release to 3.1.0 in Jira (I fear you don't have
permissions)
No need to create 3.0.x Git branch for now, unless you really have a specific
reason to do so: we generally don't try to maintain multiple versions in
parallel
Don't hesitate to ping if there are tasks you don't have permissions
Regards,
Hervé
Le mardi 15 décembre 2020, 22:37:21 CET Benjamin Marwell a écrit :
> Hello everyone,
>
> looking at the issues already solved and soon-be-solved, the next release
> feels much more like a 3.1.0 release than a 3.0.1 (bugfix) release [1].
>
> If you agree, I would like to update the git repository to 3.1.0 and create
> a 3.0.x branch from the last release, if needed.
>
> I would also like to request some help with the documentation [2].
> Currently it says that an extra 'dist' project is needed, but with the
> introduction of classifiers (or moving the main jar away using a
> classifier), this does not hold true anymore.
>
> Third, I would like to move MJLINK-39 [3] to a 3.2.0 release (or even
> "won’t fix"), as the 'vm' option only applies to 32bit vms and is not even
> documented anymore – only 'jlink --plugin-list' shows its usage.
>
> Summary:
> 4 issues left, of which are:
> 1 with PR to be merged (update plexus-utils)
> 1 with PR half-way done (--add-options for launcher script)
> 1 documentation to be done
> 1 to be moved away or "wont’t fix".
>
> Thanks in advance,
> Ben
>
> [1]
> https://issues.apache.org/jira/browse/MJLINK-60?jql=project%20%3D%20MJLINK%2
> 0AND%20fixVersion%20%3D%203.0.1 [2]
> https://issues.apache.org/jira/browse/MJLINK-49
> [3] https://issues.apache.org/jira/browse/MJLINK-39
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org