Re: [MJLINK] Move from 3.0.1 to 3.1.0
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 jlink 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 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 jlink 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 > > jlink. > > > > 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 jlink 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 > > jlink is defined, so keep them both active. Then > > remove jlink in 4.0.0. > > > > As reference the Helidon maven plugin supports creating jlink and Graal > > native images while keeping jar > > > > > 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 > > 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-unsubscr...@maven.apache.org > For additional commands, e-mail:
Re: [MJLINK] Move from 3.0.1 to 3.1.0
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 > jlink. > > 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 jlink 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 > jlink is defined, so keep them both active. Then > remove jlink 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 jar > > 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 > > 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
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 jlink 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 jlink. 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 jlink 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 jlink is defined, so keep them both active. Then remove jlink in 4.0.0. As reference the Helidon maven plugin supports creating jlink and Graal native images while keeping jar 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
+1 for 3.1.0 release wt., 15 gru 2020 o 22:38 Benjamin Marwell 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [MJLINK] Move from 3.0.1 to 3.1.0
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 jlink. 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 jlink 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 jlink is defined, so keep them both active. Then remove jlink in 4.0.0. As reference the Helidon maven plugin supports creating jlink and Graal native images while keeping jar 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 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 >
[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
