|
The article doesn't create a self-contained jlink image: it just
creates a minimal runtime image by leaving out unneeded JDK
modules (and because of the use of automatic modules, Simon has to
figure out the correct set of modules by using jdeps, rather than
having jlink do it for him).
If everything were modules, you wouldn't need this either: "To
simplify redistribution, we can copy the dist directory with the
application jar files into the java-runtime directory, create a
simple script to execute Java with all the appropriate command
line flags and we are all good to go."
Instead, you'd just run the "launcher" shell script in the jlink
image's bin directory.
Kind regards, Anthony
On 29/01/2020 16:26, Scott Stark wrote:
It is non-trivial, but this now older article by
Simon Ritter described how jlink could be used with automatic
modules:
are there problems with that approach?
Hi,
On 1/29/20 1:39 PM, Mark Thomas wrote:
> - Use that as the automatic module name
I know what I'm going to say is likely out-of-scope for EE 9
but at
least for APIs, I'd recommend considering providing full JPMS
descriptor
instead. The problem with automatic module name is that what
people/users seem to care about - based on projects I'm
involved in - is
the ability to use jlink provided by JDK 11+ and jlink cannot
be used
with automatic modules.
thanks,
--lukas
>
> is consistent with the requirement that the module names
start with
> "jakarta." and not inconsistent with any other Jakarta EE
wide policy.
>
> I therefore intend to proceed with this approach in the
projects in
> which I am involved.
>
> Separately, I'd like to recommend this proposed approach
for adoption
> across Jakarta EE.
>
> Thanks,
>
> Mark
>
>
> On 28/01/2020 18:13, Kevin Sutter wrote:
>> Thanks for the pointer to the Issue. Here's the
reference to the PMC
>> minutes regarding Module Names:
>> https://www.eclipse.org/ee4j/minutes/?date=2018-11-06#module-names
>>
>> This was the discussion previous to the Jakarta EE 8
release. It has
>> not been formally addressed for the Jakarta EE 9
release. I still stand
>> by the "jakarta." prefix, but we haven't declared the
required
>> definition of module names across all individual
projects.
>>
>> ---------------------------------------------------
>> Kevin Sutter
>> STSM, MicroProfile and Jakarta EE architect @ IBM
>> e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
>> phone: tl-553-3620 (office), 507-253-3620 (office)
>> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>>
>>
>>
>> From: Anthony Vanelverdinghe <anthonyv.be@xxxxxxxxxxx>
>> To: JakartaEE Spec Project Leadership
discussions
>> <jakartaee-spec-project-leads@xxxxxxxxxxx>,
Mark Thomas <markt@xxxxxxxxxx>
>> Date: 01/28/2020 11:53
>> Subject: [EXTERNAL] Re:
[jakartaee-spec-project-leads] Automatic
>> Module Names for Jakarta EE 9
>> Sent by: jakartaee-spec-project-leads-bounces@xxxxxxxxxxx
>>
------------------------------------------------------------------------
>>
>>
>>
>> Hi Mark
>>
>> There's [1], which says that module names must be
"jakarta.*", so e.g.
>> jakarta.el, jakarta.websocket, jakarta.servlet
>> I've been unable to find the issued PMC statement
though.
>>
>> [1] https://github.com/eclipse-ee4j/ee4j/issues/34#issuecomment-436605211
>>
>> Kind regards,
>> Anthony
>>
>> On 28/01/2020 18:02, Mark Thomas wrote:
>>> Hi,
>>>
>>> A number of projects I am involved in have open
issues for JPMS names to
>>> be defined [1][2][3]. Using the JAR name is
inherently unstable and
>>> triggers warnings in various build systems.
>>>
>>> Is there an official view on what project should
be using? I looked in
>>> [4] but module names are explicitly excluded.
>>>
>>> Absent an official view, is there any objection
to projects using:
>>> - Take the OSGi Bundle-SymbolicName
>>> - Replace any "-" with "."
>>> - Use that as the automatic module name
>>> ?
>>>
>>> Thanks,
>>>
>>> Mark
>>>
>>>
>>> [1] https://github.com/eclipse-ee4j/el-ri/issues/46
>>> [2] https://github.com/eclipse-ee4j/websocket-api/issues/260
>>> [3] https://github.com/eclipse-ee4j/servlet-api/issues/201
>>>
>>> [4] https://wiki.eclipse.org/JakartaEE_Maven_Versioning_Rules
>>>
>>>
>>> _______________________________________________
>>> jakartaee-spec-project-leads mailing list
>>> jakartaee-spec-project-leads@xxxxxxxxxxx
>>> To change your delivery options, retrieve your
password, or unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
>> _______________________________________________
>> jakartaee-spec-project-leads mailing list
>> jakartaee-spec-project-leads@xxxxxxxxxxx
>> To change your delivery options, retrieve your
password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
>>
>>
>>
>>
>
> _______________________________________________
> jakartaee-spec-project-leads mailing list
> jakartaee-spec-project-leads@xxxxxxxxxxx
> To change your delivery options, retrieve your password,
or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
>
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads
|
