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 <bmarw...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
